[PVR] Series recordings

[ksooo]

This PR adds series recording support to Kodi.

The technical concept:

Basic concept is that PVR addons now define an arbitrary number of timer types they support, each type defining its own combination of timer type attributes (out of a set of attributes predefined by the PVR addon API).

Kodi PVR core picks up the different types (and their attributes) using a new PVR addon API function and strictly builds up the complete timer-related logic dynamically, according to the timer attributes. Timer type information is now available at every TimerInfoTag instance.

Essential timer attributes: Kodi distinguishes between manual (time-based) and epg-based timers. Also, there can be one-shot and repeating timers. All combinations of these attributes are allowed, e.g. "manual + one-shot" or "epg + repeating".

Examples for other timer attributes: "supports recording priority", "supports epg search string", "supports recording folders", ...

UI changes:

Timer window:

• A "Type" column has been added
• "Scheduled time" column now handles all combinations of weekdays, and start/stop time (incl. "any time" for timer schedules) correctly.

• The timers scheduled by timer schedules (aka repeating timers) can be displayed as "children" of the timer schedule, similar to the "group items" feature of the recording window

• This behaviour can be controlled using a new (level 4) setting available in the Confluence side blade, similar to the group items feature of the recordings window.

Timer settings dialog:

• Completely rewritten from scratch, now acts completely dynamically upon the available timer types and their attributes
• Main idea is to start creation of a new timer by selecting the appropriate timer type. Dialog content will automatically adjust itself according to the respective timer type attributes. As before, user fills in the relevant data on kicks of the new timer
• Dialog can (like before) also used for editing existing timers
• Couple of new/enhanced features, among them support for epg-based repeating timers, support for all weekday combinations, pre- and post-record time, ...
• Finally, lots of bug fixes...

• For weekday selection, a new dialog was implemented.

Context menu actions:

• All relevant context menu items are now displayed only if the corresponding functionality is available according to the timer type attributes. Example: Activate/deactivate timer
• A (from my point of view very cool) new menu item "Add advanced timer" is now available if an epg entry was selected, for example in the epg grid. This opens a timer settings dialog preset to create a an epg-based series recording based on the data of the selected epg entry.

Note: All this is implemented and tested against a real PVR addon (pvr.hts), not "just" pvr.demo. I consider pvr.hts as the reference implementation of this (larger) PVR addon API change. Code is currently here (https://github.com/ksooo/pvr.hts/tree/series-recording-support), PR will follow soon.

Feedback is much appreciated!

[Montellese]

I can't comment on the PVR stuff since I don't use it.
Why did you implement a new dialog for the weekdays selection? Why not simply use CGUIDialogSelect with multi-selection enabled?

[ksooo]

@Montellese As far as I can see, CGUIDialogSelect always works on a FileItemList. Weekdays are just an int. I don't see that CGUIDialogSelect fits here. Or is it a good approach to "wrap" the single weekdays to file items?

[Tolriq]

@Montellese already proposed a few time, but my offer to provide you needed equipment for PVR is still valid.

PVR is becoming better and better and more and more used and will be in the future and the API is not really following :(

[Jalle19]

Now my eyes hurt...

[ksooo]

@Jalle19 hehe. Need some glasses? Many thanks for the review. Nothing serious found so far, which makes me feel good...

Despite from the code comments, any feedback on the functionality?

[da-anda]

I'm not sure if it wouldn't be better to split up the type so that "guide based" would have it's own flag.

[ksooo]

;-) Feel free to send me a patch to add the setting. I know you have the skills for that.

[Glenn-1990]

Will see when I can find some time.

Nice work btw ;-)

[Jalle19]

Thanks for taking care of the comments so far!

[da-anda]

@Montellese would it be possible to put the timer settings in logical groups with the changes by alwinus that allow to define a group label? It might be a nice idea to clean up this dialog even more by having logical groups. Like one section for type, channel etc, the other for advanced schedule options, and one for secondary settings like "priority", "lifetime", ...

@ksooo I always wondered who is responsible for the available "lifetime" values, Kodi or backends? I also think this shouldn't be a spinner with the range from 1-356 days but rather a predefined list of values that make most sense + a "forever" and a "until disk space is required" option, like:
1 day, 3 days, 1 week, 2 weeks, 1 month, 2 months, 3 months, 5 months, 1 year, until diskspace is required, forever

edit: thanks for addressing all the bikeshed so far 👍

[ksooo]

