Guide Forum Post Downloader - Tampermonkey Script

I had to change a TamperMonkey setting to get that back. I think it was in the 'Downloads BETA' section and it was 'Download Mode:' I changed the setting in the dropdown box to 'Native'
 
A couple of releases for anyone willing to test:
Beta version 3.21.b03 - fix for old bunkr links (cdn.bunkr.*):
https://github.com/courtneydax/sc-postdl/blob/main/scpostdl-beta.user.js
Violentmonkey Version 3.21.vm02 (bunkr fix included):
https://github.com/courtneydax/sc-postdl/blob/main/scpostdl-vm.user.js
xandominiriNeed2Sleep
Violentmonkey version tested in Chrome and Firefox (sideload with developer edition), and should work for the most part but you'll need the v2.45.5 beta version of ViolentMonkey. Firefox/VM still having issues with direct blob downloads, but should work for flat downloads.
Not sure if I'll support VM going forward since I don't use it personally, but I at least wanted to provide a base for VM support on 3.21. Plus, with the latest updates, there aren't a lot of changes needed from the main script. Try it out and let me know.
 
Weird, I guess I had to restart my browser, cause it was suddenly working again.
 
willowbranch
Tested 3.21.b04 with Firefox/Tampermonkey, and the old Bunkr links work correctly.
I also tested 3.21.vm03 with Firefox/Violentmonkey, but old Bunkr links do not work there. Both regular and direct downloads fail.
The resolver finds the data-file-id, but the _001_v2 API response is returned as [object HTMLDocument]. JSON.parse then fails, and the script falls back to the dead legacy CDN URL, which is skipped as an HTML/maintenance response.
Regular download:
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)
Direct download has the same problem with a numbered legacy CDN:
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)
So it looks like the legacy-link detection itself works in VM, but the Bunkr API request returns an HTML document instead of JSON.
 
iNeed2Sleep
Fixed in vm04. I actually grabbed it pretty much verbatim from your XenForoPostDownloader-3.17-VM2 script.
New in vm05. From that same script I added the mobile support back in since that could be lifted in pretty much the same way, although the styling was gated behind isMobile so the desktop look isn't affected.
 
Thanks for the scrip!
Is there an easy way changing this to only download images?
I assume one of the ways are to remove the whitelisted file extensions in Tampermonkey, but that would affect other scripts, so I'd prefer to not do that unless needed. So is there a setting or a line in the script that one can change to get the same effect?
Just found this script so I got all the videos I want, just missing all the images posted.
 
willowbranch
It's working now. I never got around to adding the old Bunkr support to my VM2 build, so it's nice to have it there now.
 
You can hover over the download button and uncheck the video providers for a post that has, say, bunkr videos and goonbox images. Otherwise, you can go to Tampermonkey Settings->Downloads BETA->Whitelisted File Extensions and remove all the video extensions, but that would affect all your scripts that use Browser API for downloads.
Awesome. :)
New version b06:
https://github.com/courtneydax/sc-postdl/raw/refs/heads/main/scpostdl-beta.user.js
VM version vm06:
https://github.com/courtneydax/sc-postdl/raw/refs/heads/main/scpostdl-vm.user.js
- Filester fixes (haven't had a chance to test filester post migration before, so should be good now)
 
willowbranch
Looks like Filester changed a couple more things after my original fix. I had to update my own version too because its server validation rejected API responses such as fsc3.cdn.cr.
Single /d/ links are working in b06 and vm06 now, but /f/ albums still switch back to the old direct URL format: https://fsc1.cdn.cr/v/
It then retries the same /v/ URL on fsc2 and fsc3, but they all return 404 now.
The album slugs need to use the same V2 resolver as single /d/ links: /v2/?token=&download=true&n=
Tested with b06 on TM/Firefox and vm06 on VM/Firefox.
 
There isn't a size limit per post, but those five Turbo videos are around 3 GB in total. If the ZIP option is enabled, the browser may fail while creating such a large archive, so nothing gets saved at the end. Try unchecking the ZIP option and downloading them as separate files instead.
 
iNeed2Sleep
b07/vm07 is up with those fixes, but I'll probably push another update this weekend pending some tests. If all good then I'll package it up to push to the main one. I'll leave the VM version on my repo, I don't know if POKI want's to officially support VM in the main repo.
 
Not sure if this is a new issue or if I just noticed it, but full size Goonbox images are not being downloaded.
 
willowbranch
Goonbox API calls are returning 403 in Firefox because GM_xmlhttpRequest from the SimpCity tab does not include the required first-party Goonbox/Cloudflare cookies.
I worked around it with a small same-origin bridge. Add // @match https://goonbox.cr/*, then use one inactive Goonbox tab opened with GM_openInTab. The Goonbox tab reads queued API paths from GM storage, requests them with fetch(url, { credentials: 'include' }), and writes the JSON response back through GM_setValue/GM_getValue.
The existing direct API request can stay as the first attempt. If it returns 403, empty data or invalid JSON, send the same request through the bridge. Use it for both /api/images/{id} and /api/albums/{slug}/images?page={page}, and reuse the same helper tab for the whole batch.
Keep the tab handle returned by GM_openInTab and close it with tab.close() a few seconds after the last request. window.close() alone didn’t always work in Chrome.
 
Same here. It did this earlier this week and I fixed it by manually updating the script. But that didn't work this time.
 
iNeed2Sleep
Good catch. Rolled it into b08/vm08. I still have to do some filester testing, got busy over the weekend and during the week. Real life can be a pain sometimes, lol.
 
willowbranch
No worries, real life comes first.
I tested b08/vm08. Chrome + Tampermonkey and Firefox + Violentmonkey both worked and downloaded the original Goonbox images.
Firefox + Tampermonkey is still having trouble, though.
On a post containing JPGX images and https://goonbox.cr/a/apX4HA, the JPGX images resolved immediately, but the Goonbox API request returned the expected 403. It then waited almost exactly 20 seconds and the album failed to resolve, so it looks like the helper tab never sent a fresh ready heartbeat. Single-image posts can also fall back to the lower-resolution thumbnail when this happens.
What worked in my version was opening the actual Goonbox image or album URL instead of https://goonbox.cr/, with a bridge marker added to the URL. The bridge worker only starts when that marker is present. It reuses one inactive helper tab while requests are active, cancels the close timer whenever a new request starts, and only closes the tab a few seconds after the queue and active requests are both empty.
I’d also clear the old ready value before opening the helper. If no fresh heartbeat arrives within 20 seconds, close the existing tab handle and retry opening it once before enabling the circuit breaker. The same-origin fetch can also retry a few times in case Cloudflare is still loading.
 
This is just a small thing, but is there any way to verify that everything on the page is being downloaded without going through each zip file and checking one by one and comparing it to the posts on the page?
 
I think it does the peepolove reaction at the end, so if that reaction is there then the post is downloaded (in full?) ?
 
You must log in or register to reply here.
Back
Top