Kodi Community Forum

Open it to get users feedback about this new feature scheduled for J****. The refactoring of the addon pvr.mythtv is near closed and i would like to get contributors feedback.
You can download sources of development branch supports this feature from https://github.com/janbar/pvr.mythtv/tre...recordings. The procedure to compile it doesn't change, but you have to compile kodi yourself including the PR 7079 (PR) , at least until not merged.

Some screenshots: https://canneasucre.org/owncloud/index.p...rwOJZmOxnM

@metaron , please have you try it and then what is your feedback ?

Will do :-).
...
Edit @ 22:25 OK I have it compiled and installed and it hasn't complained at my extensive list of timers.
Nice work!

More detailed feedback to tomorrow.

Wow!! How to present enough flexibility without causing confusion...

(2015-06-20, 20:49)VictorG Wrote: [ -> ]I think all this is too much complicated and might make things worse.

Approach
I believe we ought to support just options typical end users are likely to want to adjust using a remote control.
Anything needing a keyboard or extensive menus (i.e. mythfrontend/mythweb) just needs to be recognizeable and tweakable.

Some of these comments will be aimed @ksooo, some @janbar, some @metaron and some @ other users on this forum. Sorry if it's not 100% clear who at the moment...

Comments on Recording Types
Currently implemented types and my understanding of their purpose:

• Manual / Record this shownings - "Just what I asked for"
  
• Record one showning - (Films?)
  
