Guide Forum Post Downloader - Script Tampermonkey

J'ai dû changer un paramètre de TamperMonkey pour retrouver ça. Je crois que c'était dans la section 'Downloads BETA' et c'était 'Download Mode :' J'ai changé le réglage dans la liste déroulante sur 'Native'
 
Quelques versions pour ceux qui veulent tester :
Version bêta 3.21.b03 - correctif pour les anciens liens bunkr (cdn.bunkr.*) :
https://github.com/courtneydax/sc-postdl/blob/main/scpostdl-beta.user.js
Version Violentmonkey 3.21.vm02 (correctif bunkr inclus) :
https://github.com/courtneydax/sc-postdl/blob/main/scpostdl-vm.user.js
xandominiriNeed2Sleep
Version Violentmonkey testée sur Chrome et Firefox (sideload avec l'édition développeur), et ça devrait globalement fonctionner mais il faudra la version bêta v2.45.5 de ViolentMonkey. Firefox/VM a encore des soucis avec les téléchargements blob directs, mais ça devrait marcher pour les téléchargements simples.
Je sais pas si je vais continuer à supporter VM vu que je l'utilise pas personnellement, mais je voulais au moins fournir une base pour le support VM sur 3.21. En plus, avec les dernières mises à jour, il n'y a pas beaucoup de changements nécessaires par rapport au script principal. Testez-le et dites-moi.
 
Bizarre, j'ai dû redémarrer mon navigateur, parce que d'un coup ça remarchait.
 
willowbranch
Testé 3.21.b04 avec Firefox/Tampermonkey, et les anciens liens Bunkr fonctionnent correctement.
J'ai aussi testé 3.21.vm03 avec Firefox/Violentmonkey, mais les anciens liens Bunkr ne fonctionnent pas là-bas. Les téléchargements normaux et directs échouent tous les deux.
Le resolver trouve le data-file-id, mais la réponse de l'API _001_v2 est renvoyée comme [object HTMLDocument]. JSON.parse échoue alors, et le script retombe sur l'URL morte du CDN legacy, qui est ignorée comme réponse HTML/maintenance.
Téléchargement normal :
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)
Le téléchargement direct a le même problème avec un CDN legacy numéroté :
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)
Donc on dirait que la détection des liens legacy fonctionne bien dans VM, mais la requête API de Bunkr renvoie un document HTML au lieu de JSON.
 
iNeed2Sleep
Corrigé dans vm04. J'ai en fait repris ça presque mot pour mot de ton script XenForoPostDownloader-3.17-VM2.
Nouveau dans vm05. Du même script j'ai réintégré le support mobile puisqu'il pouvait être repris quasiment de la même façon, même si le style était conditionné par isMobile donc le look desktop n'est pas affecté.
 
Merci pour le script !
Y a-t-il un moyen simple de modifier ça pour ne télécharger que les images ?
Je suppose qu'une des façons serait de retirer les extensions de fichiers autorisées dans Tampermonkey, mais ça affecterait les autres scripts, donc je préfère éviter si possible. Y a-t-il donc un paramètre ou une ligne dans le script qu'on peut modifier pour obtenir le même effet ?
Je viens de trouver ce script donc j'ai déjà toutes les vidéos que je veux, il ne me manque que toutes les images postées.
 
willowbranch
Ça marche maintenant. Je n'ai jamais pris le temps d'ajouter l'ancien support de Bunkr à mon build VM2, donc c'est cool de l'avoir maintenant.
 
Tu peux survoler le bouton de téléchargement et décocher les fournisseurs de vidéos pour un post qui a, disons, des vidéos bunkr et des images goonbox. Sinon, tu peux aller dans Tampermonkey Settings->Downloads BETA->Whitelisted File Extensions et retirer toutes les extensions vidéo, mais ça affecterait tous tes scripts qui utilisent la Browser API pour les téléchargements.
Génial. :)
Nouvelle version b06 :
https://github.com/courtneydax/sc-postdl/raw/refs/heads/main/scpostdl-beta.user.js
Version VM vm06 :
https://github.com/courtneydax/sc-postdl/raw/refs/heads/main/scpostdl-vm.user.js
- Corrections Filester (je n'avais pas eu l'occasion de tester la migration des posts filester avant, donc ça devrait être bon maintenant)
 
willowbranch
On dirait que Filester a encore changé quelques trucs après mon correctif initial. J'ai dû mettre à jour ma propre version aussi parce que leur validation serveur rejetait des réponses API comme fsc3.cdn.cr.
Les liens /d/ individuels fonctionnent maintenant dans b06 et vm06, mais les albums /f/ reviennent toujours à l'ancien format d'URL directe : https://fsc1.cdn.cr/v/
Ensuite il réessaie la même URL /v/ sur fsc2 et fsc3, mais elles renvoient toutes 404 maintenant.
Les slugs d'album doivent utiliser le même resolver V2 que les liens /d/ individuels : /v2/?token=&download=true&n=
Testé avec b06 sur TM/Firefox et vm06 sur VM/Firefox.
 
