[MikeB2013]

@janbar

Just an update, not finished testing yet, and basically confirming identified issues from earlier contributors to this thread.
I built kodi from ksooo pvr-recordings branch, and your series recording branch (including 23 June commits)

1. Record All Showings on Any Channel has problems. This Channel filter is being set, and timer display showing a specific channel (instead of any). I use Any Channel frequently (in UK we have lots of +1 hour channels)

2. Remove ? in Recording Group, should default to "Default"

3. Add "Record new and expire old" together with "number of recordings to keep" (I use this quite often for certain news programs, usually keeping 2)

4. Add subtitle/Series/Episode to title.

5. Typo in various screens "shownings" should be "showings"

Mike

[janbar]

@metaron, i tried timer type as you have specified (daily and weekly). But an issue came back again: In the myth source code, file recordingrule.cpp, the method IsValid breaks creation (from api) of any override with search type manual. That's means we cannot create valid rule "don't record" for all manual rule. Overriding seems to be valid by changing search type to "noSearch", but this hack doesn't work with "don't record" and i would prefer to not hack the behavior to avoid issue in backend itself. So finally it is preferable to make rule with search type noSearch (epg based) or titleSearch, keyword search etc , even in daily or weekly rules.
That is why i have added the field "EPG search" for those rules.

Edit: and finally attribute check duplicate could be usable for those rules which should be named: Find weekly and Find daily instead.
recordingrule.cpp: in MakeOverride(): a manual override must keep search type as manual

Code:

if (m_searchType != kManualSearch)
        m_searchType = kNoSearch;

recordingrule.cpp: in IsValid(): DontRecord & OverrideRecord are forbid for search type manual !!! :-\

Code:

if ((isNormal && (m_type == kDailyRecord || m_type == kWeeklyRecord)) ||
        (isSearch && (m_type != kDailyRecord && m_type != kWeeklyRecord &&
                      m_type != kOneRecord && m_type != kAllRecord)) ||
        (isManual && (m_type != kDailyRecord && m_type != kWeeklyRecord &&
                      m_type != kSingleRecord && m_type != kAllRecord)))
    {
        msg = QString("Invalid recording type/search type.");
        return false;
    }

[janbar]

@MikeB2013,@metaron, thanks for your feedback. This evening i can get some time to fix found issues and maybe more: I will let you know.

[metaron]

@janbar

I found a small bug in the 'Record all showings' code if you set up an 'Any Channel' recording.
...
I had a quick look but I'm afraid I haven't quite found the culprit yet...

I've found the culprit and had a go at fixing it. It got quite involved (see https://github.com/metaron-uk/pvr.mythtv...eriesfixes )
NB: This includes your splitting out of the MythScheduleHelper75/76 functions.

In the end the easiest way seemed to be adding a separate boolean to the MythTimerEntry structure.
That way the chanid (which the mythbackend scheduler seems to rely on) stays intact.
I haven't tested it on a 0.26 (75 helpers) or a 0.28pre backend. Works fine on 0.27.4.

I'm continuing to debug the 'Any Channel' selection for 'Record every week' and 'Record every day' rules and to check for other corner cases. I'm guessing there isn't a way to prevent them from appearing in the list, so best would be to say 'no' politely and not modify the rule.

If I find any more bugs related to 'Any Channel' I'll push some extra commits to my seriesfixes branch.

Comments on Timers screen
Scheduled time
For repeating timers, currently this is set to 'startdate / starttime'. This matches the order in mythweb, but gives you no idea when that rule will next do something or when it last did something.
I propose: if (next_record != 0) next_record; else if (last_record != 0) last_record; else startdate / starttime;

I've had a play with the implementation of this and all my 'in the past' rules are now getting in the way. I was thinking that somewhere in MythScheduleManager::GetTimerEntries() Rules with which show a scheduled time in the past (i.e. yesterday or before) could be 'skipped' based on m_showNotRecording. I had a go but got confused with how the cpp time() function works.

Hope this helps!

[metaron]

@metaron, i tried timer type as you have specified (daily and weekly). But an issue came back again: In the myth source code, file recordingrule.cpp, the method IsValid breaks creation (from api) of any override with search type manual. That's means we cannot create valid rule "don't record" for all manual rule. Overriding seems to be valid by changing search type to "noSearch", but this hack doesn't work with "don't record" and i would prefer to not hack the behavior to avoid issue in backend itself. So finally it is preferable to make rule with search type noSearch (epg based) or titleSearch, keyword search etc , even in daily or weekly rules.
That is why i have added the field "EPG search" for those rules.

