• 1
  • 2(current)
  • 3
  • 4
  • 5
  • 12
Planned API changes for Series Recordings
#16
Hi @ksooo. Refactoring of the schedule manager for pvr.mythtv addon is progessing. I pushed a branch with all current changes. But i am afraid to have used some existing behaviors of the api which could not awaited.
I created 1 manual timer type, 4 repeating and 5 others without manual or repeating flags. All "select type list" screens, in "add timer" or "guide custom timer", only show types with flags manual or repeating: this is good for me because those 5 last types are not timer rule. I use them to type scheduled and they have always a manual or repeating timer type as parent. Also 4 last have short list of attributes: only those updatable for their scheduled type. Finally first of those 5 is used by api to create a live timer or "not customized" timer from guide.
So my question is do you think these behaviors, summarized below, will be kept in the future ?

Rule #1 - Select boxes to choose timer type always shows only timer types with MANUAL or REPEATING attribute.
Rule #2 - Live timer and Guide timer use the first timer type (in order of rank in timer type array) without MANUAL and REPEATING flags, but with at least attribute flags: CHANNELS, START_END_TIME, (and maybe more)
Reply
#17
(2015-06-17, 18:42)metaron Wrote: I also worked out how Lifetime could be tweaked to allow non-integer settings - so no more doubts there!
Hi @metaron. I think no need to tweak. In all case we should use enum (int) to map with backend api values. As sample MythTV api supports only true/false for recording expiration (autoexpire) because the expiration rules are configured in backend, not by recording rule. In my current dev i show values like "Never recording expires" for false and "Allow recording to expire".
Reply
#18
@janbar

Some terminology:
manual == timer values like start and end time are entered manually
epg-based == timer values like start snd end time are obtained from an epg event
=> not manual == epg-based (not setting the "manual" attribute means "epg-based")

repeating == timer rule
one-shot == scheduled timer, every one-shot timer should have a repeating timer as "parent"
=> not repeating == one-shot (not setting "repeating" attribute means "one-shot")

A timer type with neither repeating nor manual attribute set is not "hidden", but one-time epg-based.

Regarding rule #1: One-time epg-based timers do currently not show up in the timer settings dialog, because this dialog currently(!) cannot be used to create such timers as this would require a dialog (or similar) to select an epg-event to use as data source for the timer. Such a "dialog" is to my best knowledge today not available. Therefore I decided to "hide" all epg-based one-shot timers from the list of available timers for now. But this can change at any time in the future. Conclusion: Current behavior to hide one-shot epg-based timers can change at any time

Regarding rule #2: Not 100% sure what you mean, sorry. "live timer" means one-time manual and "guide timer" means one-time epg-based?! "Using" means "show in timer settings dialog"? Assuming I'm right with this interpretation, the timer selection list in the timer settings dialog simply show all types reported by the addons, with the only exception of one-time epg-based timers for the reason given above. Furthermore, there are no assumptions made in the code on what attributes a timer must have. If and only if you define an attribute you will get the respective control in the timer settings dialog. OTOH, if you create a timer using context menu entry "add timer" or "add custom timer" from inside the epg window, the first timer type matching epg-based and non-repeating (in case of "add timer") or epg-based and repeating (in case of "add custom timer") will be chosen. Here, the order you supply your types in the timer types array is actually important.

HTH, Kai.
Reply
#19
(2015-06-19, 15:06)ksooo Wrote: ...Therefore I decided to "hide" all epg-based one-shot timers from the list of available timers for now. But this can change at any time in the future. Conclusion: Current behavior to hide one-shot epg-based timers can change at any time
So it would be great to add attribute flag like IS_UNUSABLE. In my next sample:
Code:
typedef enum
{
  TIMER_TYPE_ONCE_MANUAL_SEARCH       = 1,// Manual record
  TIMER_TYPE_THIS_SHOWING             = 2,// Record This showning
  TIMER_TYPE_ONE_SHOWING,                 // Record one showning
  TIMER_TYPE_ONE_SHOWING_WEEKLY,          // Record one showing every week
  TIMER_TYPE_ONE_SHOWING_DAILY,           // Record one showing every day
  TIMER_TYPE_ALL_SHOWINGS,                // Record all showings
  // KEEP LAST
  TIMER_TYPE_RECORD,                      // Record
  TIMER_TYPE_OVERRIDE,                    // Override
  TIMER_TYPE_DONT_RECORD,                 // Don't record
  TIMER_TYPE_UNHANDLED_RULE               // Unhandled rule
} TimerTypeId;
"Record", "Override" and "Don't record" are NOT usable as rule, rather they are really timer. Same for "Unhandled" which is the type to group all rules not handlable by addon. But all of them have to be show in timer screen.
Reply
#20
@janbar not sure I understand what you're trying to achieve. Maybe attribute read-only is what you are looking for. I forgot to memtion that timers ettings dialog does not show timers marked with this attribute in the timer types list - and yes, this behavior will be the same in the future:

