mirror of
https://github.com/PR0M3TH3AN/bitvid.git
synced 2026-10-27 07:52:24 +00:00
thePR0M3TH3ANandClaude Opus 5
99f8e88969
On mobile a bitvid share link opens with no user gesture, so the browser refuses autoplay. bitvid handled that correctly -- it showed "Press play to start the hosted video." and armed a no-stall watchdog to wait -- but the 3s start timeout kept running underneath and fired anyway. For a video with both a hosted URL and a magnet that meant: Press play to start the hosted video. Switching to WebTorrent... The element was reset out from under the prompt the viewer was about to act on, and the swarm (often seedless, the webseed being the very URL we just abandoned) played nothing. Desktop usually hides this because an established Media Engagement score lets autoplay through, so the same link plays there. A blocked autoplay is not a stalled source. Suspend the start timeout while we are waiting on a user gesture and let the attempt settle on its own -- it resolves when they press play, or when a real media error or stall fires. The guard is cleared on the `play` gesture so a genuine stall afterwards still fails over normally. Reproduced on an emulated phone against the reported video (v.nostr.build/1eNLjw5el05Uc3KU.mp4, magnet with a webseed): before, statuses end "Press play..." then "Switching to WebTorrent..." with the P2P path entered; after, they end at "Press play..." and playback starts on tap. The new tests fail 2/4 without the guard. Note for future test authors: createSession() overwrites any playbackStartTimeout passed in its options with the service's value, so a per-session override is silently ignored -- set it on the PlaybackService constructor or the test races the real 3s default and proves nothing. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>