[metaron]

@janbar - I have some more ideas to push in your direction based on my 'work in progress'
(https://github.com/metaron-uk/pvr.mythtv...reducedEPG)

You seem to have several active branches (3.0.0, doityourself, series_recordings)

Which branch would be most useful as the rebase for a pull request?

[janbar]

@metaron, so now kodi feature seems to be stable and i merged series_recording in development branch "doityourself" after long review and tests with valgrind and others tools i use. The last commit from today includes update to make all new things thread safe. This last could show big stuff but in fact nothing change rule handling. I added a mutex and I removed static storage used for testing.
Please you can create PR rebased on doityourself. Thanks

[metaron]

@janbar - thanks, will do.
I'd be interested in your opinion about the ideas I posted here as most of them would require further API changes.

[metaron]

@janbar: Excellent to see your thread safety changes :-)

I want to make changes to pvr.mythtv series recording:

1. Only associate EPG tags with upcomings (not rules)
   
2. Use EPG tags only when creating a new rule, not on edit.
   
3. Update rule using old rule as template (in NewFromTimer - for more flexibility)
   
4. Support 'AnyTime' for daily and weekly rules (API 3.0.0)
   
5. Provide EpisodeName / Season / Episode / Year separately from Title (API 3.0.0)
   
6. Remove 'EPG Search' field from all/one/daily/weekly rules (imo not needed here, search based on 'Name' field where necessary)
   
7. Separate 'Max Recordings' from 'Lifetime' (API 3.0.0)
   
8. Support 'recording templates' ('defaults' for creating each rule type)
   
9. Remove 'Record series' (imo not needed. Use 'Record All')
   

I have a prototype for 1-6 (and part of 7) at https://github.com/metaron-uk/pvr.mythtv...s/API3.0.0 which you could test against API 3.0.0 if you want.

This uses old pvr.mythtv code, so I need to rebase (and make fixes).

Is it OK to use kodi-pvr/pvr.mythtv (no force pushes)?

Thanks.

[MikeB2013]

@janbar: Excellent to see your thread safety changes :-)

I want to make changes to pvr.mythtv series recording:

1. Only associate EPG tags with upcomings (not rules)
   
2. Use EPG tags only when creating a new rule, not on edit.
   
3. Update rule using old rule as template (in NewFromTimer - for more flexibility)
   
4. Support 'AnyTime' for daily and weekly rules (API 3.0.0)
   
5. Provide EpisodeName / Season / Episode / Year separately from Title (API 3.0.0)
   
6. Remove 'EPG Search' field from all/one/daily/weekly rules (imo not needed here, search based on 'Name' field where necessary)
   
7. Separate 'Max Recordings' from 'Lifetime' (API 3.0.0)
   
8. Support 'recording templates' ('defaults' for creating each rule type)
   
9. Remove 'Record series' (imo not needed. Use 'Record All')
   

I have a prototype for 1-6 (and part of 7) at https://github.com/metaron-uk/pvr.mythtv...s/API3.0.0 which you could test against API 3.0.0 if you want.

This uses old pvr.mythtv code, so I need to rebase (and make fixes).

Is it OK to use kodi-pvr/pvr.mythtv (no force pushes)?

Thanks.

@metaron

Looks ok, but what are the effects on recording rules/timers previously created outside of kodi e.g. mythtvfrontend/mythweb as far as editing within kodi is concerned ?

Removing Record Series may generate complaints as multiple series are broadcast on the same day, sometimes on the same channel, sometimes different channels. Personally, I don't have a problem with removing Record Series as I mostly use Record All with or without This Channel filter. From my travels to the USA there are lots of reruns!

Mike

[janbar]

@metaron

Thanks for your work. Like said Mike "Record series" is a request from US users and it contains special filter. Without it any rule using this filter will be unhandled. Also it is one of rule was implemented using hook from guide screen. Therefore we won't remove it.

1. : why is it intented ?

2. : why is it intented ? also all rule using search NoSearch REQUIRES a valid EPG to work. I want to be able to edit my rules with this type of search without break it.

3. : AGREE: Please add a new member "UpdateFromTimer()" instead update NewFromTimer and make a PR including only this change.

4. : wait for merge of api