• Record every week - (Sunday's weekly weather forcast for the week?)
  
• Record every day - (The 6 o'clock news?).
  
• Record all shownings - (Box Sets and Soaps)
  
• Unhandled rule (Power searches etc...)
  
• Record (Upcoming Recording)
  
• Override (Overridden Upcoming Recording)
  

Proposed Types & Names:

• Manual - (Just this) Fixed: "Record only this showing", Channel, Time, Date
  
• One - (One of these) Fixed: "Find and record one showing of this title", Default: Any channel
  
• Series - (All of these) Fixed: "Record at any time on any channel", Default: Any channel
  
• Daily - (At this time) Fixed: Filters: This Time/This channel, Default: Channel, Time
  
• Weekly - (On this day) Fixed: Filters: This Day and time/This channel, Default: Channel, Time, Day
  
• Advanced - (Like this) Default: "Title Search", string="Title", Any channel.
  
  
• Unhandled - (Power Search and other mythtv extreme cleverness...)
  
  
• Upcoming - (Upcoming Recordings as chosen by the mythbackend scheduler)
  
• Override - (Manual intervention of mythbackend scheduler choices)
  

Comments on each type
Manual
Seems to work as expected. Minor typo in timer type name, but I'm suggesting to re-name it anyhow.

One
Remove 'Search Guide For' entry
Make default 'Any Channel' with 'This Channel' filter not set. Otherwise show channel and set the filter.
Default duplicate matching to: "Subtitle then Description"
Don't show 'Any Time'/'Start Time'/'End Time' options. (You would use a 'Manual' timer for this)

Series
Remove 'Search Guide For' entry
Make default 'Any Channel' with 'This Channel' filter not set. Otherwise show channel and set the filter.
Default duplicate matching to: "Subtitle then Description"
Don't show 'Any Time'/'Start Time'/'End Time' options. (You would use a 'Daily/Weekly' timer for this)

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.

Weekly
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.

Advanced
It should be possible to implement 'Title Search' and 'Keyword Search' (using 'full string' search radio button).
Default should be 'Title Search' using the selected item 'Title' with the option to change to a 'Keyword' search.
I propose Power and People searches be displayed read only as 'Unhandled'.

Unhandled
Allow "Priority", "Lifetime", and "Recording Group" to be changed.
Continue to display Duplicate Match but keep uneditable as this might affect the validity of the rule.
Possibly hide some of the fields for clarity: Start/End/Anytime/Padding?

Upcoming
'Upcoming Recordings' associated with an 'Unhandled rule' should still be over-rideable (already works in 1.12.21 for power search).

Override
Currently only shows as 'Enabled'. Should show as 'Disabled' when the over-ride prevents a recording.

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;

Manual Timer Display - One for Ksooo I think...
When sorting 'By Date' manual recordings always appear at the bottom of the list. This is confusing when sorting in descending order with expired timers (i.e. those that haven't done anything for a while), or when sorting by Name.

Showing 'Upcoming recordings' only - One for Ksooo I think...
I find myself missing the simiplicity of what will record next on what channel (like the 1.12.21 client now does in Helix!). Might it be possible to switch between 'Rules' - the new behaviour and 'Upcoming' in the View: setting on the sideblade? Maybe an 'edit master timer' button can be added to the timer settings screen for 'subordinate' timer types. This should make day to day 'will my soap record tomorrow' checks simpler.

Title
When viewing subordinate 'Upcoming Recordings' for each repeating timer, the Title should show Season/Episode and Subititle information if available. 'Title' will always be the same and is shown in the path at the top of the screen anyhow. Not sure if this comment applies to the PVR client, the PVR core or the Skin (or all of the above!)...

Other Comments
Duplicate Matching
Mythtv uses 'Programid' extensively for duplicate matching without making this clear via the UI. This breaks when the listings provider thinks that all episodes of columbo shown during daytime television are effectively the same and assigns the same program ID. It also breaks when you use two listings providers (e.g. over the air for some channels and xmltv for others) as they tend to have different Programids.
I think we can do better and propose the following:

• Off (record everything)
  
• ID(EPG) fallback subtitle
  
• ID(EPG) fallback description
  
• ID(EPG) fallback subtitle & description
  
• ID(EPG) fallback subtitle, fallback description
  

Recording Group
"Default" should be the default. No need for "?". All backends should have a "Default" recording group already.

Lifetime
One of the features I use quite a bit is 'record new and expire old' with a number of recordings.
Currently 'Recordings never expire' and 'Allow recordings to expire' are implemented.
Could 'Keep last x' be added? (Maybe Last 5, Last 10, Last 20).
Not sure how an arbitrary value could be displayed if you chose something else via mythweb/mythfrontend, but I'm sure a compromise is possible, particularly as no one is likely to use values larger than '100'.

Conclusions
There's plenty to think about here. I'm happy to help debug/implement some of these features if necessary.
@janbar let me know if you would welcome assistance with something in particular.

Otherwise, I'll get back to trying to 'productionize' my season/Episode ttvdb scraper integration and 'recorded watched' with 0.27 patches while I wait for the comments to flood in.

(2015-06-22, 17:54)metaron Wrote: [ -> ]Wow!! How to present enough flexibility without causing confusion...

(2015-06-20, 20:49)VictorG Wrote: [ -> ]I think all this is too much complicated and might make things worse.

...

Comments on Timers screen

...

Title
When viewing subordinate 'Upcoming Recordings' for each repeating timer, the Title should show Season/Episode and Subititle information if available. 'Title' will always be the same and is shown in the path at the top of the screen anyhow. Not sure if this comment applies to the PVR client, the PVR core or the Skin (or all of the above!)...

I had the same feeling and that's why I implemented this last Saturday. :-) Repull 7079, please.

Will put the other things for the timer window on my post-7079 list.

@ksooo - I'm up to date with your pvr-series-recordings branch of kodi.

MyPVRTimers.xml:

I guess @janbar's code isn't populating subtitle for these timer types yet. I know subtitle was 'squeezed' into the title field before. The current pvr.mythtv version (helix/gotham) doesn't do series/episode for recordings, so it's unlikely to be providing it for timers yet. It may also be the data on my backend of course. I'll take a look.

I see @ronie had this merged https://github.com/xbmc/xbmc/commit/9b86...021f5863f6 . In this it mentions $INFO[ListItem.Season, • $LOCALIZE[20373] ]$INFO[ListItem.Episode, • $LOCALIZE[20359] as well as $INFO[ListItem.EpisodeName, (,)].

If Season/Episode numbers are to be displayed as well, should it not look more like this?:

wow, interresting review. I will add some comments for each later. Before just few things: We have to keep in mind that feature has to be compliant with more than one backend and the workflow to create a timer is the same for all: Based on EPG or MANUAL. Also we need to translate the backend rule types to user view through the kodi interface and vice versa with the smallest possible gap: Everything is not reasonably feasible.
Regarding pvr.mythtv , i continue to support 3 versions of the backend (0.26, 0.27, 0.28) and set of timer type will be suitable for each version, at least for 0.26 and others (while 0.28-pre and 0.27 have same behavior).
So now i think the best way is to try to implement, one by one, timer type as you describe. Also regarding some translations, i would prefer keep same as mythtv.

@janbar No problem. It's only my opinion after all and I'm just one of many people using your addon. That's quite a task you have there supporting three Kodi builds and three mythtv builds.

I can see your point about keeping terminology (particularly for 'match duplicates') the same as mythtv and I tend to agree with you. It may be potentially misleading in my opinion, but at least it's consistent with the backend.

Regarding the 'Advanced' search option, I see this as a future enhancement. It's not something I would use myself much (although I do set up Title searches via mythweb), but as the API supports it and Mythtv can do it, it seemed a good idea.
@nickr you said previously you set up quite a lot of power searches. Do you think Title/Keyword searches via kodi would be useful, or will mythweb still win when a keyboard is required?

All the other timer options are already there with different names. If you prefer to keep the existing names for consistency with the gotham, helix and isengard versions I can live with that, although I do like my names better

For 'One' and 'Series' (my names), personally I prefer 'Any Channel' rather than 'Current Channel' by default, which is different from the current philosophy. The mythtv scheduler prefers HD content/earlier showings so I let it decide if to record something from ITV1 HD/ITV1/ITV1+1 or later on another channel when it shows a re-run. If I force a rule to ITV1 HD and it can't record then because of a conflict, I could miss a show altogether.

@ksooo @janbar

I have just tried ksooo build with pvr.mythtv addon (series_recording branch) against my mythtv test server (0.28pre with TBS 6981 dual tuner, UK Freesat). Series recording is looking good.

If there is any testing I can assist with please let me know.

Mike

(2015-06-22, 17:54)metaron Wrote: [ -> ]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;

Seems you are an expert on mythtv database. I didn't know that or i missed in my dev . I just added the missing fields in cppmyth lib and i have implemented your proposal. Thanks metaron.
Next i will try to implement timer type like you described, and give you a feedback soon.

@metaron, about "Manual" and "Record this": In fact i have to keep these two types, because feature requires at least one IS_MANUAL timer and one !IS_REPEATING && !IS_MANUAL. The first is use when pressing "Rec" button in live screen, the second is used when selecting option "Add timer" in epg screen.
Also the "Record this" is never displayed in select box because it is only epg-based and not manual. Finally in mythtv the rule will be SingleRecord (for all 0.26-0.28) with channel and timeslot for these two types. So the translation from myth rule to kodi rule will returns a collision: Manual or This ? Here as before i set the type "Record this". Conclusion you will never see in timer screen a rule type "Manual" but only "Record this".

Edit: i will change to translate rule singleRecord+chan+slot to "Manual" instead "Record this".
Edit: Finally Manual and This have different searchType. So i can translate to each addan type.

(2015-06-23, 12:05)MikeB2013 Wrote: [ -> ]@ksooo @janbar

I have just tried ksooo build with pvr.mythtv addon (series_recording branch) against my mythtv test server (0.28pre with TBS 6981 dual tuner, UK Freesat). Series recording is looking good.

If there is any testing I can assist with please let me know.

Mike

Hi Mike, yes there is. You could play with it: creating timer, updating/deleting/enabling/disabling etc... rules and records to check for abnormal behavior or crash... Let me know, Thanks.

EDIT: below the basic manual:

record (under repeating rule):
deleting record => create a don't record (record is no longer visible)
updating record => create an override (record is no longer visible)
disabling/deleting don't record => delete don't record (make original record visible)
disabling/deleting override => delete override (make original record visible)

rule repeating:
deleting rule => ask confirmation : No => returns, YES => delete rule
disabling rule => disable
enabling rule => enable
updating rule => update

rule not repeating (single):
depending of recording status (see recent fixes from metaron-uk), but basically same behavior as record.

@janbar
I found a small bug in the 'Record all showings' code if you set up an 'Any Channel' recording.

• If you use mythweb, chanid is set and 'this channel' filter is not set. - Works
  
• If you use pvr.mythtv chanid = 0, and 'this channel' filter is set. - Doesn't work
  
• I tried editing the rule setup by pvr.mythtv just to reset the 'this channel' filter, keeping chanid=0. - Doesn't work
  

The good news is that pvr.mythtv correctly identifies "chanid set and 'this channel' filter not set" as a 'Record all showings' so only the methods that set up or modify the rule need change.

Edit: Also, the mythweb set-up any channel recordings don't appear as 'Any Channel' recordings in kodi. They show as being recordings on the 'chanid' channel.

Edited snippet from my log file:

I had a quick look but I'm afraid I haven't quite found the culprit yet...

I've had some thoughts about displaying 'Repeating' or 'Find Once' timers in the EPG.

Currently if you set up a repeating rule, you will get at least two icons showing in the EPG, and potentially several 'invisible' ones:

1. At the EPG entry where you set up the timer - with a little 'repeating timer' icon (even if in the past)
   
2. At the times that the recording will actually occur (if that differs) - with a 'standard timer' icon (active subordinate timers)
   
3. If 'show not recording' is on in the addon, there will also be a 'no icon' timer record in the EPG for all alternative times in the future when a show could record if it had to (alternative channels and times/reruns of previously recorded shows)
   

It would be good if the EPG could display a 'will record at another time/on another channel' icon, or 'already recorded' variant of the repeating icon in these cases. (I've see a Youview box in the UK do something like this)
Probably it should be the duty of the addon/backend to identify these guide entries (pvr.mythtv can already do this for times in the future).

While having this extra information available is good for the EPG view, it isn't necessarily good for the Timers window. Certainly you would want to be able to filter it out. Currently pvr.mythtv does this 'at source' by not sending the pvr core these timers if 'show not recording' is off (the default), but it might be better to mark them 'optionally visible' and let pvr-core decide when and where to display them.
(You wouldn't want to hide all disabled timers as conflicts or manual over-rides would want to be visible so you could fix them)

Maybe this could go on the post 7079 Jxxxx ideas list if it isn't there already?

@opdencamp also mentioned wanting 'at some time in the future' to be able to see what was recorded from the guide and view it from there. I doesn't seem that far of a stretch from 'already recorded' icons to 'select here to watch'. The data for this is in the mythtv backend, but if it can be got at easily with the current API is another matter.
You can already relate 'historical' mythtv guide data to recording rules, but I'm not sure how 'current' that is or if this could be translated into a recorded file. Probably it's just whatever the schedule manager set last time it re-scheduled while that time was 'in the future'.

OK I'll stop now. Yes it would be cool, but the prospect of trying to implement, debug and support it is likely to bring on a nervous breakdown. The only reason I'm even considering it is the excellent stability of the current code!

@metaron, i can set the epgid for all future record, probably it will help to display better things in epg screen.