Files

Simon 2adde22514 Fix broken-playback providers (wowxxx, porndish, noodlemagazine) and a shared 429 retry bug

- wowxxx: site migrated wow.xxx -> wowxxx.to; update BASE_URL and stop
  pinning Version::HTTP_11, which mismatched the TLS handshake's h2 ALPN
  and got scored as a bot (same root cause already fixed for jable.tv)
- porndish: recognize playmogo.com iframes as the same Doodstream-clone
  embed protocol as myvidplay.com (confirmed live) instead of falling
  through to a naive branch that pointed formats[0] at the unresolved,
  Cloudflare-protected iframe URL; kept in sync in both providers/porndish.rs
  and proxies/porndish.rs since single-provider builds can't share code
  across that boundary
- noodlemagazine: entity-decode the thumb URL pulled from a raw
  data-original="..." attribute - undecoded `&amp;` in the query string
  was getting the CDN to 400 the request
- requester.rs: cap the previously-unbounded HTTP 429 retry loop at 3
  attempts before falling through to the existing Jina/FlareSolverr
  fallback, instead of retrying forever with no bound

Also fixes check.py: the thumbnail check never consulted the
CF-protected-host allowlist (only the page-url check did), and adds
missav.ws/surrit.com, tik.porn/image-cdn.tik.porn, vrporn.com, and
www.wowxxx.to/img.wowxxx.to to that allowlist - all four providers
already work fine through the app's real client; the checker's plain
probes (and its yt-dlp invocation, which never applies a channel's
declared ytdlpCommand impersonation flag) just can't replicate that.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QTqf6orbHZ9rFFpVpcgzcR

2026-09-22 19:42:53 +00:00

hottubapp

docs

2026-04-03 17:20:11 +00:00

architecture.md

docs and prompt

2026-04-10 22:57:27 +00:00

provider-catalog.md

Fix broken-playback providers (wowxxx, porndish, noodlemagazine) and a shared 429 retry bug

2026-09-22 19:42:53 +00:00

provider-playbook.md

more providers

2026-09-07 15:25:03 +00:00

README.md

more providers

2026-09-07 15:25:03 +00:00

README.md

Hottub Docs

This folder is the fastest handoff path for anyone adding or repairing a channel.

Start here:

Read architecture.md for the server flow, request lifecycle, and core types.
Read provider-playbook.md — its top "Best Practices (Living)" section is the cross-cutting rule set to internalize first, then follow the rest of the playbook for the exact process to add a new provider or proxy.
Use provider-catalog.md to find the closest existing implementation to copy.
Use docs/hottubapp/*.html when you need the client-facing API contract for status, videos, or uploaders.
Only then touch prompts/new-channel.md; it assumes the docs above exist.

Recommended local workflow:

cargo check -q
HOT_TUB_PROVIDER=<channel_id> cargo check -q
HOT_TUB_PROVIDER=<channel_id> cargo run --features debug

Useful runtime baseline:

DATABASE_URL=hottub.db
RUST_LOG=info
PROXY=0
BURP_URL=http://127.0.0.1:8081
FLARE_URL=http://127.0.0.1:8191/v1
DOMAIN=127.0.0.1:18080
DISCORD_WEBHOOK=

Key facts:

Hottub is a Rust ntex server with providers under src/providers/.
build.rs controls compile-time provider registration.
/api/videos is the main provider execution path.
/proxy/... exists for sites whose direct media or thumbnails need a redirect/proxy layer.
Only three providers currently implement /api/uploaders: hsex, omgxxx, and vjav.
Uploader IDs should be namespaced like <channel>:<site-local-id> so /api/uploaders can route directly.