Guia Forum Post Downloader - Script do Tampermonkey

Tive que mudar uma configuração do TamperMonkey pra voltar a funcionar. Acho que era na seção 'Downloads BETA' e era 'Download Mode:' Mudei a opção no dropdown pra 'Native'
 
Algumas versões pra quem quiser testar:
Versão beta 3.21.b03 - correção pros links antigos do bunkr (cdn.bunkr.*):
https://github.com/courtneydax/sc-postdl/blob/main/scpostdl-beta.user.js
Versão Violentmonkey 3.21.vm02 (com correção do bunkr incluída):
https://github.com/courtneydax/sc-postdl/blob/main/scpostdl-vm.user.js
xandominiriNeed2Sleep
Versão Violentmonkey testada no Chrome e Firefox (sideload com a edição developer), e deve funcionar na maior parte, mas você vai precisar da versão beta v2.45.5 do ViolentMonkey. Firefox/VM ainda tem problemas com downloads diretos de blob, mas deve funcionar pra downloads simples.
Não sei se vou continuar dando suporte ao VM já que eu mesmo não uso, mas pelo menos quis dar uma base pro suporte de VM na 3.21. Além disso, com as últimas atualizações, não são necessárias muitas mudanças em relação ao script principal. Testem e me avisem.
 
Estranho, acho que tive que reiniciar o navegador, porque de repente voltou a funcionar.
 
willowbranch
Testei 3.21.b04 com Firefox/Tampermonkey, e os links antigos do Bunkr funcionam corretamente.
Também testei 3.21.vm03 com Firefox/Violentmonkey, mas os links antigos do Bunkr não funcionam lá. Tanto downloads normais quanto diretos falham.
O resolver encontra o data-file-id, mas a resposta da API do _001_v2 vem como [object HTMLDocument]. JSON.parse então falha, e o script cai de volta pra URL morta do CDN legado, que é pulada como resposta de HTML/manutenção.
Download 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)
O download direto tem o mesmo problema com um CDN legado 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)
Então parece que a detecção de link legado em si funciona no VM, mas a requisição da API do Bunkr retorna um documento HTML em vez de JSON.
 
iNeed2Sleep
Corrigido na vm04. Na verdade peguei quase igualzinho do seu script XenForoPostDownloader-3.17-VM2.
Novidade na vm05. Do mesmo script eu coloquei de volta o suporte mobile já que dava pra pegar praticamente do mesmo jeito, embora o estilo estivesse condicionado ao isMobile então o visual desktop não é afetado.
 
Valeu pelo script!
Tem alguma forma fácil de mudar isso pra só baixar imagens?
Eu imagino que uma das formas seja remover as extensões de arquivo permitidas no Tampermonkey, mas isso afetaria outros scripts, então prefiro não fazer isso a menos que seja necessário. Então tem alguma configuração ou linha no script que dá pra mudar pra ter o mesmo efeito?
Acabei de achar esse script então já peguei todos os vídeos que eu queria, só tô faltando todas as imagens postadas.
 
willowbranch
Agora tá funcionando. Nunca tinha arrumado tempo pra adicionar o suporte antigo do Bunkr no meu build VM2, então é bom ter isso aí agora.
 
Você pode passar o mouse sobre o botão de download e desmarcar os provedores de vídeo pra um post que tenha, tipo, vídeos do bunkr e imagens do goonbox. Senão, dá pra ir em Tampermonkey Settings->Downloads BETA->Whitelisted File Extensions e remover todas as extensões de vídeo, mas isso afetaria todos os seus scripts que usam a Browser API pra downloads.
Maneiro. :)
Nova versão b06:
https://github.com/courtneydax/sc-postdl/raw/refs/heads/main/scpostdl-beta.user.js
Versão VM vm06:
https://github.com/courtneydax/sc-postdl/raw/refs/heads/main/scpostdl-vm.user.js
- Correções do Filester (não tinha tido chance de testar a migração de posts do filester antes, então agora deve estar de boa)
 
willowbranch
Parece que o Filester mudou mais umas coisas depois do meu fix original. Tive que atualizar minha própria versão também porque a validação do servidor deles rejeitava respostas de API como fsc3.cdn.cr.
Os links /d/ individuais já estão funcionando no b06 e vm06, mas os álbuns /f/ ainda voltam pro formato antigo de URL direta: https://fsc1.cdn.cr/v/
Depois ele tenta de novo a mesma URL /v/ no fsc2 e fsc3, mas agora todos retornam 404.
Os slugs de álbum precisam usar o mesmo resolver V2 dos links /d/ individuais: /v2/?token=&download=true&n=
Testado com b06 no TM/Firefox e vm06 no VM/Firefox.
 
