• 1
  • 2
  • 3(current)
  • 4
  • 5
  • 8
pvr.mythtv and series recordings
#31
@janbar
I was thinking that it might make the code simpler to maintain if MythScheduleHelper75::NewFromTimer and MythScheduleHelper76::NewFromTimer were merged.

If I understand correctly, 0.26 should be able to support all the rule types that 0.27 can.
In that case pvr.mythtv can just use the 'new' method to create timers for both '75' and 76'.

As long as MythScheduleHelper75::FillTimerEntry can cope with both the 'new' and 'old' rules and detect them correctly, users should be seamlessly migrated as they use the interface.

What do you think?
Reply
#32
@janbar
OK I've rebased my code (plus more fixes) to your current series_recordings branch and pushed it to https://github.com/metaron-uk/pvr.mythtv.git on branch newseriesfixes

Timer Types supported (Slightly re-ordered):
  • This Showing - was 'Record this'
  • Once (This title) - was 'Record one'
  • Series (Any time) - was 'Record all'
  • Weekly (This day and time) - was 'Record weekly'
  • Daily (This time) - was 'Record daily'
  • Text Search - new
plus the manual and upcoming types in your version which are unchanged.

The philosophy I've taken is:
  1. Minimize options for 'EPG' types
  2. Move text searches to the new Text Search type
  3. Assume @ksooo will add an API method to disable 'Any Channel' for fixed channel methods in the future
  4. Assume @ksooo will add an API method to control if a Type should appear in the 'Add Timer....' screen
  5. Assume @ksooo will add an API method to remove a redundant 'Any Time' radio button.

I've hidden 'rule' timers in the past (with m_showNotRecording condition commented out).
It still need some bugs squishing and some commits squashing, but I've submitted a pull request anyhow https://github.com/janbar/pvr.mythtv/pull/3 mainly so I can upload some screenshots Smile.
Time for bed!

Let me know what you think.
Reply
#33
(2015-06-26, 07:43)janbar Wrote:
(2015-06-24, 20:06)MikeB2013 Wrote: 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

Still problems with Any Channel.

Any channel recording rule created using mythfrontend shows in kodi timer main screen with a channel, instead of any.

This happens on both 0.28pre (DVB-S/S2 UK Freesat) and 0.27.5 (DVB-T UK Freeview), both are using eit for program data not xmltv

Debug log files are:

http://paste.ubuntu.com/11782352/
http://paste.ubuntu.com/11782357/

On my main mythtv 0.28pre system (DVB-S/S2 and DVB-T/T2) which does use xmltv Any channel does show in kodi main time screen for some but not all any channel recording rules.

Debug log here http://paste.ubuntu.com/11782391/

Mike
Reply
#34
@MikeB2013, thanks Mike. I found the root cause.

EDIT: should be fixed now. At least i hope, as i said to metaron the code is tricky !
Reply
#35
@janbar

1. "First showing" filter

Mythtv backends using ONLY eit (over the air program data) will not record anything for any timer when "First showing" filter is set.

This is due to program.first data field in mythconverg database not being set by eit by mythtv backend.

Mythfilldatabase sets the data, but does not normally run on mythtv systems using only eit.

Systems using a mixture of eit and xmltv will have the data populated for eit and xmltv channels by mythfilldatabase program when it runs (usually every 24 hours).

Both of my test systems use eit only (mythfilldatabase does not run)

In kodi "Record all new episodes (this channel)" timer, sets the "First showing" filter.

Not really sure on how to handle this, require users to ensure mythfilldatabase is setup to run on mythtv backend or something else?

2. "Any channel" timer display

Confirmed as fixed in your latest changes to your series-recordings branch on 27 June.
However trying to set a timer within kodi with Any channel still has problems "This channel" filter is being set, I will provide more information later

Mike
Reply
#36
While developing a new 'Text Search' Timer Type, it became apparent that that there is a conflict with this and the other Recording types, as most of them already include a freetext 'Title Search' function.

janbar correctly pointed out that there is no need to have the same feature available in two places, however it appears we currently have different opinions about how best to accomplish this.

