4 Commits

Include renames

Author	SHA1	Message	Date
foxyzandClaude Opus 5.5	4ab37c55cf	Sessions leave redacted logs; viewers wait for a member relay's source before opening it ... Logs: one redaction pass (query strings to names, member tokens, passwords, cookies, auth headers) for every line; daily files with size and age caps in the app (hosted server included) and the dedicated server (--log-dir); swaps, relay channels, per-member /r /m /j outcomes, server fetches, mpv load errors, yt-dlp runs. Settings > About: Copy diagnostics, Open logs folder. Bilibili through someone else: the viewer opened /r/ before the source dialled in; the server holds that request and mpv gives up after 5 s ("could not be opened"). Viewers now open a member relay once it is live, the putter starts its source before its own player, and track sizes are read in parallel. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-12 19:05:32 +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	745717a4a0	yt-dlp for page links in every Link mode; app icon and Linux launcher entry ... yt-dlp: a managed, checksum-verified, daily-updated yt-dlp in the app and the dedicated server (--[no-]yt-dlp, --yt-dlp-dir). Pasted links are probed: direct files stay links, pages are resolved for title, uploader, duration and thumbnail. Everyone fetches it: mpv's ytdl hook on the managed copy. I pass it on / the server fetches it: the best single-file format, re-resolved once when its URL expires. Relay names never split the /r/ path; viewers of server-fetched pages wait for the relay to go live. No wire change. Icon: two stars orbiting a play button (assets/icon/icon.svg, PNGs, the Windows .ico). GTK app id moe.senkochan.watch_together; release builds install their .desktop file and icons into ~/.local/share so Wayland shows the icon; the window icon is set for X11. README shows the icon. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-09 18:21:22 +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