Edit: and finally attribute check duplicate could be usable for those rules which should be named: Find weekly and Find daily instead.
recordingrule.cpp: in MakeOverride(): a manual override must keep search type as manual

Code:

if (m_searchType != kManualSearch)
        m_searchType = kNoSearch;

recordingrule.cpp: in IsValid(): DontRecord & OverrideRecord are forbid for search type manual !!! :-\

Code:

if ((isNormal && (m_type == kDailyRecord || m_type == kWeeklyRecord)) ||
        (isSearch && (m_type != kDailyRecord && m_type != kWeeklyRecord &&
                      m_type != kOneRecord && m_type != kAllRecord)) ||
        (isManual && (m_type != kDailyRecord && m_type != kWeeklyRecord &&
                      m_type != kSingleRecord && m_type != kAllRecord)))
    {
        msg = QString("Invalid recording type/search type.");
        return false;
    }

Sorry Janbar, I seem to have lead you astray with my comments. I didn't mean to change the way the 'Record every week' and 'Record every day' rule was sent to mythtv, just the way it was displayed in Kodi's 'Timer Settings' window and its name.

Daily
Remove 'Search Guide For' entry
Don't show 'Any Channel' (is this possible?), or refuse as Filter: 'This Channel' should always be set.
Don't show 'Prevent duplicate episodes' - This should always be 'off' for this type of recording.
There appear to be bugs if you change 'Anytime' or start/end in the current code.

To do this I was thinking:

1. for timer type TIMER_TYPE_ONE_SHOWING_WEEKLY and TIMER_TYPE_ONE_SHOWING_DAILY, don't show the 'Search guide for' free text field in the Timer settings window. (But maybe this is a comment aimed @ksooo as PVR_TIMER_TYPE_SUPPORTS_TITLE_EPG_MATCH probably does more than just turn on the 'Search guide for' free text field. I'll take a look.)
   
2. for timer type TIMER_TYPE_ONE_SHOWING_WEEKLY and TIMER_TYPE_ONE_SHOWING_DAILY set PVR_TIMER_TYPE_SUPPORTS_RECORD_ONLY_NEW_EPISODES to false. This should remove the ''Prevent duplicate episodes' option from appearing in the Timer settings list. In my opinion duplicate matching for 'channel, time and date' based rules should always be 'none'.
   

Sorry if this caused you to spend time looking in the wrong place!

[janbar]

@metaron, yes right the screen would be more readable. But the timer title allows user to name the rule with his friendly name. Also in myth the rule title has the same usage and all keywords, title, people to search are stored in field description of the rule. At least it is like that in source code.
For a first release we can keep the attributes as ksooo concept. And maybe with usage users don't want the rule name and we will use it to store epg search.
For 2. i agree with you. Also if channel and timeslot are selected then it should be and EPG based. But if i want to record daily at any time a show on one channel. Sometimes the same episode is shown several times during the week, so we need the check duplicate for this case.

EDIT: in fact we have to think a timer type can be used from EPG screen or from timer screen: here the user uses the search facility instead.
@ksooo, maybe only manual timers (manual and manual/repeating) should be selectable in add timer from timer setting. Then we could create some types manual usable in add timer from timer screen and others not manual usable from epg screen.

[metaron]

To do this I was thinking:

1. for timer type TIMER_TYPE_ONE_SHOWING_WEEKLY and TIMER_TYPE_ONE_SHOWING_DAILY, don't show the 'Search guide for' free text field in the Timer settings window. (But maybe this is a comment aimed @ksooo as PVR_TIMER_TYPE_SUPPORTS_TITLE_EPG_MATCH probably does more than just turn on the 'Search guide for' free text field. I'll take a look.)
   
2. for timer type TIMER_TYPE_ONE_SHOWING_WEEKLY and TIMER_TYPE_ONE_SHOWING_DAILY set PVR_TIMER_TYPE_SUPPORTS_RECORD_ONLY_NEW_EPISODES to false. This should remove the ''Prevent duplicate episodes' option from appearing in the Timer settings list. In my opinion duplicate matching for 'channel, time and date' based rules should always be 'none'.
   

