⌘R refresh + auto-retry on network loss for video playback - #24
Merged
Conversation
After a network interruption the video player could stay stuck (black / spinning) with no way to recover. Add: - ⌘R "Refresh": reloads the current video's playback surface at its last position, recovering a stuck player without losing the user's place. ⌘R was Repeat — moved Repeat to ⌘⇧R (browser-like ⌘R = reload). - Auto-retry: when connectivity returns (NetworkMonitor), a video that stalled during the outage is reloaded automatically. Deliberately-paused playback is left untouched. Closes #19 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
🤖 CodeAnt AI — Review Status
|
Thanks for using CodeAnt! 🎉We're free for open-source projects. if you're enjoying it, help us grow by sharing. Share on X · |
codeant-ai
Bot
added
the
size:M
![codeant-ai[bot]](https://avatars.githubusercontent.com/in/646884?s=60&v=4){kind=small}
Comment on lines
+467
to
470
| Button(String(localized: "Refresh")) { | ||
| self.youtubePlayerService.refreshCurrentVideo() | ||
| } | ||
| .keyboardShortcut("r", modifiers: .command) |
There was a problem hiding this comment.
Suggestion: The new refresh command is always enabled and directly targets the YouTube service, unlike the existing video seek commands, which are disabled unless media keys are routed to video and a current video exists. When music is the active source but a YouTube video remains loaded in the background, ⌘R still reloads that video and can cause it to reclaim the playback arbiter, unexpectedly disrupting music. Apply the same active-video routing and availability guard used by the other video playback commands. [api mismatch]
Severity Level: Critical 🚨
- ❌ ⌘R can interrupt active music playback.
- ⚠️ Background YouTube state remains addressable globally.
- ⚠️ Refresh behavior differs from existing video command routing.Steps of Reproduction ✅
1. Start a YouTube video through `YouTubePlayerService.play(video:)` at
`Sources/Kaset/Services/Player/YouTubePlayerService.swift:448`; this sets `currentVideo`
and causes `PlaybackArbiter.videoWillStartPlaying()` to set the active source to video at
`Sources/Kaset/Services/Player/PlaybackArbiter.swift:32-35`.
2. Start music afterward; `PlaybackArbiter.musicDidStartPlaying()` at
`Sources/Kaset/Services/Player/PlaybackArbiter.swift:48-57` changes `activeSource` to
music and pauses the video, but does not clear `youtubePlayerService.currentVideo`.
3. With music active and the paused YouTube video still loaded, press ⌘R. The command at
`Sources/Kaset/KasetApp.swift:467-470` is always enabled and directly calls
`refreshCurrentVideo()`, unlike the seek commands at
`Sources/Kaset/KasetApp.swift:383-394`, which use `shouldDisableVideoSeekCommands`.
4. `refreshCurrentVideo()` at
`Sources/Kaset/Services/Player/YouTubePlayerService.swift:558-570` reloads the retained
video. The reloaded watch page can autoplay, and playback updates call `playbackWillStart`
from `Sources/Kaset/Services/Player/YouTubePlayerService.swift:1519-1521`, allowing the
arbiter to reclaim the video source and disrupt music.
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** Sources/Kaset/KasetApp.swift
**Line:** 467:470
**Comment:**
*Api Mismatch: The new refresh command is always enabled and directly targets the YouTube service, unlike the existing video seek commands, which are disabled unless media keys are routed to video and a current video exists. When music is the active source but a YouTube video remains loaded in the background, ⌘R still reloads that video and can cause it to reclaim the playback arbiter, unexpectedly disrupting music. Apply the same active-video routing and availability guard used by the other video playback commands.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
Comment on lines
+620
to
+628
| self.beginYouTubePlaybackIntent() | ||
| let resumeAt = self.interruptionResumeAt(for: currentVideo.videoId) | ||
| self.playbackController.prepare( | ||
| webKitManager: self.webKitManager, | ||
| playerService: self, | ||
| usesCookieFreeDataStore: self.usesCookieFreePlaybackDataStore | ||
| ) | ||
| self.playbackController.reloadVideo(videoId: currentVideo.videoId, resumeAt: resumeAt) | ||
| self.isPlaybackLoading = true |
There was a problem hiding this comment.
Suggestion: The refresh path starts a new autoplaying document without clearing isExplicitPauseIntentActive, isAwaitingResumeConfirmation, or changing desiredPlaybackIntent to .playing. If the current video was deliberately paused, the new page's playing updates are suppressed and immediately paused again, so the documented refresh behavior does not resume the refreshed surface and native/WebView state becomes inconsistent. Use the same intent reset and reload state transitions as the resume or identity-reload path, or preserve the paused state explicitly. [stale reference]
Severity Level: Major ⚠️
- ❌ Manual refresh fails to resume paused video surfaces.
- ⚠️ Native playback state disagrees with WebView autoplay state.
- ⚠️ Recovery refresh can leave the player apparently stuck.Steps of Reproduction ✅
1. Load and play a video through `YouTubePlayerService.play(video:)` at
`Sources/Kaset/Services/Player/YouTubePlayerService.swift:448-489`, then explicitly pause
it through `pause()` and `performPause()` at
`Sources/Kaset/Services/Player/YouTubePlayerService.swift:822-837`.
2. The explicit pause sets `desiredPlaybackIntent` to `.paused`, sets
`isExplicitPauseIntentActive` to `true`, and clears resume confirmation at
`Sources/Kaset/Services/Player/YouTubePlayerService.swift:899-916`.
3. Press ⌘R, which invokes `refreshCurrentVideo()` at
`Sources/Kaset/Services/Player/YouTubePlayerService.swift:558-570`. That method calls
`beginYouTubePlaybackIntent()` but does not reset `desiredPlaybackIntent`,
`isExplicitPauseIntentActive`, or `isAwaitingResumeConfirmation`.
4. The new watch page is requested through `reloadVideo()` at
`Sources/Kaset/Services/Player/YouTubePlayerService.swift:562-569`. When its playing
update arrives, `reconciledPlayingState()` suppresses it whenever the pause fence remains
active at `Sources/Kaset/Services/Player/YouTubePlayerService.swift:1717-1722`, so the
refreshed surface remains natively paused instead of following the documented autoplaying
refresh behavior.
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** Sources/Kaset/Services/Player/YouTubePlayerService.swift
**Line:** 620:628
**Comment:**
*Stale Reference: The refresh path starts a new autoplaying document without clearing `isExplicitPauseIntentActive`, `isAwaitingResumeConfirmation`, or changing `desiredPlaybackIntent` to `.playing`. If the current video was deliberately paused, the new page's playing updates are suppressed and immediately paused again, so the documented refresh behavior does not resume the refreshed surface and native/WebView state becomes inconsistent. Use the same intent reset and reload state transitions as the resume or identity-reload path, or preserve the paused state explicitly.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
Comment on lines
+637
to
+639
| let stalled = self.isPlaybackLoading | ||
| || (self.desiredPlaybackIntent == .playing && !self.isPlaying) | ||
| guard stalled else { return } |
There was a problem hiding this comment.
Suggestion: The loading-only branch ignores the user's playback intent. In particular, refreshCurrentVideo() sets isPlaybackLoading even when refreshing a deliberately paused video, so a later connectivity restoration can call this handler and reload/autoplay that paused video despite the documented guarantee that deliberate pauses are left untouched. Require desiredPlaybackIntent == .playing before retrying the loading state, or distinguish user refresh loading from outage-stall loading. [incorrect condition logic]
Severity Level: Major ⚠️
- ❌ Paused videos can receive unintended automatic reloads.
- ⚠️ Connectivity restoration ignores deliberate pause intent.
- ⚠️ Repeated reloads can disrupt the paused playback surface.Steps of Reproduction ✅
1. Load a video and deliberately pause it using `performPause()` at
`Sources/Kaset/Services/Player/YouTubePlayerService.swift:828-837`; this records `.paused`
intent and clears loading through `activateExplicitPauseIntent()` at
`Sources/Kaset/Services/Player/YouTubePlayerService.swift:840-858`.
2. While paused, press ⌘R. `refreshCurrentVideo()` at
`Sources/Kaset/Services/Player/YouTubePlayerService.swift:558-570` starts a new navigation
and unconditionally sets `isPlaybackLoading = true`, even though the pause intent remains
active.
3. When connectivity subsequently transitions to connected, `KasetApp` calls
`handleNetworkRestored()` at `Sources/Kaset/KasetApp.swift:325-330`.
4. The loading-only condition at
`Sources/Kaset/Services/Player/YouTubePlayerService.swift:576-582` ignores
`desiredPlaybackIntent` and calls `refreshCurrentVideo()` again. Thus a user-initiated
paused refresh is treated as an outage stall, violating the documented guarantee that
deliberate pauses remain untouched and repeatedly reloading an autoplay-capable page.
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** Sources/Kaset/Services/Player/YouTubePlayerService.swift
**Line:** 637:639
**Comment:**
*Incorrect Condition Logic: The loading-only branch ignores the user's playback intent. In particular, `refreshCurrentVideo()` sets `isPlaybackLoading` even when refreshing a deliberately paused video, so a later connectivity restoration can call this handler and reload/autoplay that paused video despite the documented guarantee that deliberate pauses are left untouched. Require `desiredPlaybackIntent == .playing` before retrying the loading state, or distinguish user refresh loading from outage-stall loading.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
User description
After a network interruption the video player could stay stuck (black / spinning) with no way to recover.
NetworkMonitor), a video that stalled during the outage reloads automatically. Deliberately-paused playback is left untouched.Closes #19
🤖 Generated with Claude Code
CodeAnt-AI Description
Recover video playback after network interruptions
What Changed
Impact
✅ Fewer stuck or black video players✅ Playback resumes without losing the viewing position✅ Deliberately paused videos stay paused💡 Usage Guide
Checking Your Pull Request
Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.
Talking to CodeAnt AI
Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:
This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.
Example
Preserve Org Learnings with CodeAnt
You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:
This helps CodeAnt AI learn and adapt to your team's coding style and standards.
Example
Retrigger review
Ask CodeAnt AI to review the PR again, by typing:
Check Your Repository Health
To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.