5. : wait for merge of api. But inclusion of "subtiltle" (episodeName ?) was requested by users. It will not be removed while this field is not displayed in guide timeline or any others place where it was requested.

6. : That could make unreadable code by making special cases (using title as search field for few types). Also remember the addon core (class PVRClientMythTV) SHOULD NOT handle timer type. Timer type is handled by schedule manager and only it. You could make a PR including only this change to check impact and clarity of code.

7. : What is the benefits ? Timer setting is already full of fields. For me it add more complexity and no improvement. As aside i think again to revert the deletion of hooks which are really usable and they simplified the life of user.

8. : what do you mean by "recording templates" ? what is it intented ?

9. : It will not be removed

For beginning we can check point 3 and see what it will allowing to do or open some closed case.

EDIT: Please use my branch "doityourself" as base. "kodi-pvr/pvr.mythtv" is not the repository for development.

Don't worry if i seems to be like cerberus . I just want to keep all features available (requested by users/contributors or not) with best quality (no bug as possible!).

[MikeB2013]

@metaron @janbar

For 8 Recording templates.
I think I mentioned this sometime ago.

mythtv has a default recording template, but Users can create additional templates e.g for movies, sports etc.

These additional recording templates could be vastly different from the default template e.g. sports may well have recording end time padding of an hour or more, as such events often overrun the scheduled program times.


Mike

[metaron]

@janbar - many thanks for your detailed reply, it was just what I hoped for . doityourself it is. If you can avoid force pushes, it will make my life much easier!
@MikeB2013, thanks for your comments.

@janbar I will try and answer your questions. If I am unclear, please say:

1. I want to change 'channel' for an existing rule without affecting recorded show.
Rule EPG tag code matches by channel/time, then over-rides Title. Not good for +1/+24 channels.

2. ST_NoSearch rules don't need an EPG entry. RT_DailyRecord, RT_WeeklyRecord, RT_OneRecord and RT_AllRecord all match using 'Title'.
Duplicate checking uses ProgramID, Title, Subtitle and Description.
'This Series' filter uses SeriesID, not an EPG entry. ( See https://www.mythtv.org/wiki/Recordfilter_table ).
An EPG entry is needed to populate ProgramID and SeriesID (PVR_TIMER_REQURIES_EPG_TAG_ON_CREATE), but is then not necessary. I have alternative logic for NewFromTimer (UpdateFromTimer) for all existing timer types which works well without needing an EPG TAG on modify.

3. OK. Like the approach, will do.
4. Yes.
5. Yes. All missing places where 'subtitle' needs to be displayed are included in the API3.0.0 commit.

6. With my working code only Weekly and Daily rules use ST_TitleSearch (when 'AnyTime' is set). This uses 'title'. Search Keyword and Search People use ST_XXXXSearch but using 'strEpgSearchString'. I don't think this makes for 'unreadable' code, but yes, a separate PR is a very good idea.

7. Benefits: a) makes the UI more like Mythfrontend / mythweb, b) uses the Kodi API 'properly' (i.a.w. doxy). Not major benefits I agree and I haven't fully tested this yet, so maybe I will change my mind when I finish implementing a prototype.

8. @MikeB2013 is right, I mean the (optional) user defined recording templates. I haven't prototyped this yet, so I am not sure exactly how it should work. Still at the very least the user should be able to select which recording template to use in the addon configure dialog: addon provided, Mythtv "Default" or Mythtv "<select from list>".

9. I don't want to waste time PRing changes no one else wants! If Record Series is essential, let's keep it.

@MikeB2013 - Managing rules created/modified outside kodi is a key part of my philosophy:

• Simple timer types, similar to those available in Mythweb.
  
• Create new rules using (in priority order) a) timer settings dialog values, b) EPG TAG data, c) the chosen rule template.
  
• When editing a rule, only change what can be edited on the timer settings dialog (changes 1/2/3). Anything which can't be displayed won't be changed by Kodi.
  
• One-One mapping: backend rule <-> timer type.
  
• Only use 'unhandled' for rule types which Kodi can't edit properly (PowerSearch)
  