Não tem limite de tamanho por post, mas esses cinco vídeos Turbo somam uns 3 GB no total. Se a opção ZIP estiver ativada, o navegador pode falhar ao criar um arquivo tão grande, e no final nada é salvo. Tenta desmarcar a opção ZIP e baixar como arquivos separados em vez disso.
 
iNeed2Sleep
O b07/vm07 já tá no ar com essas correções, mas provavelmente eu vou lançar outra atualização esse fim de semana dependendo de uns testes. Se tudo der certo, eu empacoto e mando pro repo principal. Vou deixar a versão VM no meu repo, não sei se o POKI quer dar suporte oficial pra VM no repo principal.
 
Não sei se é um problema novo ou se eu só percebi agora, mas as imagens do Goonbox em tamanho real não estão sendo baixadas.
 
willowbranch
As chamadas da API do Goonbox estão retornando 403 no Firefox porque GM_xmlhttpRequest da aba do SimpCity não inclui os cookies first-party do Goonbox/Cloudflare necessários.
Contornei isso com uma pequena ponte same-origin. Adicione // @match https://goonbox.cr/*, e depois use uma aba do Goonbox inativa aberta com GM_openInTab. A aba do Goonbox lê os caminhos de API na fila do armazenamento GM, solicita eles com fetch(url, { credentials: 'include' }), e escreve a resposta JSON de volta por GM_setValue/GM_getValue.
A requisição direta de API existente pode continuar sendo a primeira tentativa. Se retornar 403, dados vazios ou JSON inválido, envie a mesma requisição pela ponte. Use isso tanto pra /api/images/{id} quanto pra /api/albums/{slug}/images?page={page}, e reaproveite a mesma aba auxiliar pro lote inteiro.
Mantenha o identificador de aba retornado por GM_openInTab e feche com tab.close() alguns segundos após a última requisição. Só window.close() nem sempre funcionou no Chrome.
 
Aqui também. Isso aconteceu mais cedo essa semana e eu resolvi atualizando o script manualmente. Mas dessa vez não funcionou.
 
iNeed2Sleep
Boa pegada. Incluí no b08/vm08. Ainda tenho que fazer uns testes de filester, fiquei ocupado no fim de semana e durante a semana. A vida real às vezes é um saco, kkk.
 
willowbranch
Sem problemas, a vida real vem primeiro.
Testei b08/vm08. Chrome + Tampermonkey e Firefox + Violentmonkey funcionaram e baixaram as imagens originais do Goonbox.
Firefox + Tampermonkey ainda está com problema, porém.
Num post contendo imagens JPGX e https://goonbox.cr/a/apX4HA, as imagens JPGX resolveram na hora, mas a requisição da API do Goonbox retornou o 403 esperado. Aí ele esperou quase exatamente 20 segundos e o álbum falhou em resolver, então parece que a aba helper nunca mandou um heartbeat de "ready" novo. Posts de imagem única também podem cair pra miniatura de resolução mais baixa quando isso acontece.
O que funcionou na minha versão foi abrir a URL real da imagem ou álbum do Goonbox em vez de https://goonbox.cr/, com um marcador de bridge adicionado na URL. O bridge worker só inicia quando esse marcador está presente. Ele reaproveita uma aba helper inativa enquanto há requisições ativas, cancela o timer de fechamento sempre que uma nova requisição começa, e só fecha a aba alguns segundos depois que a fila e as requisições ativas estiverem vazias.
Eu também limparia o valor antigo de ready antes de abrir o helper. Se nenhum heartbeat novo chegar em 20 segundos, eu fecharia o handle da aba existente e tentaria abrir de novo uma vez antes de ativar o circuit breaker. O fetch same-origin também pode tentar de novo algumas vezes caso o Cloudflare ainda esteja carregando.
 
É só uma coisa pequena, mas tem algum jeito de verificar se tudo na página está sendo baixado sem precisar passar por cada arquivo zip um por um e comparar com os posts da página?
 
Acho que ele coloca a reação peepolove no final, então se essa reação estiver lá, o post foi baixado (completo?) né?
 
Voltar
Topo