Works like a dream. Nice one Ksooo!

Code:

typeList.push_back(MythScheduleManager::TimerType(TIMER_TYPE_ONE_SHOWING_DAILY,
            PVR_TIMER_TYPE_IS_REPEATING |
            PVR_TIMER_TYPE_SUPPORTS_ENABLE_DISABLE |
            PVR_TIMER_TYPE_SUPPORTS_CHANNELS |
            PVR_TIMER_TYPE_SUPPORTS_START_END_TIME |
            PVR_TIMER_TYPE_SUPPORTS_FIRST_DAY |
            PVR_TIMER_TYPE_SUPPORTS_START_END_MARGIN |
            PVR_TIMER_TYPE_SUPPORTS_PRIORITY |
            PVR_TIMER_TYPE_SUPPORTS_LIFETIME |
            PVR_TIMER_TYPE_SUPPORTS_RECORDING_GROUP /*|
            PVR_TIMER_TYPE_SUPPORTS_RECORD_ONLY_NEW_EPISODES |
            PVR_TIMER_TYPE_SUPPORTS_TITLE_EPG_MATCH*/,
            XBMC->GetLocalizedString(30463),

Doesn't seem to have any nasty side effects either.

Looks like PVR_TIMER_TYPE_SUPPORTS_TITLE_EPG_MATCH and PVR_TIMER_TYPE_SUPPORTS_FULLTEXT_EPG_MATCH are only needed for 'Title Search' and 'Keyword Search' and my proposed 'Advanced' timer type

[metaron]

@ksooo, maybe only manual timers (manual and manual/repeating) should be selectable in add timer from timer setting. Then we could create some types manual usable in add timer from timer screen and others not manual usable from epg screen.

I agree.

In my opinion when a user selects to create a timer from an EPG entry they should be presented with a list of options like this:

• This (Just This Specific Showing on this channel. Set up as a 'Manual once'?)
  
• One (At any time on any channel with this ProgramID (or Title/Subtitle))
  
• Series (At any time on any channel with this SeriesID/Title?, full duplicate matching)
  
• Daily (@ this time on this channel, no duplicate matching)
  
• Weekly (@ this time on this channel, no duplicate matching)
  

An 'Advanced Timers' menu could also offer:

• Freetext Title search based on the EPG entry Title (e.g. *Resident Evil*)
  

The 'Add Timer...' option in the Timers list should only offer options that don't need an EPG reference:

• Manual (@this time on this channel)
  
• Daily (@ this time on this channel, every day)
  
• Weekly (@ this time on this channel, on this day every week)
  
• Title/Keyword search
  

However, I may have misunderstood what the 'Daily' and 'Weekly' rules are meant to do.
For just recording the 6'oclock news, or Friday's 7 day weather forecast you don't need any duplicate matching (my guide data doesn't seem to have a programID for most 'News' anyhow, just a seriesid, so duplicate matching probably won't do much)

[philled]

I apologise for jumping in here and I hope this doesn't hijack/upset the thread or the contributors. I have just been pointed here from a response on the MythTV mailing list debating the merits of Mythfrontend vs Kodi. I see that there is a lot of work going on to beef up the Mythbackend recording options through Kodi and I would like to ask a question. Does this include (or are there plans for) support for Mythtv "recording templates"?

A recording template lets you set things like early start and late finish padding, which recording group to store the recording in, whether to do commercial skipping, whether to look up metadata etc. The good thing about them is that you have have more than one - so for example I have a default one for most things, and an additional one for movies which has different settings and the listing category matches the template so it gets automatically applied to programs listed as movies.

[janbar]

@MikeB2013, @metaron, I pushed my proposal 20150625 !

I fixed a lot of your requirements. I let you discover. @metaron for instance not to many change for timer type, but i updated names and probably i will add "Record series": there i need extra info to setup filter correctly because i don't know if i need to use filter ThisEpisode or something else. Do you know about ?

EDIT: ah I missed, I cleaned all my old code in ScheduleManager (dating from 2012 !). So it should be more readable and maintainable by anyone. I "burst" the version helpers in dedicated source for each supported version of the backend: 75 = 0.26+ , 76 = 0.27+ , 85 = 0.28+

[janbar]

@philled , currently addon apply template regarding category since 2012 using my fork of cmyth and always now even using exclusively the API to manage record schedules.
About updating template with kodi: I haven't any plan to update the template with Kodi. Today the addon load all templates in its area and uses them to default rules attributes, also it is possible to design a screen to update them. Unfortunately it is not a priority because today i am alone to maintain the code.

[metaron]

I apologise for jumping in here and I hope this doesn't hijack/upset the thread or the contributors. I have just been pointed here from a response on the MythTV mailing list debating the merits of Mythfrontend vs Kodi. I see that there is a lot of work going on to beef up the Mythbackend recording options through Kodi and I would like to ask a question. Does this include (or are there plans for) support for Mythtv "recording templates"?

A recording template lets you set things like early start and late finish padding, which recording group to store the recording in, whether to do commercial skipping, whether to look up metadata etc. The good thing about them is that you have have more than one - so for example I have a default one for most things, and an additional one for movies which has different settings and the listing category matches the template so it gets automatically applied to programs listed as movies.

I was thinking something similar myself when I asked Ksooo to add 'Recording Groups' to the API.
The way pvr.mythtv code is structured, it wouldn't be impossible to substitute 'Recording Groups' (what I use) for 'Recording Templates' (which I was wondering about, but never felt the urge/need to experiment with).
Unfortunately, Kodi core controls the name of the feature at present so it would still be called 'Recording Group' in the UI.

Personally I was thinking Ideally it would be a 'configurable' option in pvr.mythtv. To use this dropdown list as either 'Recording Group' - which just groups things into folders, or 'Recording Template' which could do this and much more as well. Even better if the API allows the addon to rename the feature, but I didn't want to push Ksooo to far .

Janbar has a good point though. It isn't trivial and there are questions like 'what should the defaults be' to be answered... Once this first bit is working and stabilized, you never know, 'someone' might find the time to submit a pull request to janbar...

[metaron]

@MikeB2013, @metaron, I pushed my proposal 20150625 !

I fixed a lot of your requirements. I let you discover. @metaron for instance not to many change for timer type, but i updated names and probably i will add "Record series": there i need extra info to setup filter correctly because i don't want if i need to use filter ThisEpisode or something else. Do you know about ?

EDIT: ah I missed, I cleaned all my old code in ScheduleManager (dating from 2012 !). So it should be more readable and maintainable by anyone. I "burst" the version helpers in dedicated source for each supported version of the backend: 75 = 0.26+ , 76 = 0.27+ , 85 = 0.28+

@janbar Excellent! MythSheduleManager was far too large a file to work with and the new spilt ones make things much clearer.

I'm afraid I had too much time on my hands and got a bit carried away. (see https://github.com/metaron-uk/pvr.mythtv.git seriesfixes branch). I also wanted to try 'my' names .

I've taken a slightly different approach which splits out 'manual', 'epg based' and 'search' rules, which I think simplifies both the UI and the underlying code. You may like / not like it, but I'd be interested in what you think.

Unfortunately our branches have diverged again, but if you want I'd be happy to re-base and send you a pull request.

[janbar]

1. Record All Showings on Any Channel has problems. This Channel filter is being set, and timer display showing a specific channel (instead of any). I use Any Channel frequently (in UK we have lots of +1 hour channels)

2. Remove ? in Recording Group, should default to "Default"

3. Add "Record new and expire old" together with "number of recordings to keep" (I use this quite often for certain news programs, usually keeping 2)

4. Add subtitle/Series/Episode to title.

5. Typo in various screens "shownings" should be "showings"

1: fixed
2: fixed
3: TODO : requires a new setting for "number of recordings to keep"
4: fixed
5: fixed

Also epgId is filled now for active upcoming, and icons are display in the guide.

[janbar]

@janbar Excellent! MythSheduleManager was far too large a file to work with and the new spilt ones make things much clearer.

I'm afraid I had too much time on my hands and got a bit carried away. (see https://github.com/metaron-uk/pvr.mythtv.git seriesfixes branch). I also wanted to try 'my' names .

I've taken a slightly different approach which splits out 'manual', 'epg based' and 'search' rules, which I think simplifies both the UI and the underlying code. You may like / not like it, but I'd be interested in what you think.

Unfortunately our branches have diverged again, but if you want I'd be happy to re-base and send you a pull request.

Yes i would happy too to see your approach. Now i won't change any more the structure of sources and you can rebase safely.