4 Commits

Include renames

Author	SHA1	Message	Date
foxyzandClaude Opus 5.5	6b10cae4e6	Protocol 12: Up next (a shared queue) and where the video comes from ... Up next: a server-side queue anyone edits by item id (add at end or next, move, remove, play now, skip); each item says who added it and how it plays. At the real end the first item swaps in after the end card's countdown, put up by whoever can (its adder for through-me links and files, someone with access for Jellyfin, else anyone); items that can't play are skipped with the reason. The next item's link is resolved ahead. Greyed "Continues with" episodes below. A chip with the controls opens it as a popover (leaf_widgets, local path dependency for now); "Add to queue" next to Put it up everywhere. Delivery: the server measures the source's rate, the media's bitrate and each member's read rate; the members card shows a source line (who passes it on, through what, keeping up or not, source left) and each member's route and buffer. A slow source is told once per media. A failed server fetch is announced to everyone. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-11 06:40:26 +03:00
foxyzandClaude Opus 5.5	fe5d6c3b3f	Relay HLS/DASH-only pages as pieces tracks (protocol 11) ... A track can be served as pieces: the server writes a VOD playlist whose entries are its own piece URLs (segments, init maps, AES-128 keys; byte ranges folded in; yt-dlp's DASH fragments become the same list). A piece buffer per track fills like the byte buffer. Picks a single file, then a split byte pair, then pieces. DRM, live, master playlists are refused. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-09 23:35:31 +03:00
foxyzandClaude Opus 5.5	b038706dff	Protocol 11: split-track relay (YouTube video+audio), chunked upstream reads ... Relayed media can carry 2-4 byte tracks (video, audio): yt-dlp picks a split pair when no single-file format exists (h264 first), the source channel serves each track, the server keeps a buffer per track (budget split by size, 8 MiB floor) and viewers open an mpv edl:// of the track URLs. Expired URLs re-resolve once for all tracks. Upstream GETs are cut into <= http_chunk_size (10 MiB) ranges: YouTube throttles larger ones. Live streams and DRM are refused; HLS/DASH pieces are a follow-up. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-09 19:59:41 +03:00
foxyzandClaude Opus 5.5	e7f33b5dc3	Relay: a member's media through the server's buffer (proto 8) ... Viewers who cannot reach the media get it through the server: a file on any member's computer, a link passed on by a member ("Through me") or fetched by the server ("Server fetches it", password-protected servers only), and Jellyfin items for guests without an account, sourced by whoever put them up with their own sign-in (or a pasted link's key), which never leaves their machine. Fixes guests on a dedicated server without a Jellyfin login being blocked. The source dials /r/.../source (works behind NAT) and answers pulls with an adaptive in-flight window (2 x rate x min RTT, 256 KiB..8 MiB). The server keeps a memory-only buffer of 1 MiB slices sized like a viewer's mpv buffer (pinned head/tail, 64 MiB back, 256 MiB ahead), fills it with one sequential pull at a time (blocked viewers first, newest request only), fetches nothing while nobody watches through it, and drops it on the next swap or stop. Measured with mpv through shaped links (tool/relay_e2e.dart): 400 Mbit/s seeks ~0.03 s; 40 Mbit/s no stalls, 3 viewers cost the source ~1x the bytes. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-08 20:41:01 +03:00