ガイド Forum Post Downloader - Tampermonkeyスクリプト

TamperMonkeyの設定を変えたら戻った。多分「Downloads BETA」セクションの「Download Mode:」だったと思う。ドロップダウンで「Native」に変更した
 
テストしたい人向けにいくつかリリース:
ベータ版3.21.b03 - 古いbunkrリンク（cdn.bunkr.*）の修正:
https://github.com/courtneydax/sc-postdl/blob/main/scpostdl-beta.user.js
Violentmonkey版3.21.vm02（bunkr修正込み）:
https://github.com/courtneydax/sc-postdl/blob/main/scpostdl-vm.user.js
xandominiriNeed2Sleep
Violentmonkey版はChromeとFirefox（デベロッパーエディションでサイドロード）でテスト済み、大体は動くはずだけどViolentMonkeyのv2.45.5ベータ版が必要。Firefox/VMは直接blobダウンロードにまだ問題があるけど、通常のダウンロードは動くはず。
自分では使ってないのでVMを今後もサポートするかわからないけど、少なくとも3.21でのVMサポートの土台は提供したかった。それに最近の更新で、メインスクリプトからそんなに変更は要らない。試して感想教えて。
 
変だね、多分ブラウザを再起動しないといけなかったみたい、急にまた動くようになった。
 
willowbranch
3.21.b04をFirefox/Tampermonkeyでテストしたら、古いBunkrリンクは正しく動く。
3.21.vm03もFirefox/Violentmonkeyでテストしたけど、そこでは古いBunkrリンクは動かない。通常ダウンロードも直接ダウンロードも両方失敗する。
リゾルバーはdata-file-idを見つけるけど、_001_v2のAPIレスポンスが[object HTMLDocument]として返ってくる。それでJSON.parseが失敗して、スクリプトは死んでるレガシーCDN URLにフォールバックし、HTML/メンテナンスレスポンスとしてスキップされる。
通常ダウンロード:
コード: 
[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)
直接ダウンロードも番号付きレガシーCDNで同じ問題:
コード: 
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)
つまりレガシーリンク検出自体はVMで動いてるけど、Bunkr APIリクエストがJSONの代わりにHTMLドキュメントを返してるみたい。
 
iNeed2Sleep
vm04で修正済み。実はほぼそのまま君のXenForoPostDownloader-3.17-VM2スクリプトから持ってきた。
vm05での新機能。同じスクリプトからモバイルサポートを戻した、ほぼ同じ方法で持ってこれたから。ただスタイルはisMobileで制御されてたのでデスクトップの見た目には影響ない。
 
スクリプトありがとう!
画像だけダウンロードするように簡単に変更する方法はある?
Tampermonkeyのホワイトリスト拡張子を削除するのが一つの方法だと思うけど、それだと他のスクリプトにも影響しちゃうから、必要ない限りやりたくないんだ。だから、同じ効果を得るためにスクリプト内で変更できる設定や行はある?
このスクリプトを見つけたばかりだから欲しい動画は全部揃ってて、投稿された画像だけ足りない状態。
 
willowbranch
今は動いてる。自分のVM2ビルドに古いBunkrサポートを追加する暇がなかったから、これで入って良かった。
 
ダウンロードボタンにマウスを乗せて、bunkrの動画とgoonboxの画像がある投稿みたいなものに対して動画プロバイダーのチェックを外せるよ。それか、Tampermonkey Settings->Downloads BETA->Whitelisted File Extensionsに行って動画の拡張子を全部消す方法もあるけど、それだとBrowser APIでダウンロードする他のスクリプト全部に影響しちゃう。
いいね。:)
新バージョン b06:
https://github.com/courtneydax/sc-postdl/raw/refs/heads/main/scpostdl-beta.user.js
VMバージョン vm06:
https://github.com/courtneydax/sc-postdl/raw/refs/heads/main/scpostdl-vm.user.js
- Filesterの修正(前はfilesterの投稿移行をテストする機会がなかったから、今回で直ってるはず)
 
willowbranch
俺の最初の修正の後、Filesterはさらにいくつか変更したみたい。俺自身のバージョンも更新しないといけなかった、サーバー検証がfsc3.cdn.crみたいなAPIレスポンスを拒否してたから。
単体の/d/リンクはb06とvm06で今は動いてるけど、/f/アルバムはまだ古い直リンク形式に戻っちゃう: https://fsc1.cdn.cr/v/
それから同じ/v/URLをfsc2とfsc3で再試行するけど、今は全部404を返す。
アルバムのスラグは単体の/d/リンクと同じV2リゾルバを使う必要がある: /v2/?token=&download=true&n=
b06はTM/Firefox、vm06はVM/Firefoxでテスト済み。
 