https://github.com/ksooo/xbmc/blob/pvr-s...s.cpp#L700

I'm using this attribute exactly for the timers created by recording rules:

https://github.com/ksooo/pvr.hts/blob/se...d.cpp#L627
Reply
#21
Exactly that ksooo. But in my case those types have to be updatable, so not read only: They have few attributes can be updated manually by the user as enable/disable, priority. Today it runs , but if the behaviors will change in the future i am afraid those type will be show in select boxes. So the same as IS_READONLY but they are not readonly just they are not selectable to create a rule.
Reply
#22
Ah, I see. Obviously such an attribute is still missing in the API. Let's pinpoint the semantics:

Timers containing this attribute
* shall not be creatable by the client (esp. not appear in the timer type list when it is in "create a new timer" mode.)
* can be edited by the client (appear in the timer settings dialog when the dialog is "edit an existing timer" mode.)
* cannot be deleted by the client

Anything else?
Reply
#23
Photo 
Yes but it can be updated and delete too. If delete is not allowed then addon can handle this itself.
Here a sample screen for override containing limited attributes updatable:
Image

So:
* shall not be creatable by the client (esp. not appear in the timer type list when it is in "create a new timer" mode.)
* can be edited by the client (appear in the timer settings dialog when the dialog is "edit an existing timer" mode.)
* CAN be deleted by the client: depending of the context addon do or doesn't do the delete
Reply
#24
Okay. Will implement this the next days and report back, then. Thanks for bringing this up, @janbar.
Reply
#25
Out of interest, will these changes do away with the need for custom series record dialogue boxes?

Thanks
Reply
#26
Yes, that's one of the goals of the API change.
Reply
#27
(2015-07-05, 11:50)ksooo Wrote: Yes, that's one of the goals of the API change.
Fantastic news, one of my biggest bug bears.

Do you think this will definitely make it in to the J****** release?

Keep up the good work
Reply
#28
Yes, the respective code already got merged for J****.
Reply
#29
(2015-07-05, 11:59)ksooo Wrote: Yes, the respective code already got merged for J****.
Great news, just read the whole Github thread on this. Really appreciate your work to get this over the line. Well done
Reply
#30
@ksooo
Rather than start a new thread myself, I'll post my questions/ideas here (as they are related to the code added by this PR / API change). Hopefully this is OK and they make sense.

I had an idea to set the displayed time of a repeating timer to the 'Start Time' of its next recording, or if null the 'Start Time' of its last recording, or if null the 'Start Time' for that timer specified by the backend. End Time is set as Start Time + backend (end-start).

This has the advantage that repeating timers move in the list when sorted by 'Date' so you can see quickly in which order upcoming repeating timers did something recently, which are currently active and which are about to do something.

There are however some problems:
  1. Manual timers don't sort 'by date' (or name) with repeating timers. They always appear below them. This is confusing.
  2. 'Any Time' timers need to have startTime=endTime=0 to show as 'Any Time'. If you do this they show as starting on 1/1/1970 (i.e. not in date order anymore)
  3. If your backend has a lot of timers floating about (i.e. you're a movie buff and your backend doesn't automatically delete completed timers), the list can get a little long!
  4. If a repeating rule has active conflicts or currently in progress recordings, how should this be highlighted in the list when 'group timers' is on?

Manual/Repeating not sorting together
Is there any reason why the list isn't sorted as one?

Repeating Timer 'Date'
I note that PVR_TIMER.strSummary seems to be populated with the description of the time which appears in the 'Scheduled time' column when an updated timer is sent to the client for action. Is this the field used to sort 'by date', or could it be made the method of doing so?
If so, could the code allow a client to specify the 'Date' string to be used by setting PVR_TIMER.strSummary? A null string would indicate to PVR core that it should fill it itself. This would allow a client to decouple the 'Date' sort from the 'AnyTime' option. Do you think this idea has merit?
Sure, a separate bAnyTime flag would be better and less prone to localization issues, but it would need an API change Sad.

Lots of timers
I was wondering if it might make sense to allow (optional) filtering out of repeating timers which weren't created recently, hadn't recorded anything for a while (say within the last week / extent of retained EPG information?) and weren't planning to do something in the near future (i.e. no pending subordinate timer)?
This would need to be on/off controllable in some way so that Kodi could still be used to weed out / fix broken timers.
Sure it could be done by the addon, but maybe a 'Kodi standard' way would be better?

Echoing up subordinate timer status
It seems to be possible for the client to change the status of a 'parent' timer to show 'conflict' or 'active recording' associated with a 'subordinate' timer below it, but this hides the 'Active/Inactive' status of the parent (although you wouldn't expect to see these if the parent was 'inactive').
Is this the method you had in mind for this scenario, or did you envisage something else?

I'm happy to try prototyping any of these in PVR core if you think they have merit. Let me know.
Reply
  • 1
  • 2(current)
  • 3
  • 4
  • 5
  • 12

Logout Mark Read Team Forum Stats Members Help
Planned API changes for Series Recordings0