Currently, if I understand the code correctly, these types use:
  1. EPG data first (channel/timeslot from EPG), ignoring the freetext search field any user Channel selection or start/end time via the Timer Settings GUI.
  2. If the EPG data can't be found (the rule was created via the 'Add Timer...' selection, or the addon can't find any matching EPG records in the current guide data to tie up with the rule), they fall back to a Title Search based on the freetext search field in the Timer Settings GUI.
  3. If the EPG search string is empty, they fall back to using the selected channel/start/end time populated using the 'Timer Settings' GUI.

This is a logical progression (EPG data is selected first when creating a recording, Search string appears near the top under Timer 'Title' and the Channel/Start/End time options are below that), but I don't think it is particularly intuitive. Also mythbackend will be sent different rule data for the same 'Timer Settings' dialog display depending on the state of the EPG at the time the user created or last modified the rule via Kodi Rolleyes.

While this worked well when there was no way to view or manage rules via Kodi (before PVR API 1.9.7) I think that now we can do much better.

The way forward?
Rather than provide the full 'mythfrontend' control, I believe Kodi ought to focus on covering the basics well.
'Unhandled' rule types should allow 'tweaks' only (e.g. Recording Group/Priority/Lifetime) which is what janbar's current development code does Smile.

As Janbar and I seem to have slightly different opinions, it seems a good idea to ask other users what they would like Kodi to do with mythtv recording rules (keep it clean please Wink ).

I'll set the ball rolling by describing my opinion:
Personally (in the UK using a combination of Radio Times XMLTV for primary channels and EIT for secondaries), I've never needed to use a Title Search, the 'series' filter or specify a start time when I set up a 'Record All' or 'Record One' rule via mythweb which is what 90% of my recordings are.
I just select an EPG entry, click 'Find and record one showing of this title', or 'Record at any time on any channel', and adjust the Recording Group. Then I press 'update record settings'. Occasionally I also change Autoexpire/number of recordings to keep/Record new and expire old'.
This is what I think the basic Kodi interface should provide. By default it should create a rule which looks exactly the same as a mythweb created rule in the backend database (unless there are really good reasons not to).

Very occasionally when I can't find the title I want to record in the mythweb EPG (it's not being shown in the next two weeks), or I want to record all films with a similar title (e.g. *Resident Evil*), or featuring a particular actor (*Angelia Jolie*), I use a separate Title or Keyword Search rule.

I don't do daily, or weekly recordings, but I can see that they might be useful for recording news or similar. My guess is a similar logical progression: Find EPG entry, select 'daily/weekly', adjust recording group and number of recordings to keep, then press 'save'.

For those recording sporting events without using the over-the air EPG grabber (which I assume will be updated by the broadcaster when the match goes into extra time): Use a 'Just This' recording rule with 'start earlier' and 'finish later', set a recording group, then press 'save'.

The other use case I can see is 'tweaking' rules. Say you are running out of disk space don't want the soaps in HD - change the rule from 'Any Channel' to a specific non-HD version (mythbackend automatically prefers HD channels). Mythweb can't do this easily, but while playing with the pvr.mythtv development code, it is possible, works well and I believe would be very useful.

Say your 'Any Channel' rule is recording re-runs of ancient episodes on 'Yesterday' as well as this year's new ones on BBC1 HD. You could specify 'BBC1 HD' or if you prefer the old ones 'Yesterday'.

Other than that, any options presented on the Kodi 'Timer Settings' window ought to do what the user expects; even if that means a rule won't record anything. The user can quickly review what the change will do by selecting 'save' then viewing the upcoming recordings for the rule.
If something is wrong, they can either over-ride a specific upcoming showing (as the current development code does), or better, go back to the Timer Settings dialog and tweak the duplicate match method, the start and end times, or select a specific channel.

I believe this approach gives the mythbackend scheduler maximum flexibility to do what it is good at while keeping the kodi interface relatively simple. If you want still more power use mythweb, or mythfrontend and accept you need something more expensive than an RPi as your frontend Wink

