Anleitung Forum Post Downloader - Tampermonkey-Script

Ich musste eine TamperMonkey-Einstellung ändern, um das wieder hinzubekommen. Ich glaube es war im Abschnitt 'Downloads BETA' und es war 'Download Mode:' Ich habe die Einstellung im Dropdown auf 'Native' geändert
 
Ein paar Releases für alle, die testen wollen:
Beta-Version 3.21.b03 - Fix für alte Bunkr-Links (cdn.bunkr.*):
https://github.com/courtneydax/sc-postdl/blob/main/scpostdl-beta.user.js
Violentmonkey Version 3.21.vm02 (mit Bunkr-Fix):
https://github.com/courtneydax/sc-postdl/blob/main/scpostdl-vm.user.js
xandominiriNeed2Sleep
Violentmonkey-Version getestet in Chrome und Firefox (Sideload mit Developer Edition), sollte größtenteils funktionieren, aber du brauchst die v2.45.5 Beta-Version von ViolentMonkey. Firefox/VM hat noch Probleme mit direkten Blob-Downloads, sollte aber für flache Downloads funktionieren.
Weiß nicht, ob ich VM langfristig unterstützen werde, weil ich es selbst nicht nutze, aber wollte zumindest eine Basis für VM-Support in 3.21 bieten. Außerdem sind mit den neuesten Updates nicht mehr viele Änderungen am Hauptskript nötig. Probiert's aus und sagt mir Bescheid.
 
Komisch, ich musste wohl meinen Browser neustarten, denn plötzlich funktionierte es wieder.
 
willowbranch
Getestet 3.21.b04 mit Firefox/Tampermonkey, und die alten Bunkr-Links funktionieren korrekt.
Ich habe auch 3.21.vm03 mit Firefox/Violentmonkey getestet, aber dort funktionieren alte Bunkr-Links nicht. Sowohl reguläre als auch direkte Downloads schlagen fehl.
Der Resolver findet die data-file-id, aber die _001_v2 API-Antwort wird als [object HTMLDocument] zurückgegeben. JSON.parse schlägt dann fehl, und das Skript fällt auf die tote Legacy-CDN-URL zurück, die als HTML/Wartungsantwort übersprungen wird.
Regulärer Download:
Code: 
[Bunkr] data-file-id from https://bunkr.cr/v/indiefoxx-355326119664164865-HzPcRSPX.mp4: 2961368
[Bunkr] api _001_v2 id=2961368: bytes=21 head=[object HTMLDocument]
[Bunkr] tryNewApi threw: JSON.parse: unexpected character at line 1 column 2 of the JSON data
[Bunkr] UNRESOLVED -> falling back to the page URL, which will download as HTML: https://cdn.bunkr.ru/indiefoxx-355326119664164865-HzPcRSPX.mp4
BUNKR SKIPPED (HTML/MAINTENANCE RESPONSE)
Der direkte Download hat das gleiche Problem mit einem nummerierten Legacy-CDN:
Code: 
https://cdn8.bunkr.ru/Kimberly-Kane-and-Ryan-Keely.1080p-0oQsNc0x.mp4

[Bunkr] data-file-id from https://bunkr.cr/v/Kimberly-Kane-and-Ryan-Keely.1080p-0oQsNc0x.mp4: 13453971
[Bunkr] api _001_v2 id=13453971: bytes=21 head=[object HTMLDocument]
[Bunkr] tryNewApi threw: JSON.parse: unexpected character at line 1 column 2 of the JSON data
BUNKR SKIPPED (HTML/MAINTENANCE RESPONSE)
Es sieht also so aus, als würde die Legacy-Link-Erkennung selbst in VM funktionieren, aber die Bunkr-API-Anfrage gibt ein HTML-Dokument statt JSON zurück.
 