1投稿あたりのサイズ制限ってあるか知ってる人いる? ここの5本のターボ動画をダウンロードしてみたんだけど: https://simpcityopen.com/posts/6435/、ダウンロード処理が終わっても何も出てこない。zipフォルダも何も表示されない。
 
投稿ごとのサイズ制限はないけど、その5本のターボ動画は合計で約3GBある。ZIPオプションが有効だと、ブラウザがそんな大きなアーカイブを作る際に失敗して、結局何も保存されないことがある。ZIPオプションのチェックを外して、個別のファイルとしてダウンロードしてみて。
 
iNeed2Sleep
b07/vm07がその修正込みで公開済みだけど、テスト次第で今週末にもう一つアップデートを出すかも。うまくいけばパッケージ化してメインの方にプッシュするよ。VM版は自分のリポジトリに置いとく、POKIがメインリポジトリでVMを公式サポートしたいかどうかわからないから。
 
新しい問題なのか、ただ今気づいただけなのかわからないけど、Goonboxのフルサイズ画像がダウンロードされてない。
 
willowbranch
FirefoxでGoonboxのAPI呼び出しが403を返してる、SimpCityタブからのGM_xmlhttpRequestに必要なGoonbox/Cloudflareのファーストパーティcookieが含まれてないから。
小さなsame-originブリッジで回避した。// @match https://goonbox.cr/*を追加して、それからGM_openInTabで開いた非アクティブなGoonboxタブを一つ使う。Goonboxタブは、GMストレージからキューされたAPIパスを読み取り、fetch(url, { credentials: 'include' })でリクエストして、JSONレスポンスをGM_setValue/GM_getValue経由で書き戻す。
既存の直接APIリクエストは最初の試みとして残していい。403、空データ、または無効なJSONが返ってきたら、同じリクエストをブリッジ経由で送る。/api/images/{id}と/api/albums/{slug}/images?page={page}の両方に使って、バッチ全体で同じヘルパータブを使い回す。
GM_openInTabから返されたタブハンドルを保持して、最後のリクエストの数秒後にtab.close()で閉じる。window.close()単体だとChromeでは必ずしも動作しなかった。
 
こっちも同じ。今週早くにも同じことが起きて、スクリプトを手動でアップデートして直した。でも今回はそれで直らなかった。
 
iNeed2Sleep
よく気づいたね。b08/vm08に組み込んだよ。まだfilesterのテストをしないといけないんだけど、週末も平日も忙しくてさ。リアルライフって時々めんどくさいよな、笑。
 
willowbranch
問題ないよ、リアルが最優先だから。
b08/vm08をテストしてみた。Chrome + TampermonkeyとFirefox + Violentmonkeyはどっちも動いて、オリジナルのGoonbox画像をダウンロードできた。
でもFirefox + Tampermonkeyはまだ問題ある。
JPGX画像とhttps://goonbox.cr/a/apX4HAを含むポストで、JPGX画像はすぐ解決したけど、Goonbox APIリクエストは予想通り403を返した。その後ほぼ正確に20秒待ってアルバムの解決に失敗したから、helperタブが新しいreadyハートビートを送れてないっぽい。単一画像のポストも、これが起きると低解像度のサムネイルにフォールバックすることがある。
自分のバージョンで効いたのは、https://goonbox.cr/じゃなくて実際のGoonbox画像/アルバムURLをブリッジマーカー付きで直接開くこと。ブリッジワーカーはそのマーカーがある時だけ動き出す。アクティブなリクエストがある間は非アクティブなhelperタブを再利用して、新しいリクエストが始まるたびにクローズタイマーをキャンセルして、キューとアクティブリクエストが両方空になってから数秒後にだけタブを閉じる。
helperを開く前に古いready値もクリアしたほうがいいと思う。20秒以内に新しいハートビートが来なかったら、既存のタブハンドルを閉じて一回だけ再オープンを試みてからcircuit breakerを有効にする。same-originのfetchも、Cloudflareがまだロード中の場合に備えて何回かリトライできるようにする。
 
ちょっとしたことなんだけど、ページ内の全部がダウンロードされてるか確認する方法ってある？いちいちzipファイルを1個ずつ開いてページの投稿と比較しなくても済む方法で。
 
最後にpeepoloveのリアクションが付く仕様だと思うから、そのリアクションがあればそのポストはダウンロード済み（完全に？）ってことだよね？
 
ここに返信するにはログインまたは新規登録が必要です。
戻る
トップ