[metaron]

I've had a go at implementing a 'series' control type based on the ideas in the previous post:
https://github.com/metaron-uk/xbmc/commits/pvrAPI

Let me know what you think.

[scarecrow420]

I'll need to check but I'm pretty sure the Epg data in my area doesn't ever provide a series or episode number, but DOES still provide the boolean IsSeries=true on shows that are series recording capable. As such, your changes wouldn't work for my area

[scarecrow420]

OK yep ive just confirmed that with my EPG (over the air Australian broadcast) on our backend (WMC -> ServerWMC) we have 0 for SeriesNumber and 0 for EpisodeNumber but still get the boolean IsSeries=true. Countries with digitally downloaded EPG probably have these series/episode data but for OTA scraped EPG (or at least in Australia) these values arent provided, but the IsSeries is (whether WMC internally figures this out or not im not really sure).

Long story short, you can't just do the Series/Episode/EpisodePart > 0 check, I think we need a boolean in Kodi EpgTag for IsSeries. If you want to limit changes to the other addons, you can always make it so EpgTag->IsSeries() will return soemthing like

Code:

return (m_bIsSeries         ||    // The new boolean
        SeriesNumber() > 0  ||    // legacy overrides for any addons that set these details but not the new boolean
        EpisodeNumber() > 0 ||
        EpisodePart() > 0)

[metaron]

Posting this here so part of the discussion on https://github.com/xbmc/xbmc/pull/8032 gets a wider audience:

Regarding new 'status' flags for PVR recordings:

bExpiresNever: seems to have supporters (for a future icon etc...) so we'll keep that.

bRecordingInProgress: while this flag won't actually solve the buffering issue mentioned in https://github.com/xbmc/xbmc/pull/7905 , I think it is important to know if a recording is being added to. I would like to use this status to make the 'recording' icon in the EPG view change to a 'play' icon when the recording stops, rather than assuming it continues until the end of the EPG tag entry, even if the recording/timer has been cancelled. It could also be used to drive an icon in the recordings list to show 'in progress'. There are probably other things which kodi could do with this flag (or a change of state of this flag) in the future. To me, it seems a key piece of information to have available about a recording, so I would like to keep it.

bExpiresSoon / iExpirationDate / iLifetime: Backend expiration policies aren't all the same. Lots aren't date based (e.g. delete 'old' recordings when out of disk space and want to record something new).

IMO, for backends with a date based expiration policy iExpirationDate can already be expressed by decrementing iLifetime so it counts down to '0' on the day the recording expires.

Mythtv (and probably other backends) have a 'hit list' of those recordings which will be next in the firing line when deletion is required to make disc space.

I was thinking that the combination of iLifetime, bExpiresNever and bExpiresSoon could therefore be used to cover several types of expiration policy, without the restriction of always having to specify a time period.

