[metaron]

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.

IMO this is down to the way the pvr client implements a 'repeating EPG based' timer.

Kodi core and the current PVR API doesn't have 'series' or 'episode' identifiers (stored as SeriesID / ProgramID in my mythtv backend). The problem with these fields is they are dependent on the quality of your listings source. If some channels come from EIT (over the air) and some from xmltv, you get incompatible IDs. If your EIT data is poor, you might not get SeriesID at all!

IMO however, kodi core doesn't actually need them to schedule a recording. The API provides an EPG entry, a 'title' and some options. The key information here is the 'title'.

• If you ask for a 'single' recording of 'title' the backend should record one.
  
• If you ask for a 'repeating' recording of 'title' the backend should record multiple instances of 'title' (subject to channel, duplicate matching, storage limitations, etc...)
  

If you want to record only items with a SeriesID which matches the selected EPG entry, this can be done as a separate timer type (and has been done for mythtv), but IMO, this is unnecessary as it seems unlikely that a broadcaster would show two series with the same title on the same channel :-).

If the user selects to create a repeating timer for a non-series event (such as a movie), and the backend won't support creation of a repeating timer without a seriesid (this seems strange to me, I don't know why a backend would be hamstrung like this), the addon could simply create a single timer instead.

If there isn't a backend limitation however, I don't see a problem. The user picks a 'repeating' timer type, the backend will record all 24 repeats of the movie in the next 6 weeks. Next time the user will choose a 'record once' type for a movie ;-).

[metaron]

I suppose there might be problems if the client is still supplying 'title' and 'subtitle' together (API 3.0.0 allows 'strTitle' and strEpisodeName to be supplied separately for this reason), if the backend doesn't have a concept of 'title' and 'subtitle' and supplies the client one long string, or if your 'series' is in the habit of having different 'titles' for each episode.

I've noticed 'NEW: ' added to the front of shows on the UK EIT (over the air) guide. Fortunately the XMLTV feed i use removes these, but it might be useful to use 'seriesid' instead if only the 1st showing has 'NEW: ' at the front and you want to catch repeats if conflicts prevent you recording the 1st showing of some episodes in a series.

This sounds like backend specific teritory however, so I would suggest the complication belongs in the client if the backend doesn't already handle it.

[scarecrow420]

I guess the issue is that we have to throw an error because a user is allowed to create an Epg based repeating timer for an Epg entry that isn't a series (which in WMC isn't valid).

A repeating timer for "title" is a keyword recording not a guide/Epg recording so I guess we can "change" what we created, but then we aren't really doing what the user asked for. It would be good if there was an Epg item property boolean for whether a repeating Epg timer is allowed and then a condition on the timer creation GUI that doesn't show repeating Epg based timer when the Epg tag indicates it's not a series.

If someone had poor Epg data and no series that would be fine as they would then specifically use the keyword type repeating timer (which would be available when created off these Epg items)

[krustyreturns]

Yes, exactly. Just a simple boolean on each guide entry that says whether it's part of a series (for example IsSeries).

Other guide entry booleans that are useful - but for searching - are IsMovie and IsSports.

[metaron]

I suppose this taken to it's logical conclusion results in a 'record' menu option which is dependent on the selected EPG entry.

I've seen a BT youview box in the UK do this, which seems to work well:

• If you select an item which is part of a series, you get the options: Record this / Record Series
  
• If you select an item which is not part of a series, it just records the selected item
  
• If you select an item which is also being shown in HD at the same time, you get: Record this / Record in HD
  
• If you select a timer entry which is part of a series, but a single record rule, you get: Cancel recording / Convert to series
  
• Similar options exist for HD->SD conversion and Series to one off recording.
  

This same box also shows a 'play' icon for things available on catch-up TV, or already on the hard-disk (even when a show in the future is a repeat of something already recorded) which I was very impressed with.
This is however all very tightly coupled to guide data, which the software on the box was designed around.

Personally, I don't need to be asked if I want to record in HD if there is an option, just do it (which I why I choose 'any channel' rules for my mythbackend and give the HD channels a higher priority).
I suppose only allowing series recordings for things which are series would simplify things from a UI perspective from the 'record' option, with 'title search' rules handled via 'add advanced timer'.

If you are doing this however, I think it would be better to include a full 'seriesid' in the Kodi EPG, rather than just a boolean, so you could 'Find Series', rather than just do a 'Find Similar' search (which works on title).

It would also be good to add 'programid' so that duplicate programs could be tagged / found: 'Find alt showing'.
This would also allow kodi to choose to present 'record once' rather than only 'record this' as an option for a non-series.

I do wonder if this is however adding more complexity to Kodi core than is necessary.
What about simply having a 'supported timer types' bitmask on each EPG entry (size int), I can't see a client needing more than 32 timer types (with 0 = all valid ones) and it would allow pvr clients which wanted to restrict valid types for an EPG entry to do so.

[skarragallagher]

The option to record to prefer HD or SD is needed in my case since the guide data for some HD channel is incorrect since Microsoft changed guide date sources

[krustyreturns]

I suppose this taken to it's logical conclusion results in a 'record' menu option which is dependent on the selected EPG entry.

Well, this is exactly the conclusion I want. Really that is all I want.

But I still think the seriesId & programId are not necessary for the guide entries. If in the future kodi wants info related to a given guide entry they can just query it from the backend using the epgid. For example, in the future kodi could display all the upcoming episodes for an entry the user has right-clicked in the guide. As long as kodi knows its a series using the boolean, it can query the backend using the epgID for all of the upcoming episodes.