@da-anda may I kindly ask to hold yer horses a little, please. I very appreciate all your ideas, but I get the feeling that there is so many room for small improvements everywhere that I will still work on this PR when we are in Beta phase for Kodi 20. ;-) I try my best, but having limited time. I opt for getting this out very soon and to improve over time. The change requests are at a very high level already which makes me think the important things are already in good shape.

Regarding lifetime: Can only speak for tvheadend. There, it is the backend which can handle every lifetime from 0 to ... days. "forever" and "until disk space is required" is not supported. At least with those last two values things will get complicated. How to determine which (kind of values) the backend supports? From the API point of view ... a mess. We have carefully to weight value against effort.

[da-anda]

@ksooo - sorry for getting crazy about features/changes. The things mentioned in my previous post are ofc only nice to haves and can also be addressed later. Don't want to bikeshed this PR to death, only got inspired by the improvements done so far.

Regarding lifetime API, well, not that complicated I think. Ask the PVR add-on for supported lifetime types and get a vector (or bitmask) back (PVR_TIMER_LIFETIME_DAYS, PVR_TIMER_LIFETIME_INFINITE, PVR_TIMER_LIFETIME_DISKUSAGE). The other option would be to register a settings value filler and within the filler optain the possible values from the PVR add-on (have the add-on fill the list). We could even support both ways, where with support for PVR_TIMER_LIFETIME_DAYS we use a predefined list like in my suggestion above and if backend wants to have custom settings have it fill the options on it's own. As said, not required for this PR in general, only a nice to have and can also be addressed later.

[ksooo]

@da-anda re lifetime. Your implementation suggestion is exactly what I'm saying. It bloats the PVR addon API (remember, every addon must implement it) for IMO not (too) much value gain. IMO, this goes far beyond the scope of this PR. Especially, as this "addons should be able to specify the values they support for their supported attributes" can be applied to almost(?) all(?) timer type attributes...

[da-anda]

@ksoo - I actually thought that when you mentioned the rewrite of the other PR that you're going the way that add-ons "simply" forward a timer settings structure and we're only the rendering GUI ;)

I don't see this as bloat of the API, but the way our API is handled is unfortunately causing additional bloat. So the real issue is the lack of Kodi not being able to talk to older API versions, which i know will make things even more complicated core wise, but this logic could probably be abstracted and reused for all (binary) interfaces. No more stub functions and PVR add-on breakage or update nightmare because of a minor API bump. But I can't judge the amount of work and complexity required for this, especially with binary stuff.
One way that I could think of this might work would be talking to add-ons via API connectors that either simply forward API calls 1:1 or translate older API versions to newer ones (+ having required stubs), while we support only the last X API versions via such connectors. But that's way off topic.

I really apreciate what you've done here and look forward to see this PR in action.

[ksooo]

I actually thought that when you mentioned the rewrite of the other PR that you're going the way that add-ons "simply" forward a timer settings structure and we're only the rendering GUI ;)

Yes, that's exactly the way I want to go. And this PR is the first step into this direction. 100% is still somehow far away, but with this PR we will have the basics. Looking at it with 80/20 rule in mind we're at 80 now, imo.

[ksooo]

All feedback from yesterday and today is now in.

• strings
  • trailing colons removed from timer settings dialog setting labels
  • capitalization bugs fixed
  • wording, mostly consistency
• windows
  • minor code changes and fixes
• core
  • minor code changes and fixes
• timer settings dialog
  • channels now as a list (vs. spinnner)
  • values with proper measurement units (vs. unit part of setting label)
  • minor code changes and fixes

Thanks to all reviewers so far.

Would really like to get some feedback re. PVR addon API changes. @opdenkamp? @FernetMenta? @xhaggi? all?

[FernetMenta]

@ksooo this seem to have broken instant recordings for backends not supporting those timer types:
http://forum.kodi.tv/showthread.php?tid=234605&pid=2073817#pid2073817

EDIT: not sure about this message, why does it trigger a warning?

WARNING: GetAddonProperties - Addon VDR-Network-Streaming-Interface (VNSI) Server:192.168.100.16:34890 does not support timer types. It will work, but not benefit from the timer features introduced with PVR Addon API 2.0.0

[ksooo]

@FernetMenta could you please check what happens in cVNSIData::AddTimer in this case? Cannot do myself as I do not have a working VDR setup.

[metaron-uk]

@ksooo , @FernetMenta - this doesn't appear to affect pvr.mythtv with only the 1.9.7/2.0.0, 2.0.1 and 3.0.0 'minimal support' patches applied.
Not saying it wasn't introduced by these changes, but it makes me think that the issue is probably VDR specific, rather than affecting all clients.