iNeed2Sleep
Behoben in vm04. Ich habe es tatsächlich fast wörtlich aus deinem XenForoPostDownloader-3.17-VM2-Skript übernommen.
Neu in vm05. Aus demselben Skript habe ich den Mobile-Support wieder eingebaut, da man das praktisch genauso übernehmen konnte, auch wenn das Styling hinter isMobile gated war, sodass der Desktop-Look nicht beeinträchtigt wird.
 
Danke für das Script!
Gibt es eine einfache Möglichkeit, das so umzustellen, dass nur Bilder heruntergeladen werden?
Ich nehme an, eine Möglichkeit wäre, die whitelisted Dateierweiterungen in Tampermonkey zu entfernen, aber das würde auch andere Scripts betreffen, also würde ich das lieber nicht tun, wenn es nicht nötig ist. Gibt es also eine Einstellung oder Zeile im Script, die man ändern kann, um den gleichen Effekt zu erzielen?
Hab das Script gerade erst gefunden, also hab ich schon alle Videos, die ich will, mir fehlen nur noch die geposteten Bilder.
 
willowbranch
Es funktioniert jetzt. Ich bin nie dazu gekommen, die alte Bunkr-Unterstützung zu meinem VM2-Build hinzuzufügen, also ist es schön, dass sie jetzt da ist.
 
Du kannst über den Download-Button hovern und die Video-Anbieter für einen Post deaktivieren, der z.B. Bunkr-Videos und Goonbox-Bilder hat. Ansonsten kannst du zu Tampermonkey Settings->Downloads BETA->Whitelisted File Extensions gehen und alle Video-Erweiterungen entfernen, aber das würde alle deine Scripts betreffen, die die Browser API für Downloads nutzen.
Geil. :)
Neue Version b06:
https://github.com/courtneydax/sc-postdl/raw/refs/heads/main/scpostdl-beta.user.js
VM-Version vm06:
https://github.com/courtneydax/sc-postdl/raw/refs/heads/main/scpostdl-vm.user.js
- Filester-Fixes (hatte vorher keine Chance, die Filester-Post-Migration zu testen, sollte jetzt also gut sein)
 
willowbranch
Sieht so aus, als hätte Filester nach meinem ursprünglichen Fix noch ein paar weitere Sachen geändert. Ich musste auch meine eigene Version aktualisieren, weil deren Server-Validierung API-Antworten wie fsc3.cdn.cr abgelehnt hat.
Einzelne /d/-Links funktionieren jetzt in b06 und vm06, aber /f/-Alben wechseln immer noch zurück zum alten direkten URL-Format: https://fsc1.cdn.cr/v/
Danach versucht es die gleiche /v/-URL erneut auf fsc2 und fsc3, aber die geben jetzt alle 404 zurück.
Die Album-Slugs müssen den gleichen V2-Resolver wie einzelne /d/-Links verwenden: /v2/?token=&download=true&n=
Getestet mit b06 auf TM/Firefox und vm06 auf VM/Firefox.
 
Es gibt kein Größenlimit pro Post, aber diese fünf Turbo-Videos sind zusammen etwa 3 GB groß. Wenn die ZIP-Option aktiviert ist, kann der Browser beim Erstellen eines so großen Archivs fehlschlagen, sodass am Ende nichts gespeichert wird. Versuch, die ZIP-Option zu deaktivieren und die Dateien stattdessen einzeln herunterzuladen.
 
iNeed2Sleep
b07/vm07 ist mit diesen Fixes online, aber ich werde wahrscheinlich dieses Wochenende noch ein Update pushen, abhängig von ein paar Tests. Wenn alles gut läuft, packe ich es zusammen und pushe es zum Haupt-Repo. Die VM-Version lasse ich in meinem Repo, ich weiß nicht, ob POKI VM offiziell im Haupt-Repo unterstützen will.
 
Weiß nicht, ob das ein neues Problem ist oder ob ich es nur gerade bemerkt habe, aber Goonbox-Bilder in voller Größe werden nicht heruntergeladen.
 
