pvr: Read recording's last played position from field in PVR_RECORDING

[fetzerch]

@opdenkamp @Red-F: This is the follow-up on the discussion in #1452

I've added the field iLastPlayedPosition to PVR_RECORDING.
The value in this field is used for showing the resume indicators in the recordings view.
Instead of calling GetLastPlayedPosition for every single recording.

This fixes the high load times of the recording view. Now it's usable again even with a high number of recordings.

When working on this, I recognized that I forgot to add playCount to WriteClientRecordingInfo. e97116b takes care of this.

Cheers,
Christian

[fetzerch]

@opdenkamp: sorry, you're right. now the database is used if it's not supported to read the play position from the addon.

[jdembski]

Just to make sure I get this correctly: When setting pCapabilities->bSupportsLastPlayedPosition = false then the last played position will be stored into / fetched from the database - so there is no need to store this information within the add-on if the backend itself does not support it?

[Red-F]

@jdembski yes that was the idea originally, and as far as I know that is how it is implemented and working now.

If your PVR backend does not support last played position, or you don't want to implement it in the add-on (at this moment) set the capability to false and XBMC uses its database.

[Red-F]

@fetzerch @opdenkamp : will this be merged before Frodo's GA?

[opdenkamp]

no more interface changes until after frodo, sorry.

[Red-F]

No problem, I just wanted to know if I should find time in my agenda this year to implement this.

[opdenkamp]

please rebase

[fetzerch]

I'm not convinced anymore that this is a good solution.

1. Do we still improve performance after the recent changes? The values seem to be cached in the db now.
2. Having 2 different methods for the same thing is not really a nice API.

Imo, we could also remove GetRecordingLastPlayedPosition and only use the field in PVR_RECORDING?
I don't know if this works for all addons. For MythTV, we get notifications as soon as a recording has been changed (for example another frontend plays the recording). We cache all recordings in the addon and don't have to query the backend any more. We would then call TriggerRecordingsUpdate so that the value in xbmc gets updated.
That way, the API would be more consistent as it would match the API for the play count.

Any thoughts? I will try to rebase it at the weekend so that we can see if it makes a difference performance wise.

[Red-F]

ARGUS TV does not send events. Clients that play a recording will update the position on the server, but the server does not push out events. This mainly due to the fact that the ARGUS TV api is a pure RESTfull api, patiently waiting for requests.

There are some plans to extend the api via the use of SignalR in the future for easy real-time event pushing by the server. But this is just under consideration and not available any time soon (and integrating that with XBMC will probably a challenge by itself when it is available 🍭 :).

[fetzerch]

Ok. As long as there are addons that don't get notified about such changes, it is needed.
I've rebased it and tested it with MythTV.

[opdenkamp]

goes in with #2250