Guía Forum Post Downloader - Script de Tampermonkey

Tuve que cambiar una configuración de TamperMonkey para recuperar eso. Creo que era en la sección 'Downloads BETA' y era 'Download Mode:' Cambié la opción del desplegable a 'Native'
 
Un par de versiones para quien quiera probarlas:
Versión beta 3.21.b03 - fix para enlaces viejos de bunkr (cdn.bunkr.*):
https://github.com/courtneydax/sc-postdl/blob/main/scpostdl-beta.user.js
Versión Violentmonkey 3.21.vm02 (con fix de bunkr incluido):
https://github.com/courtneydax/sc-postdl/blob/main/scpostdl-vm.user.js
xandominiriNeed2Sleep
Versión de Violentmonkey probada en Chrome y Firefox (sideload con la edición developer), y debería funcionar en la mayoría de los casos pero vas a necesitar la versión beta v2.45.5 de ViolentMonkey. Firefox/VM todavía tiene problemas con descargas directas de blob, pero debería funcionar para descargas planas.
No sé si voy a seguir dando soporte a VM porque no lo uso yo mismo, pero al menos quería dar una base para el soporte de VM en 3.21. Además, con las últimas actualizaciones, no hace falta mucho cambio respecto al script principal. Pruébenlo y avísenme.
 
Raro, supongo que tuve que reiniciar el navegador, porque de repente volvió a funcionar.
 
willowbranch
Probé 3.21.b04 con Firefox/Tampermonkey, y los enlaces viejos de Bunkr funcionan correctamente.
También probé 3.21.vm03 con Firefox/Violentmonkey, pero los enlaces viejos de Bunkr no funcionan ahí. Fallan tanto las descargas normales como las directas.
El resolver encuentra el data-file-id, pero la respuesta de la API de _001_v2 se devuelve como [object HTMLDocument]. JSON.parse entonces falla, y el script cae de nuevo a la URL muerta del CDN legacy, que se salta como respuesta de HTML/mantenimiento.
Descarga normal:
Código: 
[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)
La descarga directa tiene el mismo problema con un CDN legacy numerado:
Código: 
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)
Así que parece que la detección de enlaces legacy en sí funciona en VM, pero la petición a la API de Bunkr devuelve un documento HTML en lugar de JSON.
 
iNeed2Sleep
Arreglado en vm04. La verdad lo agarré casi textual de tu script XenForoPostDownloader-3.17-VM2.
Nuevo en vm05. Del mismo script agregué de nuevo el soporte móvil de vuelta ya que se podía levantar prácticamente de la misma manera, aunque el estilo estaba condicionado a isMobile así que el look de escritorio no se ve afectado.
 
¡Gracias por el script!
¿Hay alguna forma fácil de cambiar esto para que solo descargue imágenes?
Supongo que una de las formas es quitar las extensiones de archivo permitidas en Tampermonkey, pero eso afectaría a otros scripts, así que prefiero no hacerlo a menos que sea necesario. ¿Hay algún ajuste o línea en el script que se pueda cambiar para lograr el mismo efecto?
Recién encontré este script así que ya tengo todos los videos que quiero, solo me faltan todas las imágenes publicadas.
 
willowbranch
Ya está funcionando. Nunca me puse a agregar el soporte del viejo Bunkr a mi build de VM2, así que está bueno tenerlo ahí ahora.
 
Podés pasar el mouse sobre el botón de descarga y desmarcar los proveedores de video para un post que tenga, digamos, videos de bunkr e imágenes de goonbox. Si no, podés ir a Tampermonkey Settings->Downloads BETA->Whitelisted File Extensions y quitar todas las extensiones de video, pero eso afectaría todos tus scripts que usen la Browser API para descargas.
¡Genial! :)
Nueva versión b06:
https://github.com/courtneydax/sc-postdl/raw/refs/heads/main/scpostdl-beta.user.js
Versión VM vm06:
https://github.com/courtneydax/sc-postdl/raw/refs/heads/main/scpostdl-vm.user.js
- Arreglos de Filester (antes no había tenido oportunidad de probar la migración de posts de filester, así que ahora debería estar bien)
 
willowbranch
Parece que Filester cambió un par de cosas más después de mi arreglo original. Tuve que actualizar mi propia versión también porque su validación de servidor rechazaba respuestas de API como fsc3.cdn.cr.
Los links individuales /d/ ya funcionan en b06 y vm06, pero los álbumes /f/ siguen volviendo al viejo formato de URL directa: https://fsc1.cdn.cr/v/
Después reintenta la misma URL /v/ en fsc2 y fsc3, pero ahora todos devuelven 404.
Los slugs de álbum necesitan usar el mismo resolver V2 que los links /d/ individuales: /v2/?token=&download=true&n=
Probado con b06 en TM/Firefox y vm06 en VM/Firefox.
 
