[ksooo]

Send debug logs, please. Otherwise I cannot help.

[puenktchen]

Send debug logs, please. Otherwise I cannot help.

Here you go...https://www.dropbox.com/s/8gvfdp9uuhyl8mp/kodi.log?dl=0

[ksooo]

@pünktchen Thanks for the log. I understood now what the problem is and working on a fix.

[ksooo]

@pünktchen https://github.com/xbmc/xbmc/pull/7764

[puenktchen]

Okay, no crash anymore when i try to edit an existing schedule.
But i can't change any timer setting except "deactivate".
Also when i want to create a new schedule Kodi hangs in a loop because the MediaPortal pvr addon has its own
schedule skin files: https://www.dropbox.com/s/8gvfdp9uuhyl8mp/kodi.log?dl=0
Without those skin files no crash occurs but of course i don't have all the different timer possibilities

So @margro where are you?

[ksooo]

... Okay, and many thanks for your "thank you" for the super fast fix I supplied. ;-)

[puenktchen]

Entschuldigung Kai!!!

[ksooo]

Nvm. I think it is now really up to the add-on maintainer to do the fine tuning. Some months ago he told me that this would be no big deal.

[TRiddle]

Apologies if this has been answered, but I recently took up a spirited debate on the NPVR forums over recording logic. When I see the screenshots on github, I see the ability to "record only new episodes". Is this going to have the ability to run some logic to determine conflicts and conflict resolution? For example:

I have a specific tuner that is set to record three different "new" episodes on Sunday. All three conflict with each other, but appropriate logic will record the new episode with the highest priority and then search out alternate airings of the other two episodes, matching the showID and again schedule based on priority. It is not uncommon these days for broadcasts to re-air a new episode multiple times, epsecially satellite/cable channels. This was how SageTV did it (to my knowledge), and from what I've used in WMC, this is how it is done there as well.

I'm just curious as to how this is going to work. Apologies if I've posted in the wrong area or am bringing up a question that has already been answered.

[ksooo]

Is this going to have the ability to run some logic to determine conflicts and conflict resolution?

Yes. But what exactly is possible depends on the PVR backend functionality (and how the PVR addon for that backend leverages this functionality).

[TRiddle]

Thanks Ksooo, that's pretty much what I expected, although had hoped that maybe kodi would override some of that functionality (they all seem to do it different). From some testing I've done recently, barring the two programs I've used the most (SageTV and WMC have great logic), the recording logic seems to be too concerned with a "new" flag and less concerned with a showID. I wrote a proof of concept excel program this morning that I posted over at NPVR showing how using showID is a much better concept than solely relying on a "new" flag, especially when it comes to conflicts. Thanks again.

[metaron]

Just to to let everyone know there's a bug in the latest code which prevents start/end time from appearing when you create a new timer with 'first day' support, reported by @janbar. Only affects new timers, not existing ones. Will investigate later today.

[metaron]

Just to to let everyone know there's a bug in the latest code which prevents start/end time from appearing when you create a new timer with 'first day' support, reported by @janbar. Only affects new timers, not existing ones. Will investigate later today.

The problem is that bStartAnyTime and bEndAnyTime default to true, even when PVR_TIMER_SUPPORTS_END_ANYTIME and PVR_TIMER_SUPPORTS_START_ANYTIME are not set by the timer type. As the bStartAnyTime and bEndAnyTime variables drive the visibility of the START and END time settings, they are hidden when creating a new timer in these circumstances. 'FIRST DAY' is unrelated to the issue.

See PR https://github.com/xbmc/xbmc/pull/7875

[metaron]

One of the issues I've come across in the past is that it isn't possible to actually set different 'default' settings for each timer type and have them honoured (although the API suggests it is), as when creating a new timer the 'defaults' for the default timer type are used to display the timer settings dialog. You can then change the timer type, but the values remain those previously selected in the dialog.

This touches on my proposed fix for the 'Any Time' display issue discussed above (https://github.com/xbmc/xbmc/pull/7875) and also a possible change to the 'FirstDay' defaults (https://github.com/xbmc/xbmc/pull/7836)

The current behaviour seems to be 'pass undisplayed values through unaltered', which seems to make sense, but this raises the question: what should settings default to when a new timer is created?

My feelings (in priority order) are:

1. Whatever the addon requests as a default for that timer type, where the API provides a mechanism (requires a change, see 1st paragraph of this post)
   
2. Whatever kodi sets as a default via the 'TV' defaults (start/end margin etc...)
   
3. Values from selected EPG tag data (where available)
   
4. Current values where EPG data is not available
   
5. 'Less clicks more fun' defaults where the user can modify the setting
   
6. 'safe' defaults where the user can't modify the setting
   

I would like to see the following:

• For First Day, I want to default the value to 'EPG Start day' or 'now' if first day is supported by the timer type, but '0' if it isn't (to avoid breaking clients which rely on '0' as a default for first day, but to set sensible defaults if first day is supported see PR7836)
  

• For 'Anytime' I want to default to 'true' if anytime is supported for the timer type, false if start/end is supported but anytime is not and 'true' if both anytime and start/end are not supported. (To provide anytime settings consistent with the timer type)
  

• To present a 'select timer type' dialog before the 'timer settings' dialog which is used to select a timer type, then fix the timer type, rather than allow the user to change it. (Allowing defaults set based on timer type to be honoured)
  

What do people think?

[scarecrow420]

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