[ksooo]

Glad to here that the API works for you and that you're making good progress with pvr.wmc

[metaron]

Hey guys, while working on my pvr.wmc implementation I noticed that if you have "child" timers that are created by the parent repeating timer, when you click on the parent in the GUI and are viewing the child timers, there is no ".." item at the top of the list to take you back to the main timer screen. If you have a parent with no children, you do get a ".." option when inside the parent

Of course you can use the "back" button on the remote but just wondering if this was by design or should be fixed, as it's not consistent with other areas in Kodi where there is always the ".." option to go up a level.

When someone eventually works this out, they should note that in settings->Appearance->File lists is an option which says 'Show parent folder items'. The help string says: Display the (..) item in lists for visiting the parent folder

I'm guessing this list should honour that setting (like the 'Ignore articles when sorting' one below it)

[archie456]

Can I ask if the series recording changes are slated for Isengard?

Thanks

[oliroe]

No, J*******

[scarecrow420]

I know about the ".." problem, but have not found a solution yet. I'm not that familiar with the GUI code. If someone knows how to fix this I would be happy about a hint or even a PR.

Hey guys, while working on my pvr.wmc implementation I noticed that if you have "child" timers that are created by the parent repeating timer, when you click on the parent in the GUI and are viewing the child timers, there is no ".." item at the top of the list to take you back to the main timer screen. If you have a parent with no children, you do get a ".." option when inside the parent

Of course you can use the "back" button on the remote but just wondering if this was by design or should be fixed, as it's not consistent with other areas in Kodi where there is always the ".." option to go up a level.

When someone eventually works this out, they should note that in settings->Appearance->File lists is an option which says 'Show parent folder items'. The help string says: Display the (..) item in lists for visiting the parent folder

I'm guessing this list should honour that setting (like the 'Ignore articles when sorting' one below it)

Ive submitted a PR for adding the ".." to the child timers view. And yes it honors the Appearance setting as well. Note that I tested behaviour against the normal Videos section and found that regardless of that setting you always get a ".." in an empty folder, so that setting only applies to when there are child items. With my change the behaviour of the PVR Timers section is inline with the Videos section so I believe this is correct (eg, if you go into a parent timer that has no children, you do see the ".." but if the parent DOES have children you will only see the ".." if you have that Appearance setting enabled in Kodi Settings).

https://github.com/xbmc/xbmc/pull/7501

[xhaggi]

@ksooo it would be great if you could add the API changes to our sticky thread http://forum.kodi.tv/showthread.php?tid=...pid1957564

[ksooo]

