[metaron]

Not a fan of the double dialog you mention I like being able to loop through timer types on the existing dialog. I think if the timer type is changed, reset all fields/values to the default (eg reset/reinitialise the dialog). I think a user can't be upset if they set some field then find that's reset if they changed timer type. At least there is a way for that not to happen (user sets timer type before changing other fields) and doesnt require restarting the whole process if they chose wrong the first time

I can see your point about reducing flexibility. The approach you suggest makes sense to me.

[skarragallagher]

Any chance we could see support for recorded TV folder thumbnails for grouped recordings with these changes

[oliroe]

Hi

Do the backend developers have to make any changes to their addons in order to support the new series record dialogs?

Just wondering whether I need to bring this to the attention of DVBLogic to make sure they're ready for 16.0

Thanks

[ksooo]

If the dvblogic add-on shall provide the new features, yes, then the add-on must be adapted. If the add-on stays as it is now, it will still work with Jarvis, but it will not support the new features (despite from some ui sugar).

[oliroe]

Thanks

I've posted a thread in the DVBLogic forum to make sure they're aware

[scarecrow420]

Hey guys, just letting you know as of latest nightlies, pvr.wmc has support for these new features. It's still a work in progress but so far any fixes are in the backend rather than the pvr addon side.
Details are in this thread: http://forum.kodi.tv/showthread.php?tid=...pid2097607


On another note, @metaron @ksooo I found some odd things with the Day Of Week field display.

When adding a guide based timer, the value starts as "Any Day". If you select it as if you want to change it, but then hit Cancel (eg you decide not to make any changes) the field display now shows Mondays, Tuesdays, Wednesdays etc. So it's still the correct value but no longer displaying "Any Day".

On a similar note, on my Repeating (manual) timer type, the day of week display already starts as "mondays Tuesdays Wednesdays" etc, when it could perhaps be "Every Day" instead. Nitpicking im sure, but just mentioning it incase one of us does decide to do something regarding the "text" value of this days of week field.

particularly in the case where Canceling a dialog appears to "change" the field value, that is a UI/UX issue I think should be tidied up...

[ksooo]

@scarecrow420 this is a known problem and documented in the original PR (#7079). Unfortunately a fix is not trivial and in code areas I have never poked into so far (settingslib). Fortunately it's just a GO glitch without functional impact.

[scarecrow420]

Fair enough thanks for pointing out it was mentioned on the first PR, I probably read it at the time but as my implementation wasnt finished I may not have retained the fact it had already been raised.


Hey, on another note Ive just come across another thing that is giving me some difficulties in implementation. The way the timer deletion stuff works now in Kodi 16, if you delete a repeating timer Kodi prompts the user with a dialog asking "Do you want to delete all the child instances as well?" (or words to that effect).

The problem for me is, this isnt a concept that our backend (WMC) has. In WMC the "child" timers only exist by virtue of the fact that a "parent" repeating timer exists. So if you delete the parent, all the children will no longer exist either. In our world, when deleting the parent, it's simply a GIVEN that all children would then be deleted in the same operation and doesnt make sense to ask the user this question which we have no real way of honouring if they say No to.

Thoughts?

I have a [WIP] change locally that I quickly put together, that adds a new TimerType attribute PVR_TIMER_TYPE_FORBIDS_CONDITIONAL_DELETION and am using that to control whether Kodi asks the "Do you want to delete all children as well?" question or just sets the bDeleteScheduled to true if the timer type forbids the scenario. Should I submit this as a pull request?

Is adding a single bitflags attribute value (non breaking change) still an API change requiring a version number change and updating all addons addon.xml file? In theory we could simply add this new attribute in Kodi and it would be available to any addons next time they are compiled, but really it doesnt change anything so could we get away with not bumping version and not updating all addons? Normally id suggest just changing the 3rd version field (eg patch level, assuming semver) but I think if we did that, all addons would "break" due to not meeting API dependencies, eventhough it was a non breaking change?

[ksooo]

Tvheadend has the same problem. I solved it by first cloning the children of the timer schedule and deleting the schedule itself afterwards. You may take a look into pvr.hts sources to get the idea.

[scarecrow420]

Oh so you didnt add this as part of your changes?

I know we could create specific one shot timers for each child before deleting the parent... but to me it seems ugly/messy to do that, when its not the expected behaviour for our backend. Id prefer if I could tell Kodi not to ask the user this question when using our backend/addon... and it sounds like other addons (eg TVHeadEnd) and possibly others could potentially also benefit from being able to control this Kodi behaviour. I wonder which other backends do/dont support this concept...

[ksooo]

For me the point here is not what the backend expects/natively supports, but Kodi functionality and I cannot see any messiness here - neither in the sense of the functionality nor in the impression on the add-on side.

It's just some more lines of code to make single timers out of the existing children of the timer schedule. I think you could easily implement this (maybe using my code as template) - imo no need for a API extension.

The purpose of the add-on is to adapt the two functional worlds - and not everything must be just rooting stuff 1:1 back and forth. ;-)

[krustyreturns]

But does adding this feature really have any benefit? I can't imagine a scenario where a user wants to delete a series/repeating timer, but yet keep the next few episodes that are slated to record. Imo it just makes the interface more confusing while not adding any real benefit. If course it can be implemented, but I think there is a good reason why pvrs don't.

[krustyreturns]

I would like to see guide entry objects get a new flag to indicate where the entry is an episode of a series. The way it is now, using the guide a user can request a series recording for a show that is not part of a series, forcing the backend to throw an error. If however the guide knows a program is not part of a series, it could make the creation of series timer not possible in the ui - an much better solution imo.

[ksooo]

PRs welcome.

[metaron]

Hey, on another note Ive just come across another thing that is giving me some difficulties in implementation. The way the timer deletion stuff works now in Kodi 16, if you delete a repeating timer Kodi prompts the user with a dialog asking "Do you want to delete all the child instances as well?" (or words to that effect).

I wondered about this as well. IMHO, the dialogue is asking the user the wrong question:

If you try and delete a repeating timer, logically you are asking to delete all the children. As this is destructive and non-recoverable, I believe kodi should ask something like:
You are about to delete a repeating timer currently scheduling x recordings. Are you sure?
[Delete repeating timer (default) | Cancel]

If you try and delete a child timer associated with a repeating timer, the question should be something like:
This timer is associated with a repeating timer. What would you like to do?
[Delete repeating timer | Delete this timer (default) | Cancel]

Mythtv has the concept of an 'over-ride' rule which can be used to add exceptions to a repeating timer. This is what the current pvr.mythtv client does if you select to delete a child timer.

Personally I can't see why you would want to delete a repeating timer, yet keep the individual children already scheduled by it.
If it is recording the wrong stuff, you want to edit it instead. If you don't want it at all, you want it and it's children gone.