Guida Forum Post Downloader - Script Tampermonkey

Ho dovuto cambiare un'impostazione di TamperMonkey per farlo tornare a funzionare. Credo fosse nella sezione 'Downloads BETA' ed era 'Download Mode:' Ho cambiato l'opzione nel menu a tendina su 'Native'
 
Un paio di release per chi vuole testarle:
Versione beta 3.21.b03 - fix per i vecchi link bunkr (cdn.bunkr.*):
https://github.com/courtneydax/sc-postdl/blob/main/scpostdl-beta.user.js
Versione Violentmonkey 3.21.vm02 (fix bunkr incluso):
https://github.com/courtneydax/sc-postdl/blob/main/scpostdl-vm.user.js
xandominiriNeed2Sleep
Versione Violentmonkey testata su Chrome e Firefox (sideload con l'edizione developer), e dovrebbe funzionare per lo più ma vi servirà la versione beta v2.45.5 di ViolentMonkey. Firefox/VM ha ancora problemi con i download diretti blob, ma dovrebbe funzionare per i download semplici.
Non so se continuerò a supportare VM visto che non lo uso personalmente, ma volevo almeno dare una base per il supporto VM sulla 3.21. Inoltre, con gli ultimi aggiornamenti, non servono molti cambiamenti rispetto allo script principale. Provatelo e fatemi sapere.
 
Strano, immagino di aver dovuto riavviare il browser, perché all'improvviso ha ricominciato a funzionare.
 
willowbranch
Testato 3.21.b04 con Firefox/Tampermonkey, e i vecchi link Bunkr funzionano correttamente.
Ho anche testato 3.21.vm03 con Firefox/Violentmonkey, ma i vecchi link Bunkr non funzionano lì. Sia i download normali che quelli diretti falliscono.
Il resolver trova il data-file-id, ma la risposta dell'API di _001_v2 viene restituita come [object HTMLDocument]. JSON.parse quindi fallisce, e lo script ricade sull'URL morto del CDN legacy, che viene saltato come risposta HTML/manutenzione.
Download normale:
Codice: 
[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)
Il download diretto ha lo stesso problema con un CDN legacy numerato:
Codice: 
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)
Quindi sembra che il rilevamento dei link legacy in sé funzioni in VM, ma la richiesta all'API di Bunkr restituisce un documento HTML invece di JSON.
 
iNeed2Sleep
Corretto in vm04. In realtà l'ho preso quasi parola per parola dal tuo script XenForoPostDownloader-3.17-VM2.
Novità in vm05. Dallo stesso script ho reinserito il supporto mobile visto che poteva essere ripreso praticamente allo stesso modo, anche se lo stile era condizionato da isMobile quindi il look desktop non ne risente.
 
Grazie per lo script!
C'è un modo semplice per cambiarlo in modo che scarichi solo le immagini?
Immagino che uno dei modi sia rimuovere le estensioni di file consentite in Tampermonkey, ma questo influenzerebbe anche gli altri script, quindi preferirei evitarlo se non necessario. Quindi c'è un'impostazione o una riga nello script che si può modificare per ottenere lo stesso effetto?
Ho appena trovato questo script quindi ho già tutti i video che voglio, mi mancano solo tutte le immagini postate.
 
willowbranch
Adesso funziona. Non avevo mai trovato il tempo di aggiungere il vecchio supporto Bunkr alla mia build VM2, quindi è bello averlo finalmente.
 
Puoi passare il mouse sul pulsante di download e deselezionare i provider video per un post che ha, ad esempio, video bunkr e immagini goonbox. Altrimenti puoi andare in Tampermonkey Settings->Downloads BETA->Whitelisted File Extensions e rimuovere tutte le estensioni video, ma questo influenzerebbe tutti gli script che usano la Browser API per i download.
Fantastico. :)
Nuova versione b06:
https://github.com/courtneydax/sc-postdl/raw/refs/heads/main/scpostdl-beta.user.js
Versione VM vm06:
https://github.com/courtneydax/sc-postdl/raw/refs/heads/main/scpostdl-vm.user.js
- Fix per Filester (prima non avevo avuto occasione di testare la migrazione dei post filester, quindi ora dovrebbe andare bene)
 
willowbranch
Sembra che Filester abbia cambiato un altro paio di cose dopo il mio fix originale. Ho dovuto aggiornare anche la mia versione perché la loro validazione server rifiutava risposte API come fsc3.cdn.cr.
I link /d/ singoli funzionano ora in b06 e vm06, ma gli album /f/ tornano ancora al vecchio formato URL diretto: https://fsc1.cdn.cr/v/
Poi riprova lo stesso URL /v/ su fsc2 e fsc3, ma ora restituiscono tutti 404.
Gli slug degli album devono usare lo stesso resolver V2 dei link /d/ singoli: /v2/?token=&download=true&n=
Testato con b06 su TM/Firefox e vm06 su VM/Firefox.
 