willowbranch
Goonbox-API-Aufrufe geben in Firefox 403 zurück, weil GM_xmlhttpRequest aus dem SimpCity-Tab nicht die benötigten First-Party-Goonbox/Cloudflare-Cookies enthält.
Ich habe es mit einer kleinen Same-Origin-Bridge umgangen. Füge // @match https://goonbox.cr/* hinzu und benutze dann einen inaktiven Goonbox-Tab, der mit GM_openInTab geöffnet wurde. Der Goonbox-Tab liest gequeute API-Pfade aus dem GM-Storage, fordert sie mit fetch(url, { credentials: 'include' }) an und schreibt die JSON-Antwort über GM_setValue/GM_getValue zurück.
Die bestehende direkte API-Anfrage kann als erster Versuch bleiben. Wenn sie 403, leere Daten oder ungültiges JSON zurückgibt, sende die gleiche Anfrage über die Bridge. Verwende sie sowohl für /api/images/{id} als auch für /api/albums/{slug}/images?page={page} und nutze denselben Helfer-Tab für den ganzen Batch wieder.
Behalte das von GM_openInTab zurückgegebene Tab-Handle und schließe es mit tab.close() ein paar Sekunden nach der letzten Anfrage. window.close() allein hat in Chrome nicht immer funktioniert.
 
Gleiches hier. Das ist mir schon diese Woche früher passiert und ich habe es behoben, indem ich das Script manuell aktualisiert habe. Aber diesmal hat das nicht funktioniert.
 
iNeed2Sleep
Gut erkannt. Habe es in b08/vm08 eingebaut. Muss noch ein paar Filester-Tests machen, war übers Wochenende und unter der Woche beschäftigt. Das echte Leben kann manchmal echt nervig sein, lol.
 
willowbranch
Kein Problem, das echte Leben geht vor.
Ich hab b08/vm08 getestet. Chrome + Tampermonkey und Firefox + Violentmonkey haben beide funktioniert und die originalen Goonbox-Bilder heruntergeladen.
Firefox + Tampermonkey hat aber immer noch Probleme.
Bei einem Post mit JPGX-Bildern und https://goonbox.cr/a/apX4HA wurden die JPGX-Bilder sofort aufgelöst, aber die Goonbox-API-Anfrage lieferte den erwarteten 403. Danach wartete es fast genau 20 Sekunden und das Album konnte nicht aufgelöst werden, sieht also so aus, als hätte der Helper-Tab nie einen frischen Ready-Heartbeat gesendet. Bei Einzelbild-Posts kann es dann auch auf das niedriger aufgelöste Thumbnail zurückfallen.
Was bei meiner Version funktioniert hat, war das direkte Öffnen der echten Goonbox-Bild- oder Album-URL statt https://goonbox.cr/, mit einem Bridge-Marker in der URL. Der Bridge-Worker startet nur, wenn dieser Marker vorhanden ist. Er nutzt einen inaktiven Helper-Tab wieder, solange Anfragen aktiv sind, bricht den Close-Timer bei jeder neuen Anfrage ab und schließt den Tab erst ein paar Sekunden, nachdem Queue und aktive Anfragen leer sind.
Ich würde außerdem den alten Ready-Wert löschen, bevor der Helper geöffnet wird. Kommt innerhalb von 20 Sekunden kein frischer Heartbeat, würde ich das bestehende Tab-Handle schließen und einmal erneut versuchen, bevor der Circuit Breaker aktiviert wird. Der Same-Origin-Fetch kann auch ein paar Mal wiederholen, falls Cloudflare noch lädt.
 
Ist nur eine Kleinigkeit, aber gibt es eine Möglichkeit zu überprüfen, dass alles auf der Seite heruntergeladen wird, ohne jede Zip-Datei einzeln durchzugehen und mit den Posts auf der Seite zu vergleichen?
 
Ich glaube, am Ende wird die peepolove-Reaktion gesetzt, also wenn die Reaktion da ist, ist der Post heruntergeladen (vollständig?) oder?
 
Du musst dich anmelden oder registrieren, um hier zu antworten.
Zurück
Oben