c7ae89fc37
melonstube.com started fronting itself with Cloudflare bot management (a real Turnstile challenge) since this provider was written, so the shared Requester's Firefox151 emulation got blocked on every path and the provider returned 0 items. A/B-probed several browser TLS fingerprints live: Chrome120/124 pass the plain listing pages but still 403 on /category/* and the /searching/by-form search POST, while Safari18 passes everywhere. Listing/search fetches now try a dedicated Safari18-emulated client first and fall back to the shared Requester if Cloudflare's rules change again (same pattern as lulustream.rs/doodstream.rs). Also fixes get_videos ignoring perPage entirely (always returned the full ~120-card page); it now truncates to the requested size. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QTqf6orbHZ9rFFpVpcgzcR
hottub
Rust based hottub server
the following URL:
build it yourself
Get, Build and Host the docker image:
git clone https://gitea.spacemoehre.de/simon/hottub
sudo docker build hottub
cd hottub && cargo build --release
nano docker-compose.yml # adjust compose file
sudo docker compose up -d
Verify setup, replace the url with your setup url
curl -v http://127.0.0.1
->
* Trying 127.0.0.1:80...
* Connected to 127.0.0.1 (127.0.0.1) port 80
> GET / HTTP/1.1
> Host: 127.0.0.1:80
> User-Agent: curl/8.5.0
> Accept: */*
>
< HTTP/1.1 302 Found
< content-length: 0
< location: hottub://source?url=127.0.0.1:80
< date: Mon, 29 Sep 2025 14:58:15 GMT
<
* Connection #0 to host 127.0.0.1 left intact
make sure that you get a code 302 to a hottub:// url
Update via git pull
To Update (i.e. for new supported sites) do
cd /path/to/hottub && git pull && cargo build --release && sudo docker container restart hottub