[ksooo]

Can confirm that there are no issues with tvheadend.

[ryangribble]

I can confirm that pvr.wmc Instant Record is working with current kodi master and pvr.wmc master (ie the 1.9.7 minimal support patches)

[ryangribble]

also just to clarify, the users in that forum thread are running Kodi 15.1 but this change on this PR was only merged into Jarvis (Kodi 16 alpha) unless im missing something?

[ksooo]

This is PR is Jarvis only. So, if the forum thread is about 15.1 there must be some other reason for the problem.

[ryangribble]

looks like the OP on the forum thread was running Kodi 16, the 2nd guy in the thread with the "same problem" is on 15.1 which confused me

[ksooo]

After reading the forum thread again, it actually is about Jarvis. Nevertheless, I think that this is most probably a problem with pvr.vdr.vnsi, not with Kodi core.

[FernetMenta]

@ksooo see my comment, this change broke it because of incorrect timer state for instant recordings

[ksooo]

@FernetMenta okay, it's a change and obviously it broke vdr.vnsi. I was not aware of that this could break anything. Sorry.

But isn't state SCHEDULED wrong, according to the API docs (https://github.com/xbmc/xbmc/blob/Isengard/xbmc/addons/include/xbmc_pvr_types.h#L109)? SCHEDULED indicates that "timer is scheduled for recording" and as long as the backend has not confirmed that it successfully added a newly kodi-side created timer (AddTimer succeeded), the timer state should be NEW ("a new, unsaved timer"), imo.

So, I suggest to fix vdr.vnsi. What do you think?

[FernetMenta]

vdr allows to create a timer which is not active. So what do you suggest?

• Kodi creates an instant timer in new state
• vdr acks that it has saved the timer
• vnsi (backend) sends a message back to kodi
• vnsi client sets the timer to scheduled
• vnsi sends a message to vnsiserver to active the timer

This ping pong makes not much sense to me.

[FernetMenta]

Also note that PVR_TIMER_STATE_NEW was used to be never set from kodi. Your change may have broken more behaviour.

[ksooo]

So the question is whether we consider the API spec broken and fix it or whether we consider some API implemenations broken because they violate the spec?

[ksooo]

This ping pong makes not much sense to me.

• Kodi creates an instant timer in new state
• vdr acks that it has saved the timer

Why can't you just instruct vdr to create an active timer in this case (assuming that this is what you currently do if incoming state is SCHEDULED)?

[FernetMenta]

why do you want to change the api? note that vdr/vnsi was the first pvr addon and many things of the API has beed derived from this.
we need to distinguish between a timer directly created on the backed (inactive, this is state new) and a timer which is supposed to start a recording.
implicitly assuming that a time state "new" from pvr means "scheduled" is wrong.
I don't see the need and the benefit why you changed this.

[FernetMenta]

So the question is whether we consider the API spec broken and fix it or whether we consider some API implemenations broken because they violate the spec?

how can the first addon with that the spec was created violate the spec?

[ksooo]

we need to distinguish between a timer directly created on the backed (inactive, this is state new) and a timer which is supposed to start a recording.

I see. But then the API docs for state NEW should definitely be revised. I read it as "just created on the Kodi side, not yet confirmed by the backend".

I will create a PR fixing both the misleading API docs and reverting the "misuse" (;-) of timer state new.

[FernetMenta]

thanks much!
btw: priority and lifetime come from vdr too.

[metaron-uk]

btw: priority and lifetime come from vdr too.

@FernetMenta anything which would affect this metaron-uk@a131127 in #7626 ?

[FernetMenta]

yes, lifetime goes untouched through vnsi and the definition is:

The number of days (0..99) a recording made through this timer is guaranteed to remain on disk before it is automatically removed to free up space for a new recording. Note that setting this parameter to very high values for all recordings may soon fill up the entire disk and cause new recordings to fail due to low disk space. The special value 99 means that this recording will live forever, and a value of 0 means that this recording can be deleted any time if a recording with a higher priority needs disk space.

[FernetMenta]

@ksooo do you have plans to support vps timers? would this be a special type or just some flag?

[ksooo]

I think a special timer type would be the easiest way to implement this. Only difference to "normal" timers would be that start and end time are not fixed values, but approximated, right? Naming the timer respectively would make things easily understandable for the users.

Nothing additionally needed in Kodi core for this. All that is necessary can be done in the PVR add-ons - given that the vps functionality is something provided and controlled by the backend.