¿Alguno sabe si hay un límite de tamaño por post? Intenté descargar los 5 videos turbo de acá: https://simpcityopen.com/posts/6435/, pero no aparece nada después de que termina el proceso de descarga. No aparece ninguna carpeta zip ni nada.
 
No hay límite de tamaño por post, pero esos cinco videos Turbo pesan alrededor de 3 GB en total. Si la opción ZIP está activada, el navegador puede fallar al crear un archivo tan grande, así que al final no se guarda nada. Probá desmarcar la opción ZIP y descargarlos como archivos separados.
 
iNeed2Sleep
b07/vm07 ya está publicado con esos arreglos, pero probablemente suba otra actualización este fin de semana pendiente de algunas pruebas. Si todo sale bien, lo voy a empaquetar para subirlo al principal. Voy a dejar la versión VM en mi repo, no sé si POKI quiere darle soporte oficial a VM en el repo principal.
 
No sé si es un problema nuevo o si recién lo noté, pero las imágenes de Goonbox en tamaño completo no se están descargando.
 
willowbranch
Las llamadas a la API de Goonbox están devolviendo 403 en Firefox porque GM_xmlhttpRequest desde la pestaña de SimpCity no incluye las cookies de primera parte requeridas de Goonbox/Cloudflare.
Lo resolví con un pequeño puente same-origin. Agregá // @match https://goonbox.cr/*, y después usá una pestaña de Goonbox inactiva abierta con GM_openInTab. La pestaña de Goonbox lee las rutas de API en cola desde el almacenamiento GM, las solicita con fetch(url, { credentials: 'include' }), y escribe la respuesta JSON de vuelta a través de GM_setValue/GM_getValue.
La solicitud directa a la API existente puede quedarse como el primer intento. Si devuelve 403, datos vacíos o JSON inválido, mandá la misma solicitud a través del puente. Usalo tanto para /api/images/{id} como para /api/albums/{slug}/images?page={page}, y reutilizá la misma pestaña auxiliar para todo el lote.
Mantené el identificador de pestaña devuelto por GM_openInTab y cerralo con tab.close() unos segundos después de la última solicitud. window.close() solo no siempre funcionó en Chrome.
 
Igual acá. Pasó lo mismo antes esta semana y lo arreglé actualizando el script manualmente. Pero esta vez no funcionó.
 
iNeed2Sleep
Buena captura. Lo incluí en b08/vm08. Todavía me falta hacer algunas pruebas de filester, estuve ocupado durante el fin de semana y la semana. La vida real a veces es un dolor, jaja.
 
willowbranch
No hay problema, la vida real es lo primero.
Probé b08/vm08. Chrome + Tampermonkey y Firefox + Violentmonkey funcionaron ambos y descargaron las imágenes originales de Goonbox.
Firefox + Tampermonkey sigue dando problemas, sin embargo.
En un post que contenía imágenes JPGX y https://goonbox.cr/a/apX4HA, las imágenes JPGX se resolvieron de inmediato, pero la solicitud a la API de Goonbox devolvió el 403 esperado. Después esperó casi exactamente 20 segundos y el álbum no se resolvió, así que parece que la pestaña helper nunca envió un heartbeat de "ready" fresco. Los posts de imagen única también pueden caer a la miniatura de menor resolución cuando pasa esto.
Lo que me funcionó en mi versión fue abrir la URL real de la imagen o álbum de Goonbox en lugar de https://goonbox.cr/, con un marcador de bridge agregado a la URL. El bridge worker solo se inicia cuando ese marcador está presente. Reutiliza una pestaña helper inactiva mientras hay solicitudes activas, cancela el temporizador de cierre cada vez que empieza una nueva solicitud, y solo cierra la pestaña unos segundos después de que la cola y las solicitudes activas estén vacías.
También limpiaría el valor "ready" viejo antes de abrir el helper. Si no llega un heartbeat fresco en 20 segundos, cerraría el handle de la pestaña existente y reintentaría abrirla una vez antes de activar el circuit breaker. El fetch same-origin también puede reintentar unas veces por si Cloudflare todavía está cargando.
 
Es solo un detalle menor, pero ¿hay alguna forma de verificar que todo en la página se está descargando sin tener que revisar cada archivo zip uno por uno y compararlo con los posts de la página?
 
Creo que al final pone la reacción peepolove, así que si está esa reacción, el post está descargado (¿completo?) ¿no?
 
Debes iniciar sesión o registrarte para responder aquí.
Atrás
Arriba