Il n'y a pas de limite de taille par post, mais ces cinq vidéos Turbo font environ 3 Go au total. Si l'option ZIP est activée, le navigateur peut échouer en créant une archive aussi grande, donc rien n'est sauvegardé à la fin. Essaie de décocher l'option ZIP et de les télécharger comme fichiers séparés à la place.
 
iNeed2Sleep
b07/vm07 est en ligne avec ces correctifs, mais je pousserai probablement une autre mise à jour ce week-end en fonction de quelques tests. Si tout va bien, je l'empaquetterai pour le pousser vers le repo principal. Je laisse la version VM sur mon repo, je ne sais pas si POKI veut officiellement supporter VM dans le repo principal.
 
Je ne sais pas si c'est un nouveau problème ou si je viens juste de le remarquer, mais les images Goonbox en taille réelle ne se téléchargent pas.
 
willowbranch
Les appels API Goonbox renvoient 403 dans Firefox parce que GM_xmlhttpRequest depuis l'onglet SimpCity n'inclut pas les cookies first-party Goonbox/Cloudflare requis.
J'ai contourné ça avec un petit pont same-origin. Ajoute // @match https://goonbox.cr/*, puis utilise un onglet Goonbox inactif ouvert avec GM_openInTab. L'onglet Goonbox lit les chemins API en file d'attente depuis le stockage GM, les demande avec fetch(url, { credentials: 'include' }), et réécrit la réponse JSON via GM_setValue/GM_getValue.
La requête API directe existante peut rester comme première tentative. Si elle renvoie 403, des données vides ou du JSON invalide, envoie la même requête via le pont. Utilise-le pour /api/images/{id} et /api/albums/{slug}/images?page={page}, et réutilise le même onglet helper pour tout le lot.
Garde le handle d'onglet renvoyé par GM_openInTab et ferme-le avec tab.close() quelques secondes après la dernière requête. window.close() seul n'a pas toujours fonctionné dans Chrome.
 
Pareil ici. C'est arrivé plus tôt cette semaine et je l'ai réglé en mettant à jour le script manuellement. Mais cette fois ça n'a pas marché.
 
iNeed2Sleep
Bien vu. Intégré dans b08/vm08. Je dois encore faire des tests filester, j'ai été occupé pendant le week-end et la semaine. La vraie vie peut être pénible parfois, lol.
 
willowbranch
Pas de souci, la vraie vie passe avant tout.
J'ai testé b08/vm08. Chrome + Tampermonkey et Firefox + Violentmonkey ont tous les deux fonctionné et téléchargé les images Goonbox originales.
Firefox + Tampermonkey a encore des soucis, par contre.
Sur un post contenant des images JPGX et https://goonbox.cr/a/apX4HA, les images JPGX se sont résolues immédiatement, mais la requête API Goonbox a renvoyé le 403 attendu. Elle a ensuite attendu presque exactement 20 secondes et l'album n'a pas pu se résoudre, donc on dirait que l'onglet helper n'a jamais envoyé de heartbeat "ready" frais. Les posts image unique peuvent aussi retomber sur la miniature basse résolution dans ce cas.
Ce qui a marché dans ma version, c'est d'ouvrir directement l'URL réelle de l'image ou de l'album Goonbox au lieu de https://goonbox.cr/, avec un marqueur bridge ajouté à l'URL. Le bridge worker ne démarre que si ce marqueur est présent. Il réutilise un onglet helper inactif tant que des requêtes sont actives, annule le timer de fermeture à chaque nouvelle requête, et ne ferme l'onglet que quelques secondes après que la file et les requêtes actives soient toutes vides.
Je viderais aussi l'ancienne valeur ready avant d'ouvrir le helper. Si aucun heartbeat frais n'arrive dans les 20 secondes, je fermerais le handle de l'onglet existant et réessaierais une fois avant d'activer le circuit breaker. Le fetch same-origin peut aussi réessayer quelques fois au cas où Cloudflare charge encore.
 
C'est juste un petit truc, mais y a-t-il un moyen de vérifier que tout sur la page est bien téléchargé sans avoir à passer par chaque fichier zip un par un et le comparer aux posts de la page ?
 
Je pense qu'il met la réaction peepolove à la fin, donc si cette réaction est là, ça veut dire que le post est téléchargé (en entier ?) non ?
 
Vous devez vous connecter ou vous enregistrer pour répondre ici.
Retour
Haut