@xhaggi ... to which I do not have write access. :-(

[xhaggi]

please ask nate or martijm to get mod rights

[metaron]

@ksooo
I've submitted https://github.com/xbmc/xbmc/pull/7553 to fix the problem with start/end being forced to now() on edit of a repeating timer.
This should address the first problem I found with https://github.com/xbmc/xbmc/pull/7508.

[metaron]

Following on from the github discussion ( https://github.com/xbmc/xbmc/pull/7553 ) on first day / start time / end time / anytime these are the features I would like to add and why:

1. Getting a meaningful 'time' to sort timers in 'date' order without breaking the underlying timer settings.
   
2. Allowing a user to toggle 'Any Time' without loosing the start and end time values.
   

AnyTime
For repeating timers which support start and end times (such as weekly or daily rules), it would be nice to be able to see what happens when you switch from 'anytime' to specific time constraints and back, without those times being lost.

Currently when you select AnyTime it stores this by setting start=end=0, and defaults both to now() when turning anytime off again.

I propose that a separate boolean be added to the API to store 'anytime' on/off. This will allow start and end time to remain unaffected, ready to be used / amended as the user sees fit.

Meaningful 'date' order
Repeating timers potentially have several times/dates associated with them:

• When they were created
  
• The recording start/end time
  
• When they last recorded something
  
• When they are next going to record something
  
• The 'first day' they should do something
  
• The 'last day' they should do something
  
• The days of the week they should do something.
  
• Times associated with the individual recordings made by the timers
  
• ...
  

To sort repeating timers in a sensible 'date' order, it is necessary to work out which are the most 'important' and then to pass this 'time/date' to the sort algorithm without affecting any of these timer settings.

Currently sorting seems to be done on 'start time/date'. We have tried to fill in the gaps caused by 'AnyTime' using 'first day'. This doesn't work properly and ksooo is rightly worried about unintended side-effects.

I propose that a separate time/date field be added to the API which is then used as a sort order. The client can then decide which time/date is most characteristic of that particular timer when sorting by date.
I propose not to add a 'TIMER_SUPPORTS' variable and to use 0 as a default (1/1/1970) if no value is specified. The timer list will automatically fall back to the secondary sort order (name) if the field isn't populated.

Way Forward
I plan to tackle these as separate PRs for consideration. If anyone has any suggestions / requests / or pertinent information (like which bit of the code specifies the 'date' field used to sort PVR timers!) please shout.

[metaron]

Some other ideas

Re-name 'Scheduled time' 'Summary' in the timer list
Current defaults can stay, but if the client provides a value for strSummary then this should be honoured instead.
This would allow a repeating timer to say "1/5, 19/7/2015 15:00" or "last recorded 1/6/2014 22:00" etc...
(no API change required for this one!)

Pass 'subtitle' 'season' and 'episode' data up to PVR core
This is already possible for EPG data, but not for recordings or timers.
For recordings, the absence of season/episode means you can't scrape the pvr:// directory properly unless you hack it into the title.... (http://forum.kodi.tv/showthread.php?tid=228316)
For timers it would be nice to have access to the data so Kodi can present it in a consistent format in the 'name' field.

[metaron]

Right, I've drafted a change to the API for consideration ( https://github.com/xbmc/xbmc/compare/mas...apiChanges ) on branch https://github.com/metaron-uk/xbmc/tree/apiChanges

As I guess we don't want to roll the API more often than necessary, this includes all my ideas in one:

1. Adds the following to PVR_TIMER type
   
   1. bAnyTime (replacing startTime=endTime=0 state to indicate Anytime for repeating recordings)
      
   2. sortTime (allow repeating timers to sort by date independent of timer settings)
      
   3. strEpisodeName, iSeriesNumber, iEpisodeNumber, iEpisodePartNumber (same series fields as existing EPG type)
      
2. Add the following to PVR_RECORDING type
   
   1. strEpisodeName, iSeriesNumber, iEpisodeNumber, iEpisodePartNumber (same series fields as existing EPG type)
      

@ksooo suggested API changes might be a little 'complicated', so I'll start here and see what people think before I submit a PR.

Reasons as identified in my previous two posts...

[scarecrow420]

From my perspective I agree may as well add as many optional configurations in the one release and API bump

From my perspective (pvr.wmc) I would actually like to have yet another option

WMC has a "keep" setting which I've mapped to lifetime - this had options like until watched, until deleted, until space needed and forever.

But WMC also then has a "keep up to" setting that has options like 1,2,3,4,5,6,7,8,9,10 episodes, latest episodes, unlimited

I started down the track of using the "recording group" field for this but that precludes me from actually using recording groups. Do any other back ends have a similar concept to "limit/number to keep" in addition to the lifetime option of how long to keep?

[metaron]

@scarecrow420 pvr.mythtv has a very similar arrangement. The code builds a Lifetime list which includes

• ...
  
• Keep 2 newest and expire old
  
• Keep 1 newest and expire old
  
• Recordings never expire
  
• Allow recordings to expire
  
• Keep up to 2 recordings
  
• Keep up to 3 recordings
  
• ....
  

See:

• Filler: https://github.com/janbar/pvr.mythtv/blo....cpp#L1219
  
• Conversion: https://github.com/janbar/pvr.mythtv/blo...5.cpp#L770
  

This doesn't give access to all the possible combinations, but imo all the essential ones are there.
Do you think this approach would work for pvr.wmc as well?

[scarecrow420]

Obviously if we have to work around Kodi API fields then we can either try to combine them as you've done, or hack/use another field as I've done, but I wonder if more than one addon could use it we could add a "recording limit" field in your proposed API changes

In my case I don't think combining them is ideal since it makes the options confusing

Keep until watched (unlimited)
Keep until watched (newest episodes only)
Keep until watched (1..2..3....10 etc)
Then repeat those several options for keep forever, keep until space needed etc. Even only supporting 3 or 4 of the various "limit" options really multiplies out the lifetime choices so I rather not expose the limit at all or (mis)use the recording group field if I have to.

Would be good if we could add a "recording limit" field in the API though...