fix: enable multi-segment playback via JSON-RPC#154
Open
maximilian-sh wants to merge 2 commits intos0faking:masterfrom
Open
fix: enable multi-segment playback via JSON-RPC#154maximilian-sh wants to merge 2 commits intos0faking:masterfrom
maximilian-sh wants to merge 2 commits intos0faking:masterfrom
Conversation
Multi-segment episodes (e.g. ZIB 2) add all segment URLs to a playlist. Previously Player().play(playlist) was called directly, which caused intermittent crashes from two concurrent BusyDialogs — one opened by Kodi to resolve the plugin URL, one from Player().play(). Instead, call setResolvedUrl(handle, False) to signal that the plugin URL itself is not directly playable and close the resolution context cleanly. In GUI mode, the playlist player then takes over: it skips the unresolvable plugin URL at position 0 and plays the segments at 1..n automatically, same as before. For external JSON-RPC control (Player.Open), no playlist player is active after setResolvedUrl returns, so playback would silently stop. We detect this by checking whether playlist.size() == len(tracks): if true, Kodi did not pre-insert the plugin URL at position 0, meaning we are in a JSON-RPC context and need to start playback explicitly. Note: the JSON-RPC detection via playlist size comparison is a heuristic that works in testing but may not cover all edge cases — happy to hear if there is a cleaner way to distinguish these two contexts.
maximilian-sh
force-pushed
the
fix/playlist-playback-not-starting
branch
from
f859f95 to
9925dd0
Compare
maximilian-sh
changed the title
The previous playlist.size() == len(tracks) check failed when the global video playlist had leftover items from a previous session, causing JSON-RPC playback to silently do nothing. In GUI mode Kodi always adds exactly 1 item (the plugin URL itself) to the playlist before running the plugin, so pre_size is 1. In JSON-RPC mode no item is pre-added, so pre_size is 0 or reflects leftover playlist state. Using pre_size != 1 as the JSON-RPC guard is reliable regardless of prior playlist contents, and startpos=pre_size correctly points to the first newly added track.
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.
Problem
Multi-segment episodes (e.g. ZIB 2 on ORF TVthek) add all segment URLs to a `PlayList` and previously called `Player().play(playlist)` directly. This caused intermittent crashes with two concurrent BusyDialogs — one opened by Kodi to resolve the plugin URL, one from `Player().play()`.
Fix
Call `setResolvedUrl(handle, False)` first to signal that the plugin URL is not directly playable and close the resolution context cleanly.
In GUI mode, the playlist player then handles everything automatically: it skips the unresolvable plugin URL at position 0 and plays the segments — same behaviour as before, no regression.
For JSON-RPC (`Player.Open` via external control like Kodi remotes or home automation), no playlist player is active after `setResolvedUrl` returns, so playback would silently stop. We detect this by recording `pre_size = playlist.size()` before adding tracks: in GUI mode Kodi always pre-inserts exactly 1 item (the plugin URL itself), so `pre_size == 1`. In JSON-RPC mode no item is pre-added, so `pre_size != 1` — we then start playback explicitly from position `pre_size` (the first newly added track). This also correctly handles the case where the global playlist has leftover items from a previous session.
Note
I put this together to fix JSON-RPC control of multi-segment content and it works correctly in both GUI and JSON-RPC testing. Happy to hear if there is a cleaner way to distinguish these two contexts.