I would really like to be able to provide a 'summary' of all the settings a rule has which don't display in the timer settings dialog. Maybe 'strSummary' could be used for this, but it would require another Kodi PVR core change. Something for the future IMHO.

[MikeB2013]

@metaron

For 8 Recording templates, yes, just the ability to select which recording template to use if more that default is defined in mythbackend is fine by me. I seem to recall that an earlier iteration of pvr.mythtv series recording code did have this capability.

Yes, it would be nice to be able to create a new named recording template within kodi/pvr.mythtv, but I would put this in a "do later list"


Mike

[janbar]

Ah yes i see what you mean: "template rules". They are already managed as mythfrontend does. Also since 0.28 they are applied after API call AddRecordSchedule. So what do you need more ?

EDIT: to tell little more: template rules are applied comparing category of program as implemented in backend too. This feature REQUIRES EPG info else it is not usable. cf => +1 why i want relate EPG info for some rules.

[metaron]

Removing Record Series may generate complaints as multiple series are broadcast on the same day, sometimes on the same channel, sometimes different channels. Personally, I don't have a problem with removing Record Series as I mostly use Record All with or without This Channel filter. From my travels to the USA there are lots of reruns!

'This Series' filter uses SeriesID, not an EPG entry. ( See https://www.mythtv.org/wiki/Recordfilter_table ).

In my guide data (UK Radio Times), SeriesID is the same for all episodes, no matter what season they are in.
If you're trying to avoid re-runs and have guide data like mine, FM_ThisSeries won't help. You'll need something more like FM_FirstShowing or FM_NewEpisode...

The only thing FM_ThisSeries is good for is if there are different series with the same Title on the same channel (or different channels if using "Any Channel"). This doesn't seem too likely a scenario to me, but according to http://www.gossamer-threads.com/lists/my...ers/520994 this is exactly what it is supposed to do.

Fine, if there are people in the US who really need this feature, keep it.

I do wonder if it might be better handled by a template for 'Record All' / 'Record One' or associated to a Recording Group, (change 8) but this can wait for another day.

[janbar]

One thing more to tell: MythWeb has its own philosophy about creating rules which is different than mythfrontend and our addon has its own too. For sample mythweb proposes by default to create RecordAll or RecordOne. But these rules have a high cost for the scheduler. It is better to use thin rules or adding filter as we do in the addon.

[metaron]

Ah yes i see what you mean: "template rules". They are already managed as mythfrontend does. Also since 0.28 they are applied after API call AddRecordSchedule. So what do you need more ?

EDIT: to tell little more: template rules are applied comparing category of program as implemented in backend too. This feature REQUIRES EPG info else it is not usable. cf => +1 why i want relate EPG info for some rules.

So 0.28 does something clever with categories to use different templates: makes sense.
As templates are only applied on create, I don't see a problem with my proposals: EPG will still be associated with 'AddRecordingRule', just not 'UpdateRecordingRule'.

For information: DVR services API always creates a rule using the 'Default' template for any settings not provided via the AddRecordSchedule method (https://github.com/MythTV/mythtv/blob/e3...r.cpp#L803 ).
pvr.mythtv currently implements templates by applying them to the rule internally before calling AddRecordSchedule then sending all the parameters...

[metaron]

One thing more to tell: MythWeb has its own philosophy about creating rules which is different than mythfrontend and our addon has its own too. For sample mythweb proposes by default to create RecordAll or RecordOne. But these rules have a high cost for the scheduler. It is better to use thin rules or adding filter as we do in the addon.

Since the scheduler improvements in 0.26 I don't see these 'difficult' rules as a problem anymore.

I have loads of 'Record All' and 'Record One' rules defined (63 channels, 132 rules) and my backend still re-schedules in a second or two. OK it's running on a core 2, but my pi2 didn't seem to struggle either, admittedly without all the 'legacy' rules...

Edit: My proposals still use 'FM_ThisChannel' by default (as Kodi core defaults to the selected channel, not 'Any Channel'), so that should keep rules 'thin' unless the user needs 'AnyChannel'.

[metaron]

@janbar - As requested 'part 3 only' pull request submitted: https://github.com/janbar/pvr.mythtv/pull/8

To really work properly I also need to do parts 1, 2, 6 and part of 4 (without the API 3.0.0 change).