I agree about HD, I think the best way to handle HD is just to have a global setting on the backend that says HD-only or HD-preferred, etc. Doesn't this only matter if the user has chosen 'Any Channel' as a record setting anyway? Because as long as the user chose an HD channel to start with there should be no issue.

[ksooo]

fyi, I will PR https://github.com/ksooo/xbmc/tree/pvr-api-4-0-0 for inclusion into Jarvis, soon.

Contains just cleanup changes:
- Removal of the senseless "Keep children on delete of timer schedule" discussed here
- Introduction of dedicated constant for invalid timer client index to solve signed/unsigned problems in Kodi core and to get rid of magic numbers here

Cheers,
Kai.

[metaron]

I suppose this taken to it's logical conclusion results in a 'record' menu option which is dependent on the selected EPG entry.

Well, this is exactly the conclusion I want. Really that is all I want.

OK, WMC only allows repeating EPG timers for EPG entries which are 'series'. I agree there is nothing more frustrating to a user than 'backend rejected' so absolutely there ought to be a method of preventing this by manipulating the UI.

The precise handling of each timer type however is down to the client, so only the client can know in advance which timer types are valid for a particular EPG entry.

API 3.0.0 added 'TIMER_TYPE_REQUIRES_EPG_ON_CREATE' and TIMER_TYPE_FORBIDS_EPG_ON CREATE' to complement TIMER_TYPE_FORBIDS_NEW_INSTANCES, which introduced some control over which menus a timer type is presented in.

I'm thinking that 'TIMER_TYPE_REQUIRES_EPG_SERIES_FLAG' could be added, along with an EPG 'series' boolean kodi PVR core uses to 'enable' or 'disable' affected timer types in the 'add custom timer' menu.

But this only caters for one scenario at a time. Can anyone think of other scenarios in which a client might want to prevent a certain group of timer types from being selected for an EPG entry?

(mythtv has a 'this series' filter, used by one of the current pvr.mythtv timer types. When first implemented this was always on for all repeating EPG timers. I saw a posting requesting this filter be removed as the user's guide data didn't set 'seriesid' so nothing got recorded. This is where my worries came from. It also means that the mythtv client could find a use for this feature as well.)

[metaron]

fyi, I will PR https://github.com/ksooo/xbmc/tree/pvr-api-4-0-0 for inclusion into Jarvis, soon.

Contains just cleanup changes:
- Removal of the senseless "Keep children on delete of timer schedule" discussed here
- Introduction of dedicated constant for invalid timer client index to solve signed/unsigned problems in Kodi core and to get rid of magic numbers here

Looking good. Will probably require a tweak to pvr.mythtv though as I think it uses that 'magic number'.

However, if you're removing magic numbers and fixing API signed/unsigned problems, here are some more to consider:

1. PVR_TIMER.iEpgUid - set to "-1" to indicate 'no associated EPG entry'
   
2. PVR_TIMER.iEpgUid is type 'int'. The matching PVR_RECORDING.iEpgEventId and EPG_TAG.iUniqueBroadcastId are unsigned int.
   

[krustyreturns]

Good, and thanks for the discussion. I personally can't think of any other timer types that the user should be restricted from, other than epg based series recordings.

But on the subject of adding a boolean to the core for each entry, why not provide more info so the kodi guide can display it. This is what we send back to Emby for each guide entry:

Code:

public enum ProgramType
    {
        none = 0,
        IsRepeat = 1,
        IsSeries = 2,
        IsHD = 4,
        IsMovie = 8,
        IsSports = 16,
        IsKids = 32,
        IsLive = 64,
        IsNews = 128,
        IsPremiere = 256,
        IsFinal = 512
    }

Having this sort of info available for each guide entry gives the guide view the possibility of more display richness (once skinners adopt it). Take a look at screenshots of the emby guide view.

Thanks @ksooo for removing the option to keep the orphaned timers.

[ksooo]

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.

Fixed and merged ( https://github.com/xbmc/xbmc/commit/5af9...c3ab03fa68 ).

[metaron]

But on the subject of adding a boolean to the core for each entry, why not provide more info so the kodi guide can display it. This is what we send back to Emby for each guide entry:

Code:

public enum ProgramType
    {
        none = 0,
        IsRepeat = 1,
        IsSeries = 2,
        IsHD = 4,
        IsMovie = 8,
        IsSports = 16,
        IsKids = 32,
        IsLive = 64,
        IsNews = 128,
        IsPremiere = 256,
        IsFinal = 512
    }

Having this sort of info available for each guide entry gives the guide view the possibility of more display richness (once skinners adopt it). Take a look at screenshots of the emby guide view.

Isn't this slightly duplicating info available in the 'genre' fields (especially Kids/Sports/News).
I can certainly see that HD, Repeat etc... might be useful though.

[krustyreturns]

Yeah maybe. I have never been clear how one is supposed to use those genre codes for tv. For example, you can mark a movie as a comedy, but how do you mark a tv series as a comedy without also saying it is a movie? So what I end up doing is just ignoring that most of those genres are for movies and just pretend they are for both. But then when the user does a movies search in the guide they get a bunch of false hits (shows that aren't movies). At least I think this was the problem, to be honest I haven't looked at it for a while.

[metaron]

@krustyreturns / @ scarecrow420:

Regarding identifying an EPG entry as a 'series' what about using a condition like:

if (EPG_TAG.iSeriesNumber > 0 || EPG_TAG.iEpisodeNumber > 0 || EPG_TAG.iEpisodePartNumber > 0)
to control the presence of a timer type in the menu
(see https://github.com/xbmc/xbmc/blob/master...ypes.h#L93)

along with a new:

TIMER_TYPE_REQUIRES_EPG_SERIES_ON_CREATE
(on https://github.com/xbmc/xbmc/blob/master...pes.h#L135 )