Non c'è un limite di dimensione per post, ma quei cinque video Turbo pesano circa 3 GB in totale. Se l'opzione ZIP è attivata, il browser potrebbe non riuscire a creare un archivio così grande, quindi alla fine non viene salvato nulla. Prova a deselezionare l'opzione ZIP e scaricarli come file separati.
 
iNeed2Sleep
b07/vm07 è online con quei fix, ma probabilmente farò un altro aggiornamento questo weekend in base ad alcuni test. Se tutto va bene, lo impacchetterò per pubblicarlo sul repo principale. Lascerò la versione VM sul mio repo, non so se POKI voglia supportare ufficialmente VM nel repo principale.
 
Non so se è un problema nuovo o se l'ho appena notato, ma le immagini Goonbox a dimensione piena non vengono scaricate.
 
willowbranch
Le chiamate API di Goonbox restituiscono 403 in Firefox perché GM_xmlhttpRequest dalla tab di SimpCity non include i cookie first-party Goonbox/Cloudflare necessari.
L'ho aggirato con un piccolo bridge same-origin. Aggiungi // @match https://goonbox.cr/*, poi usa una tab di Goonbox inattiva aperta con GM_openInTab. La tab di Goonbox legge i percorsi API in coda dallo storage GM, li richiede con fetch(url, { credentials: 'include' }), e riscrive la risposta JSON tramite GM_setValue/GM_getValue.
La richiesta API diretta esistente può rimanere come primo tentativo. Se restituisce 403, dati vuoti o JSON non valido, invia la stessa richiesta tramite il bridge. Usalo sia per /api/images/{id} che per /api/albums/{slug}/images?page={page}, e riutilizza la stessa tab helper per l'intero batch.
Mantieni l'handle della tab restituito da GM_openInTab e chiudilo con tab.close() qualche secondo dopo l'ultima richiesta. window.close() da solo non ha sempre funzionato in Chrome.
 
Anche qui. È successo prima questa settimana e l'ho risolto aggiornando lo script manualmente. Ma stavolta non ha funzionato.
 
iNeed2Sleep
Buona osservazione. L'ho incluso in b08/vm08. Devo ancora fare qualche test su filester, sono stato impegnato durante il weekend e la settimana. La vita reale a volte è una rottura, lol.
 
willowbranch
Nessun problema, la vita reale viene prima.
Ho testato b08/vm08. Chrome + Tampermonkey e Firefox + Violentmonkey hanno funzionato entrambi e scaricato le immagini originali di Goonbox.
Firefox + Tampermonkey continua ad avere problemi, però.
Su un post contenente immagini JPGX e https://goonbox.cr/a/apX4HA, le immagini JPGX si sono risolte subito, ma la richiesta all'API di Goonbox ha restituito il 403 previsto. Poi ha aspettato quasi esattamente 20 secondi e l'album non si è risolto, quindi sembra che la tab helper non abbia mai inviato un heartbeat "ready" fresco. I post con immagine singola possono anche ripiegare sulla thumbnail a risoluzione più bassa quando succede questo.
Ciò che ha funzionato nella mia versione è stato aprire l'URL reale dell'immagine o dell'album Goonbox invece di https://goonbox.cr/, con un marcatore bridge aggiunto all'URL. Il bridge worker parte solo quando quel marcatore è presente. Riutilizza una tab helper inattiva mentre ci sono richieste attive, annulla il timer di chiusura ogni volta che inizia una nuova richiesta, e chiude la tab solo qualche secondo dopo che coda e richieste attive sono entrambe vuote.
Pulirei anche il vecchio valore ready prima di aprire l'helper. Se non arriva un heartbeat fresco entro 20 secondi, chiuderei l'handle della tab esistente e riproverei una volta prima di attivare il circuit breaker. Il fetch same-origin può anche riprovare qualche volta nel caso in cui Cloudflare stia ancora caricando.
 
È solo una piccola cosa, ma c'è un modo per verificare che tutto nella pagina venga scaricato senza dover controllare ogni file zip uno per uno e confrontarlo con i post nella pagina?
 
Credo che alla fine metta la reazione peepolove, quindi se c'è quella reazione il post è stato scaricato (per intero?) giusto?
 
Devi accedere o registrarti per rispondere qui.
Indietro
Top