animekai.be fronted two server backends per episode: megaplay.buzz
(same player/CDN family as hianime — 403s our egress IP) and
my.1anime.site (direct progressive MP4, independent CDN — verified
serving our IP at ~2.4MB/s). This is the rescue path around the
MegaPlay Cloudflare block, per the ani-cli #1945/#1918 work.
- providers/animekai.py: standard interface, per-episode backend
dispatch (1anime first, then megaplay), same listed-but-dead ->
raise semantics as hianime. All endpoints ride the shared TTL cache
(no re-fetching on repeat UI hits).
- upstream.py: megaplay_master() moved out of hianime — the MegaPlay
chain (embed -> data-id -> getSourcesNew -> enc decrypt -> CDN proof)
is now shared by every provider fronting that player.
- app.py: /stream forwards Range for progressive files (206 +
Content-Range passthrough, partial bodies never LRU-cached, 8MB cap
on the parallel path so a 250MB MP4 can't pin RAM). api_stream
reports hls=true/false from the URL — the player kind is a property
of the URL, so future stream types slot in without app changes.
- app.js: hls===false -> native <video> (existing Range-seeking),
hls.js path untouched.
- run.sh: ANI_SOURCE=animekai,hianime,anidb,anikoto (revert to the old
chain when the MegaPlay block lifts).
- tests: test_animekai.py (offline: interface, enc decrypt, /stream
Range via monkeypatched network) + test_animekai_live.py (opt-in
ANI_LIVE=1 end-to-end, skipped by default so the suite never touches
animekai.be).