The main reason I didn't call it 'ExpiresWithinTheNext<insert value here>', was that I wasn't sure what the threshold should be and thought therefore that allowing flexibility for individual backends in defining the threshold by calling the period 'Soon' was a good thing. (mythtv's value would probably best be expressed in Megabytes!)

If this ambiguity is considered unacceptable, maybe bExpiresWithin48hrs? (I suppose pvr.mythtv could make an assumption based on upcoming recordings and a nominal data rate?)

[metaron]

OK yep ive just confirmed that with my EPG (over the air Australian broadcast) on our backend (WMC -> ServerWMC) we have 0 for SeriesNumber and 0 for EpisodeNumber but still get the boolean IsSeries=true. Countries with digitally downloaded EPG probably have these series/episode data but for OTA scraped EPG (or at least in Australia) these values arent provided, but the IsSeries is (whether WMC internally figures this out or not im not really sure).

Long story short, you can't just do the Series/Episode/EpisodePart > 0 check, I think we need a boolean in Kodi EpgTag for IsSeries. If you want to limit changes to the other addons, you can always make it so EpgTag->IsSeries() will return soemthing like

Code:

return (m_bIsSeries         ||    // The new boolean
        SeriesNumber() > 0  ||    // legacy overrides for any addons that set these details but not the new boolean
        EpisodeNumber() > 0 ||
        EpisodePart() > 0)

I was afraid you would say that.

The problem with adding a bIsSeries boolean to the EPG_TAG data is that as it's also stored in the EPG DB, a database schema change is required :-(.

Will take a look, but probably this will push the change out past Jarvis Alpha 3 (cutoff 20th Sept) as I'm away from 16th to 21st. This means it might miss Jarvis completely as @ksooo suggested there won't be an Alpha 4 and API changes are out for Beta 1.

I suppose there's no appetite for setting EpisodePartNumber to '999' in this case...

[metaron]

I've had a go at adding some 'EPG flags' to cater for 'IS_SERIES' and one or two other things which a bit of quick googling showed up.. (https://github.com/xbmc/xbmc/pull/8032)
I still need to do the database bit though....

@krustyreturns / @scarecrow420 / others - any comments?

[krustyreturns]

Beautiful. My comment is: you rock metatron - thank you.

[scarecrow420]

Regarding the "IsSeries" boolean field on EPG (and yes it's a pain this is stored in the EPG database, particularly since I turn off the EPG database on my Kodi installation haha) if the changes cant be done in time, then I am happy to just set EpisodePartNo to a non zero value for EPG items that WMC indicates are series but the series info is blank (eg with Australian OTA EPG).

[metaron]

@krustyreturns - thanks
@scarecrow420 - I will try and get the database bit done this evening, (and maybe even the addon.xml.in bumps) but as I'm off on holiday tomorrow I won't be here to incorporate any feedback before the Alpha 3 deadline on the 20th :-(.

If you really want this in Jarvis, (given that @ksooo says Alpha 3 is likely to be the last chance to do API changes) then it may require some pushing / addressing of comments.

Like I said in the PR, if someone wants to cherry pick (or clone my branch to address comments) so this makes it into Jarvis, please go ahead :-)

Edit: My PR is now complete and ready for review/testing (https://github.com/xbmc/xbmc/pull/8032)

[metaron]

First, thanks to @scarecrow420 for getting the 'is_series' part of this PR into Jarvis at the 11th hour.

Regarding the remaining ideas in my PR, here is a summary of my current thoughts as potential candidates for Kxxxxx:

regarding 'strSubtitle' for PVR_TIMERs:
This has two benefits I can see, but they aren't necessarily 'must haves':
1) The skin can choose if it wants to display subtitles for timers, and when it does, choose the format to display them (i.e. separated by a dash (as pvr.mythtv used to do), enclosed in brackets (as confluence currently does for strEpisodeName), a separate column, or whatever it wishes). This means that a skin can ensure consistent presentation of 'subtitle' in the EPG, recordings and timers lists.
2) The main benefit I can see however is that 'Find Similar' can return similar items by searching on 'title' alone. The presence of subtitle in brackets as part of the title field for upcoming shows means it never returns anything using pvr.mythtv at present.


regarding 'iLifetime' 'bExpiresNever' and 'bExpiresWithin24Hrs' (replacing 'soon'):
iLifetime == bExpiresNever == bExpiresWithin24Hrs == 0 : not defined / not used
iLifetime >0, bExpiresNever == bExpiresWithin24Hrs == 0 : expires in iLifetime days
iLifetime == 0, bExpiresNever == 1, bExpiresWithin24Hrs == 0 : will never expire
iLifetime == 0, bExpiresNever == 0, bExpiresWithin24Hrs == 1 : will expire within 24 hrs
Maybe bExpiresNever + bExpiresWithin24Hrs could be made a 2 bit 'validity' field for iLifetime
(00 = use if non-zero; 10 = expires never; 01 = expires within 24h, 11 = reserved), but that might be overkill - booleans are easier to code!
I will see if I can come up with some preliminary 'icons' and logic for skins to use here.

regarding 'bRecordingInProgress':
I think it is useful to present a 'currently recording' icon in the recordings screen to inform the user and possibly to drive extra context menu options like 'stop recording' or 'watch live'. Using it to disable or enable 'realtime' caching of the stream is broken as @FernetMenta pointed out, so this isn't a proper use of the flag. That needs a different API change!

regarding the new iFlags variables for EPG entries:
Might be worth me taking a look at Emby as @krustyreturns suggested. I can see icons indicating 'surround sound', '3d' or 'audio description' for example might be really useful for some users and clutter for others, so probably this needs configuration options as well as confirmation that a backend can drive them.
I get the impression WMC can could do some of this already, but pvr.mythv although it has some of the data in the backend and uses it in the internal EPG, doesn't offer it up via the services interface (yet!)

Still I've plenty of non-api changes to keep me busy for now!

[krustyreturns]

regarding 'strSubtitle' for PVR_TIMERs:
I think having the subtitle field available for timers would be nice, but not a must have. But appending it to the title string doesn't seem like a problem to me, maybe because I don't understand 'find similar' as applied to timers. I think if was issuing that command as a user, I'd assume I am asking kodi to search the guide for something similar to what I have have scheduled to record - rather than searching the timer list for something similar. Why would I want to find something similar in the timer list?

regarding 'iLifetime' 'bExpiresNever' and 'bExpiresWithin24Hrs' (replacing 'soon'):
I think every timer I create exists forever if it's a series timer, or exists until it completes if it's an episode timer. So this doesn't seem that useful to me. (so yeah, do whatever is easier)

regarding 'bRecordingInProgress':
?? I don't understand what this one is for, kodi has all the data it needs to figure out if a recording is in progress.

regarding the new iFlags variables for EPG entries:
I don't think wmc can support all the flags you suggested, but I would still like to have them. It seems to me it is useful for the skin guys to provide more info to the user about programs, and it enables better searching - for example searching for all the upcoming HD only broadcasts of a movie. I don't see that there is a problem if a backend's guide source doesn't have this data - it just means kodi runs as it does now. But if we have the data, why not make it accessible to the user? To keep the guide less busy, some of this data would probably only be presented if the user chooses to get info about the program entry. emby example

[metaron]

regarding 'strSubtitle' for PVR_TIMERs:
I think having the subtitle field available for timers would be nice, but not a must have. But appending it to the title string doesn't seem like a problem to me, maybe because I don't understand 'find similar' as applied to timers. I think if was issuing that command as a user, I'd assume I am asking kodi to search the guide for something similar to what I have have scheduled to record - rather than searching the timer list for something similar. Why would I want to find something similar in the timer list?

'Find Similar' returns similar EPG entries to the selected Timer entry, or at least it would if the timer 'Title' didn't have have " (<subtitle>)" appended to the end of it, messing up the search string. That's the point. I thought of the change mainly because I wondered why the 'Find Similar' context menu option didn't work the way I expected it to from the timer list.

regarding 'iLifetime' 'bExpiresNever' and 'bExpiresWithin24Hrs' (replacing 'soon'):
I think every timer I create exists forever if it's a series timer, or exists until it completes if it's an episode timer. So this doesn't seem that useful to me. (so yeah, do whatever is easier)

This relates to PVR_RECORDING type, not PVR_TIMER type. It would allow the UI to indicate which recordings will be 'kept forever' and which are currently on 'death row'. At present expired recordings just disappear, which I admit isn't that much of a problem for me as I have 2.5TB of storage and I move anything I want to keep to a separate 'Box Sets' group/folder using mythfrontend / the original recording rule. It would be nice to be able to do this from Kodi as well for isolated recordings though...

regarding 'bRecordingInProgress':
?? I don't understand what this one is for, kodi has all the data it needs to figure out if a recording is in progress.

IMO It does for timers, but not for recordings. (Or else why was 'CPVRRecording::IsBeingRecorded' doing something clever using an associated EPG Tag entry?) Again it's probably more of a 'tidy up the loose ends' type of change than a killer feature. Loose ends irritate me.

[ksooo]

regarding 'strSubtitle' for PVR_TIMERs:
I think having the subtitle field available for timers would be nice, but not a must have. But appending it to the title string doesn't seem like a problem to me, maybe because I don't understand 'find similar' as applied to timers. I think if was issuing that command as a user, I'd assume I am asking kodi to search the guide for something similar to what I have have scheduled to record - rather than searching the timer list for something similar. Why would I want to find something similar in the timer list?

'Find Similar' returns similar EPG entries to the selected Timer entry, or at least it would if the timer 'Title' didn't have have " (<subtitle>)" appended to the end of it, messing up the search string. That's the point. I thought of the change mainly because I wondered why the 'Find Similar' context menu option didn't work the way I expected it to from...

Agree to @krustyreturns here. I improved the find similar functionality to behave more like one would expect: https://github.com/xbmc/xbmc/pull/8144

[Jönke]

@ksooo, did you also fix find similar from channel epg ? It has been broken for a while

[metaron]

regarding 'strSubtitle' for PVR_TIMERs:
I think having the subtitle field available for timers would be nice, but not a must have. But appending it to the title string doesn't seem like a problem to me, maybe because I don't understand 'find similar' as applied to timers. I think if was issuing that command as a user, I'd assume I am asking kodi to search the guide for something similar to what I have have scheduled to record - rather than searching the timer list for something similar. Why would I want to find something similar in the timer list?

'Find Similar' returns similar EPG entries to the selected Timer entry, or at least it would if the timer 'Title' didn't have have " (<subtitle>)" appended to the end of it, messing up the search string. That's the point. I thought of the change mainly because I wondered why the 'Find Similar' context menu option didn't work the way I expected it to from...

Agree to @krustyreturns here. I improved the find similar functionality to behave more like one would expect: https://github.com/xbmc/xbmc/pull/8144

Looks like this fixes most of my reason for wanting to add the subtitle field. There is still the issue of the format for the subtitle being set by the addon rather than the skin, but I think this quirk isn't a real problem. As @ksooo says, the field can be set to anything, although probably for children of a repeating timer it won't be.
I'm still a little uneasy (what if the EPG event for the timer isn't loaded), but not enough to continue pushing for this particular API change at present.