[jsonrpc] The playerid is derived from the playlist, not the player, so a playing video can be unreachable from every Player method

[malard]

The playerid is derived from the playlist, not the player

Split out of xbmc#29077 — the official iOS remote cannot change the audio stream during Blu-ray playback. The app is not at fault: it uses the playerid Player.GetActivePlayers handed it.

The bug

Player.GetActivePlayers reports a video player under playerid 0:

{"id": 105, "jsonrpc": "2.0", "result": [{"playerid": 0, "playertype": "internal", "type": "video"}]}

and every video-only method then refuses both that id and the real one:

Player.SetAudioStream  {"stream": 2, "playerid": 0}         -> -32100 Failed to execute method
Player.SetAudioStream  {"stream": 2, "playerid": 1}         -> -32100 Failed to execute method
Player.GetProperties   ["audiostreams"] "playerid": 1       -> -32100 Failed to execute method
Player.GetProperties   ["audiostreams"] "playerid": 0       -> 200, the full stream list

(reporter's transcript over the web server, Kodi 21.2, xbmc#29077)

A client that follows the documented flow — call GetActivePlayers, then address the playerid it returns — cannot reach the player at all. The read path answers anyway, so nothing about the state is visible until a write silently fails.

The chain

1. The playing item does not classify as video. VIDEO::IsVideo() (xbmc/video/VideoFileItemClassify.cpp:91) has no bluray:// case, and the URIUtils::IsDVD() it calls (xbmc/utils/URIUtils.cpp:1128) matches only the literal dvd://1 off Windows. A bluray://<encoded>/ or dvd://<encoded>/ path returns false.

2. So the playlist player files it under music. CPlayListPlayer's TMSG_MEDIA_PLAY handler (xbmc/PlayListPlayer.cpp:1008) starts at Id::TYPE_MUSIC and upgrades to TYPE_VIDEO only if some item passes IsVideo(). The current playlist becomes TYPE_MUSIC (0), while CApplication::PlayFile goes on to play the disc as video.

3. JSON-RPC takes the playerid from the playlist. CPlayerOperations::GetPlaylist() (xbmc/interfaces/json-rpc/PlayerOperations.cpp:1598) returns the current playlist and consults the player only when there is none, so GetActivePlayers (:142) stamps playerid = 0 onto the video entry.

4. GetPlayer() round-trips through the same function (:1568): 0 resolves to Audio, and 1 resolves to None because GetPlaylist(Video) returns 0 and no longer matches the id asked for. SetAudioStream (:1359) handles only Video. Both ids fail, for two different reasons.

5. The read path papers over it. GetPropertyValue for currentaudiostream and audiostreams (:2052, :2093) handles case Video: case Audio: together against the same CApplicationPlayer, so playerid 0 returns the real stream list. That is why the remote's menu populates, and follows changes made from the OSD, while its own writes do nothing.

Reachable from our own surface

Player.Open posts the same message through the same classification (PlayerOperations.cpp:1132, via PlayFileItemList), so this reproduces over JSON-RPC alone with a disc path — no Python add-on involved. It is not disc-specific either: any item that plays as video but fails IsVideo() puts the whole Player namespace into this state.

Fix

Two defects, and one upstream of them:

• The playerid should come from the player. GetActivePlayers answers what is playing; deriving that answer from the playlist lets it name a player that is not the one playing. This is the fix.
• Read and write disagree about which playerids are valid. Whatever resolution rule lands, GetProperties and SetAudioStream / SetSubtitle must apply the same one: a playerid that returns audiostreams has to accept SetAudioStream.
• IsVideo() does not know bluray:// and barely knows dvd://. Upstream of both, worth fixing on its own, but it does not make the API correct — the reachability gap survives for the next item that misclassifies.

Status

Diagnosed by reading jsonrpc-14; the wire evidence above is the reporter's, not reproduced here yet. Failing tests first.

[malard]

The type half of this is now #129 — the player has no identity of its own, and playerid is invented in seven places by four different rules, only one of which is in JSON-RPC. Reversing what I said above: the PlayerId type does not belong in this ticket. It reaches VideoPlayer, the announcement path and seven call sites setting playlist_type_hint, which is a core review, not a JSON-RPC one.

This ticket stays scoped to resolution: GetActivePlayers publishes the player's own id, and every Player.* method accepts it. That fixes xbmc#29077 and does not depend on #129.

[malard]

Verified on the wire, and the repro in the description above is wrong — correcting it.

Player.Open with a disc path does not reproduce this. The item picks up a video info tag on the way through (Player.OnAVStart reports "type": "movie"), so VIDEO::IsVideo() returns true and the playlist is correctly set to video. I tested that first and everything behaved.

The state is reachable over pure JSON-RPC with an ordinary video file, no disc and no add-on:

Playlist.Clear  {"playlistid": 0}
Playlist.Add    {"playlistid": 0, "item": {"file": "<any video>"}}
Player.Open     {"item": {"playlistid": 0, "position": 0}}

The video plays while the music playlist is current, which is the same state a bluray:// path leaves behind by a different route.

Measured against two builds of jsonrpc-14, one at the tip (d34860dfaa) and one with the fix:

call	before	after
Player.GetActivePlayers	playerid: 0, type video	playerid: 1, type video
Player.GetProperties playerid 0	playlistid=0, 2 audiostreams	-32100
Player.GetProperties playerid 1	-32100	playlistid=0, 2 audiostreams
Player.SetAudioStream playerid 1	-32100	OK
current audio stream afterwards	0, unchanged	1, switched

That is xbmc#29077's transcript reproduced and then closed, including the part that made it hard to read: the read path answering on playerid 0 while every write failed.

The row worth noting is GetProperties playerid 1 -> playlistid=0. After the fix the player is addressed as 1 while reporting the playlist it is working through as 0. Those two numbers could not differ before.