@janbar: could you describe the types of recordings you schedule at the moment and how? It might help me understand better where you're coming from.
Reply
#37
@janbar @metaron

My usage is similar to @metaron, my main system is 0.28pre using Atlas xmltv grabber (the RT grabber is deprecated) with some EIT for UK Freesat and Freeview both are SD/HD using TBS pcie tuners (6981 and 6280).

I agree with @metaron about use of separate Title/Keyword/People timers, with these in place, I don't see a need to provide EPG search timer.

The current implementation from the EPG has "Add timer", "Add Custom" timer" or "Client Actions" context options, which seems overkill, surely "Add timer" for simple single record of the highlighted EPG entry, and "Add Custom timer" which then allows user to select from whatever range of timer types that are available. Defaults for each time type would be same as mythfrontend/mythweb created, with some adjustments being possible. Also I would like to be able to select the template to be used (assuming more than the "Default" template exists on the mythbackend)

My real concern with any EPG/title/keyword/people search timers is that the User could input data (say % on its own) which effectively takes down the mythbackend. I did try this on one of my test systems, doing on a single channel, maybe not too bad, just slowed everything down for a while (only 7 days epg via eit - total only 15000 rows in program table, my main system has around 190000 rows in program table i.e. more than 10 times the number of rows of the test system). Any channel is another matter, mythbackend became pretty much unresponsive and I had to manually recover.

Kodi/pvr.mythtv will get the blame, even though putting in the same data in the mythfrontend or mythweb will result in the same thing - mythbackend effectively down (it might recover after a long time - I gave up waiting after 30 minutes). We need some protection on search type timers to limit the possible effects.

Mike
Reply
#38
(2015-06-30, 17:10)MikeB2013 Wrote: My real concern with any EPG/title/keyword/people search timers is that the User could input data (say % on its own) which effectively takes down the mythbackend.

I managed something similar with a search string of 'one' and keyword search while debugging. I agree wholeheartedly that some sort of protection would be good with something as powerful as a freetext search, but what?
Maybe >3 characters would suffice. It should prevent 'and', 'the', 'one' and other potential back-end killers.
Reply
#39
(2015-06-30, 19:34)metaron Wrote:
(2015-06-30, 17:10)MikeB2013 Wrote: My real concern with any EPG/title/keyword/people search timers is that the User could input data (say % on its own) which effectively takes down the mythbackend.

I managed something similar with a search string of 'one' and keyword search while debugging. I agree wholeheartedly that some sort of protection would be good with something as powerful as a freetext search, but what?
Maybe >3 characters would suffice. It should prevent 'and', 'the', 'one' and other potential back-end killers.

Another possible approach (without me understanding any of the code! or how difficult it would be to implement) would be to try the search without committing the timer and if it returned more than some limit , say 100, possible recordings to be made then do not set the timer on the mythbackend and give the User a suitable message on-screen (an entry in the log file would be needed as well). If such an approach is feasible the limit could be set in Advanced tab of pvr.mythtv addon.

Mike
Reply
#40
@janbar, @MikeB2013
I've implemented a solution for add 'Record new and expire old'. (The screenshot at https://github.com/janbar/pvr.mythtv/pull/5 says it all). Should work for all timer types which currently support 'Lifetime'

I'm particularly interested in opinions about the limited set of options I've chosen to present (to keep the UI simple) and the 'if you can't present it don't change it' approach for unlisted values of 'No. of recordings to keep'.
I chose:
  • 2 - as MikeB2013 said he used it,
  • 7 - a week's worth
  • 14 - two weeks' worth (and close to the '15' I had in my rules)

Also let me know if the logic is sound, particularly for 'Keep up to x recordings'. I know it works for "Keep x newest (expire old)" as it matches my working mythweb rules Smile
Reply
#41
@janbar
I'm not comfortable with the convoluted path the code takes to update an existing "PVR_TIMER" between Kodi Core and the mythbackend.

The process starts in PVRClientMythTV::UpdateTimer:
  • converts the PVR_TIMER into a MythTimerEntry using a set of rules (PVRtoTimerEntry)
  • converts the MythTimerEntry into a MythRecordingRule using a set of rules (NewFromTimer)
  • selectively copies aspects of that new MythRecordingRule over the top of the existing one (UpdateRecordingRule)
  • and finally sends the modified rule to the backend (m_control->UpdateRecordSchedule)

