Transition "Scheduled Live" → "Live Started" does not work on iPhone/Android

[ar9708]

How to reproduce:

1. Have a Scheduled Live coming up
2. Open the Live stream playback and find yourself with the "Schemalagt live, om fem minuter" (in 5 minutes)
3. Let the device fall asleep
4. Open the device again after 7 minutes (2 minutes after the live was scheduled and 3 minutes after it de facto started streaming)
5. Text on the Live stream playback is now "Schemalagt live, två minuter sedan" (2 minutes ago)
6. Bug:
   • Expected behavior — Live player checks if the stream is now live, if it is then stops waiting and starts playback
   • Actual behavior — No transition occur between waiting and playing, nothing happens (just stuck in waiting)

@claude Please think hard and deep, post an analysis on why this bug occurs.

[claude]

Claude finished @ar9708's task —— View job

---

Root Cause Analysis: Scheduled Live → Live Transition Bug

I've identified the root cause of this bug. Here's what's happening:

The Problem

When a scheduled live stream transitions to "live" while the device is asleep, the app fails to detect this state change and start playback. The countdown text updates correctly (showing "2 minutes ago"), but the video player remains stuck in the waiting state.

Technical Details

1. Countdown Timer (useTimeLeftUpdates.ts:27-29)

The countdown is updated via setInterval every 60 seconds:

const interval = setInterval(() => {
  setFormattedTimeLeft(formatDate(scheduledLiveDate));
}, 60 * 1000);

Issue: setInterval continues running in the background on mobile, which is why the countdown text updates correctly when the device wakes up.

2. Video State Polling (api/queries/videos.ts:103-105)

The video metadata is refetched every 10 seconds when isLive is true:

refetchInterval: (query: Query<Video, OwnTubeError, Video, QueryKey>) => {
  return query.state.data?.isLive ? LIVE_REFETCH_INTERVAL : 0;
},

Issue: This refetch interval is only active when isLive is already true. For scheduled live streams (state ID 4 or 5), isLive is false, so the refetch interval is set to 0.

3. Waiting State Logic (screens/VideoScreen/index.tsx:62)

The waiting state is determined by:

const isWaitingForLive = [4, 5].includes(Number(data?.state?.id));

State IDs:

• 4 = Waiting for live (scheduled but not started)
• 5 = Live is ending
• When the stream actually starts, the state changes to 1 (published) with isLive: true

4. React Query Refetch Behavior

React Query's default behavior includes refetching on window focus (web) and app foreground (mobile). However, looking at the query configuration in api/queries/videos.ts:93-109, the video query has:

• staleTime: 0 - Query is immediately stale
• refetchInterval - Only active when isLive is true
• No explicit disabling of foreground refetch

React Query should be refetching when the app comes to the foreground, but there's a critical issue...

Why the Bug Occurs

The bug happens due to a combination of factors:

1. Device goes to sleep with video in "waiting" state (state ID 4/5)
2. Stream starts (transitions to state ID 1 with isLive: true) while device is asleep
3. Device wakes up after the stream has started
4. React Query does refetch the video data when app comes to foreground
5. The video state updates from 4/5 to 1, and isLive becomes true
6. isWaitingForLive computed value in VideoScreen updates to false
7. This causes VideoView to receive isWaitingForLive: false

The critical issue is in VideoView.tsx:473:

{googleCastClient ? (
  <IcoMoonIcon name="Chromecast" size={72} color={colors.white80} />
) : isWaitingForLive ? (
  // Waiting overlay with preview image
) : (
  <Video ... />
)}

When isWaitingForLive changes from true to false, React unmounts the waiting overlay and mounts the <Video> component. However, the <Video> component's initialization logic at line 288-297 has a critical flaw:

const isInitialVideoLoadDone = useRef(false);

useEffect(() => {
  if (uri) {
    videoRef.current?.setSource({
      ...videoSource,
      uri,
      startPosition: Number(!isInitialVideoLoadDone.current ? Number(timestamp || 0) : currentTime) * 1000,
    });
    isInitialVideoLoadDone.current = true;
  }
}, [uri]);

The problem: When the <Video> component is first mounted (after transitioning from waiting state), if uri is undefined or not yet available, this effect doesn't run. Then, when uri becomes available, the effect runs and sets isInitialVideoLoadDone.current = true. But there's another issue...

Looking at VideoScreen/index.tsx:186-188:

if (!uri && !isWaitingForLive) {
  return null;
}

This means if we're not waiting for live but there's no URI, the component returns null. For live streams transitioning from waiting to active, there might be a brief moment where:

• isWaitingForLive becomes false
• But uri isn't available yet (because it depends on the updated video data)
• The screen returns null instead of rendering anything

The Real Root Cause

The polling doesn't happen during the waiting period. The refetchInterval only activates when isLive is already true:

refetchInterval: (query: Query<Video, OwnTubeError, Video, QueryKey>) => {
  return query.state.data?.isLive ? LIVE_REFETCH_INTERVAL : 0;
},

This means:

• While waiting (state 4/5): No polling, only refetch on foreground
• While live (state 1 with isLive: true): Poll every 10 seconds

When the device is asleep during the transition:

1. No polling happens because the video isn't live yet
2. When device wakes up, React Query should refetch on foreground
3. BUT React Query's refetchOnWindowFocus and refetchOnMount might not trigger reliably if:
   • The component doesn't unmount/remount
   • The app state change isn't detected properly
   • The query is still considered fresh (though staleTime: 0 should prevent this)

Additionally, even if the refetch happens, there's no guarantee the Video component will initialize properly because it was never mounted while in waiting state.

Summary

The root cause is lack of active polling during the "waiting for live" state. The app relies on React Query's foreground refetch, which:

1. May not trigger reliably when the device wakes from sleep
2. Even if it triggers, the complex Video component initialization logic may not handle the waiting→live transition properly
3. The refetchInterval should include waiting states (4 and 5) to poll for the transition to live

---

Proposed Solutions

Solution 1: Poll during waiting state (Recommended)

Modify api/queries/videos.ts:103-105 to also poll when video is in waiting state:

refetchInterval: (query: Query<Video, OwnTubeError, Video, QueryKey>) => {
  const data = query.state.data;
  const isWaitingForLive = [4, 5].includes(Number(data?.state?.id));
  return data?.isLive || isWaitingForLive ? LIVE_REFETCH_INTERVAL : 0;
},

Solution 2: Force refetch on app foreground

Use a React Query option to ensure refetch happens when app comes to foreground, combined with proper Video component reinitialization.

Solution 3: Add explicit AppState listener in VideoScreen

Add an AppState listener in the VideoScreen component that explicitly refetches the video query when the app comes to foreground.

---

Would you like me to implement Solution 1 (the recommended approach)? This would ensure the app actively checks for the live stream transition every 10 seconds while in waiting state, eliminating the reliance on foreground refetch timing.

---