Special treatment for PVR recordings causes loss of features

[wutschel]

Background:

The Remote App`s playback concept is playlist centric. When requesting to play an item the Remote App will first add the item to the playlist, and then play the playlist. This allows to queue more items either right after the current playing item or at the end of the playlist. A simple direct playback of any item will violate this basic concept and would cause problems, e.g. not being able to queue items right after current playing.

Problem:

Until the current Kodi version 19.1 there is no support for recordingid in Playlist.Add and Playlist.Insert. To work around this any recordingid item will be added as file to the playlist. This causes the function Playlist.GetItem to not being able to resolve thumbnails, icons, descriptions or plots. In consequence the NowPlaying screen will no show such existing (!) metadata.

Another problem is that playcount is only updated on the JSON API when a recording is played via recordingid. If a recording is played via its file path (e.g. pvr://path-to-recording), the playcount Kodi-internally is increased but it is not changing on the JSON API. Example:

1. play via file -> JSON API playcount=0
2. play via recordingid -> JSON API playcount=2
3. play via file -> JSON API playcount=2
4. play via file -> JSON API playcount=2
5. play via recordingid -> JSON API playcount=5

Solution:

The proper solution will be to support recordingid in Playlist.Add and Playlist.Insert in Kodi and remove Remote App`s special treatment from then on.

Alternative:

Also use direct playback (like for Live TV channels). In this case you cannot enqueue recordings, and enqueuing any other item "after the current item" will place this as the start of the playlist.

Screenshots:

Current look caused by playing file type:

If playing via recordingid:

[wutschel]

@howie-f, could you support and check, if it is possible to allow recordingid in playlists for future JSON API versions? Or was there a good reason to not allow this?

[howie-f]

will take a look at it the next days @wutschel

[howie-f]

hm, i think in order to support recordingid in Playlist.Add / .Insert we would need to extend type Playlist.Item

https://github.com/xbmc/xbmc/blob/cf427205bde11fa30902fd7a765b3f7d34e4909e/xbmc/interfaces/json-rpc/schema/types.json#L154-L166

and add the recordingid here to solve the first point... i don't think this is problematic, but would like to hear the opinion of @DaveTBlake on this. there's a few json pr's queued actually as far as i know.

@wutschel the wrong playcount is the result of the call to Player.Open right? but i've no idea how i get the playcount afterwards via json :) how does this work?

[wutschel]

@howie-f, thanks for looking into this.

the wrong playcount is the result of the call to Player.Open right? but i've no idea how i get the playcount afterwards via json :) how does this work?

The playcount is a property of PVR.GetRecordings. You would request it via something like
"method": "PVR.GetRecordings", {"params": {"properties": ["title", "playcount"]} }

[howie-f]

looks like we need a json-rpc call playlist.add(recordingid) that does the same like executing the context-menu entry Queue item in Kodi‘s UI (pvr recordings)…. can you confirm @wutschel?

just wondering why i see the plot but not the station logo on the remote when i queue via UI. it might be a different issue and pvr.hts related 🤔

[wutschel]

looks like we need a json-rpc call playlist.add(recordingid) that does the same like executing the context-menu entry Queue item in Kodi‘s UI (pvr recordings)…. can you confirm @wutschel?

Yes, exactly. Support for Playlist.Add(recordingid) and Playlist.Insert(recordingid) -- similar like it is available for albumid or artistid -- should resolve this topic from my understanding.

just wondering why i see the plot but not the station logo on the remote when i queue via UI. it might be a different issue and pvr.hts related 🤔

Yes, could be the case. A while back I worked on a similar problem where triggering playback of an episode via UI was resulting in a different label as triggering the same via Remote App. I can take a look at this in the next days. Maybe there is a solution possible.

[howie-f]

ok, thanks.. i‘ll go digging a bit further 🙂

[wutschel]

just wondering why i see the plot but not the station logo on the remote when i queue via UI. it might be a different issue and pvr.hts related 🤔

Just looked into this with Kodi 19.1 setup. The Remote simply ignores the icon currently. When playing a TV channel or another item type the API provides a thumb property (and also a non-empty icon property). The NowPlaying screen is coded to only display this thumb. When watching a recording this property is missing and only icon property is provided. The screenshots shown above were using a hardwired solution which simply takes icon and ignores all other properties.

To handle this correctly I need to take into account which type is currently played (type is part of the response to Player.GetItem), Sadly the API reports "type": unknown" when playing a recording. This should be fixed as I am not sure for which other item also "unknown" might be reported. This is the next ToDo.

[wutschel]

@ksooo, do you maybe have an idea how to tackle this?

[howie-f]

sorry for the delay wutschel, turns out it‘s not as simple as just extending Playlist.Item.. honestly i‘m stuck at the moment 🤔

[wutschel]

No worries, and thanks for taking a look at this.

[wutschel]

Significant progress is seen in a Kodi test build. "Playlist.Add", "Playlist.Insert" and the increase of "playcount" is working with this build.

To be able to show a proper thumbnail it is still preferred to receive "thumbnail" or "type" reflecting the playback of a recording as response to a "Player.GetItem" request. In worst case I can also make use of "file" (which starts with "pvr:" in such case) and use this as trigger to fall back to "icon" as thumbnail. This would result in showing the station logo on the NowPlaying screen.