The Problem
Several times I've wanted to just change part of one of the features based on the PVR_TIMER_TYPE, but by the time I get to UpdateRecordingRule, I don't have access to the timer type anymore and have had to invent 'creative' work-arounds, or just give up.

I believe the 'if you don't understand it, don't change it', approach to editing an existing rule is best (mythtv rules are very powerful and may not have been set up using a Kodi frontend). Unfortunately I don't have enough control to accomplish this at the moment because all knowledge of what was actually changed is stripped out by 'PVRtoTimerEntry' and 'NewFromTimer'.

My proposed way forward
I'm going to have a go at writing an alternative path between PVRClientMythTV::UpdateTimer and m_control->UpdateRecordSchedule which implements the existing functionality for a restricted range of PVR_TIMER_TYPES.
As there are relatively few settings on the GUI which a user would want to change and therefore very few parts of a rule to modify, this might actually work.

I won't change any of the existing code, just write a replacement for:
"MythScheduleManager::MSM_ERROR ret = m_scheduleManager->UpdateTimer(entry);"
which uses a PVR_TIMER.

Ideally I would propose to keep the existing path to create a new timer (where full set-up is needed), but use the new 'slim' approach for editing an existing timer.

You've obviously got years of experience with Kodi development (and API changes) so if you think this would be a waste of effort as it will probably get sunk by API version 1.9.7.1 in a month's time, please shout!
Reply
#42
(2015-06-30, 23:28)metaron Wrote: Also let me know if the logic is sound, particularly for 'Keep up to x recordings'.
Seems to work as expected with 'Record All' and 'keep 2 recordings'.
With two episodes of 'Teleshopping' recorded (more than enough to my mind!), Mythweb reports all future matching occurrences as 'Too Many' in the upcoming list.
Delete one of the recordings and mythbackend schedules another one.

It is interesting to note that 'Too Many' (status 5) upcoming recordings show as 'disabled' in kodi even though 'show not recording' is "off". Maybe this should be added to the status list which doesn't display unless 'show not recording' is on.
Reply
#43
@janbar

pvr.mythtv series_recording will not build on Windows 7 or 8.1

Code:
Error    6    error C3861: 'difftime': identifier not found    C:\Users\Mike\src\pvr.mythtv\src\cppmyth\MythEPGInfo.cpp    126    1    pvr.mythtv
Error    7    error C3861: 'time': identifier not found    C:\Users\Mike\src\pvr.mythtv\src\cppmyth\MythEPGInfo.cpp    136    1    pvr.mythtv
Error    8    error C3861: 'difftime': identifier not found    C:\Users\Mike\src\pvr.mythtv\src\cppmyth\MythEPGInfo.cpp    137    1    pvr.mythtv
Error    9    error C3861: 'localtime_r': identifier not found    C:\Users\Mike\src\pvr.mythtv\src\cppmyth\MythEPGInfo.cpp    143    1    pvr.mythtv
Error    10    error C3861: 'mktime': identifier not found    C:\Users\Mike\src\pvr.mythtv\src\cppmyth\MythEPGInfo.cpp    148    1    pvr.mythtv

Mike
Reply
#44
@janbar

For info series recording.

Running on my RPi2. I built from source using Openelec (master branch), replacing kodi with that from ksooo (pvr-series-recordings branch) and latest from your series_recording (built standalone). It works the same as on my Ubuntu system (15.04) . From my initial tests speed is ok on the RPi2 and I have yet to have any crashes.

Mike
Reply
#45
@janbar

Created a new timer from EPG, Record all, Any channel, timer created but for a specific channel (the one in the EPG entry ).

Debug log http://paste.ubuntu.com/11810610/

Mike
Reply
  • 1
  • 2
  • 3(current)
  • 4
  • 5
  • 8

Logout Mark Read Team Forum Stats Members Help
pvr.mythtv and series recordings1