timer recordings 1 show off
#16
nah mythweb is all ok, though more fiddly Smile advanced settings, having to modify the pre and post values every time. tick boxes etc etc..
Must hack that code and modify the defaults.. though I got lost reading through it last time.
Reply
#17
ok some semi success..
Managed to capture a recording failing this tonight, go figure Smile
Brock on channel 10.
And the debug info from within BreakBroadcastID and returned looks ok.
Program starts at 9pm..
Sooo its after that it appears.. more trace to be added..
20:09:14 T:13428 DEBUG: AddOnLog: MythTV PVR Client: PVRClientMythTV::AddTimer: title: Brock, start: 1476104400, end: 1476111600, chanID: 1010
20:09:14 T:13428 DEBUG: AddOnLog: MythTV PVR Client: PVRClientMythTV::AddTimer: Submitting new timer
20:09:14 T:13428 DEBUG: AddOnLog: MythTV PVR Client: PVRClientMythTV:TongueVRtoTimerEntry: EPG=1 CHAN=1 TS=1 SEARCH=1
20:09:14 T:13428 DEBUG: AddOnLog: MythTV PVR Client: MythEPGInfo::BreakBroadcastID: now=2016-10-10T20:09:14 ptc=25740 ntc=25689 distance=51 epgtm.tm_min=0 epgtm.tm_sec=59 epgtm=2016-10-10T21:00:59
20:09:14 T:13428 DEBUG: AddOnLog: MythTV PVR Client: PVRClientMythTV:TongueVRtoTimerEntry: broadcastid=1686897650 chanid=1010 localtime=2016-10-10T21:00:59
20:09:14 T:13428 DEBUG: AddOnLog: MythTV PVR Client: PVRClientMythTV:TongueVRtoTimerEntry: original chanid is overridden with id 1010
20:09:15 T:13428 DEBUG: AddOnLog: MythTV PVR Client: PVRClientMythTV:TongueVRtoTimerEntry: Found EPG program: 1010 0 Australian Survivor
20:09:15 T:13428 DEBUG: AddOnLog: MythTV PVR Client: 76::MythScheduleHelper76::NewFromTimer
20:09:15 T:13428 INFO: AddOnLog: MythTV PVR Client: 75::MythScheduleHelper75::NewFromTemplate: Overriding the rule with template 1 'Default (Template)'
20:09:15 T:3040 DEBUG: CPVRTimers - PVR::CPVRTimers::Update - updating timers
Reply
#18
Ah I just noticed something.
The client is saying it should record at 9:00pm, but if I go and look at the server it's actually showing the program is starting at 9:03pm...

I got this on another computer with the same dll, and then went and looked at the server itself via mythweb.
19:58:22 T:12640 DEBUG: AddOnLog: MythTV PVR Client: PVRClientMythTV::AddTimer: title: Brock, start: 1476104582, end: 1476111145, chanID: 1010
19:58:22 T:12640 DEBUG: AddOnLog: MythTV PVR Client: PVRClientMythTV::AddTimer: Submitting new timer
19:58:22 T:12640 DEBUG: AddOnLog: MythTV PVR Client: PVRClientMythTV:TongueVRtoTimerEntry: EPG=1 CHAN=1 TS=1 SEARCH=1
19:58:22 T:12640 DEBUG: AddOnLog: MythTV PVR Client: MythEPGInfo::BreakBroadcastID: now=2016-10-10T19:58:22 ptc=25743 ntc=25678 distance=65 epgtm.tm_min=3 epgtm.tm_sec=59 epgtm=2016-10-10T21:03:59
19:58:22 T:12640 DEBUG: AddOnLog: MythTV PVR Client: PVRClientMythTV:TongueVRtoTimerEntry: broadcastid=1687094258 chanid=1010 localtime=2016-10-10T21:03:59
19:58:22 T:12640 DEBUG: AddOnLog: MythTV PVR Client: PVRClientMythTV:TongueVRtoTimerEntry: original chanid is overridden with id 1010
19:58:22 T:12640 DEBUG: AddOnLog: MythTV PVR Client: PVRClientMythTV:TongueVRtoTimerEntry: Found EPG program: 1010 0 Brock

So the later search is picking up something different from the local guide.. Is this a cacheing issue
Reply
#19
BTW the actual guide in Kodi is showing 9:00pm on the PC that set the wrong timer..
and 9:03 on the one that worked..
I went and told Kodi to delete the cache on the channel and the guide fixed itself on the bad one..
and would then record the correct channel. so maybe when mythtv switched to channel 10 to record the "wrong" program it updated??
and kodi didn't get that update as it was set to only update every 120 minutes..
And when I went and recorded it on the other laptop kodi got this new updated guide data..

Last thing I recorded on channel 10 would've been saturday night.. don't think I watched anything yesterday / today..
One way or another though I thought Kodi reloaded the guide data on restart?? I restarted it a couple of times before doing a manual clear..

Maybe channel 10 updated the guide between now and then... mythtv is set to use idle time/tuners to scan for guide I believe..

**** Actually scratch most of that, one part of kodi id's the program as Brock, the other gets the wrong but actually correct program for that time slot..
So I think this is a guide caching issue..
Reply
#20
Hi all, strange thing ...

I saw 2016-09-26T23:58:59 for the start time. It should be 2016-09-26T23:59:59. The root cause seems to be here. I am checking the code ...

@rtresidd , mmm no bug Wink

On ubuntu 64bit: now = 1474896081, chanid = 1009, start = 1474905540: broadcastId = 377422833 => 2016-09-26T17:59:59
On windows/cygwin: now = now = 1474896081, chanid = 1009, start = 1474905540: broadcastId = 377422833 => 2016-09-26T17:59:59

17:59 is my localtime for your show

@rtesidd, what was os/version to get 23:58 instead 23:59 ?
Reply
#21
What else, an other root could cause that when EPG guide has been updated in myth-backend and not refreshed by kodi. Programs could be shifted for few minutes. So the addon request the backend guide for specified time and then it retrieves the previous program because last EPG update of guide has shifted the program.

A quick fix to handle small shift, could be adding 5 minutes instead 59 secondes. But it is fully empirical !
Reply
#22
Yep I think my first calc was due to the the actual guide having an old stale program time, vs kodi.. hence the 1 minute error I observed.
I hadn't added in some debug code at that point to see what that function actually calculated and was relying on the later debug output which was generated by the search result
I stupidly overwrote that log about 5 minutes later..
Didn't realize at the time that the kodi guide could get out of sync with the mythtv up2date guide..
I'm not really sure how to handle the kodi guide update.. not like you want this continually polling..

5 minute thing:
Problem is there are lots of silly filler programs that are ~5 minutes long..
Maybe it'll reduce the problem a bit though.
I really wonder if they're doing this on purpose, I noticed when I went and viewed the guide on the Android TV for that same program it was at 9:02 so I had 3 different times depending on when the frontend updated its guide info.
Maybe stick the timer point for the search smack bang in the middle of a programs length and then we shouldn't hit silly little shifts of start times etc..?
Haven't looked at the search routine to see if thats viable..

Thanks
Reply
#23
(2016-10-10, 06:46)rtresidd Wrote: Metaron I can have a look, though I'm kind of stuck with Jarvis at the moment due to it being the actual release that I can get on my TV and tablet..

There's a jarvis branch here https://github.com/metaron-uk/pvr.mythtv/tree/jarvis

Although from the discussions above it looks very unlikely anything I did would fix this behaviour.

I do remember pvr.mythtv using 'localtime' for calculations when 'gmtime' seemed more sensible to me, and I remember that windows doesn't always have the same time approach in these functions as linux, but unless you were setting a timer while daylight saving time changed, I don't think that would make any difference at all.
Reply
#24
Is there a fix or workaround for this issue for folks looking to upgrade to Krypton? Using myth web or myth frontend to set timers defeats the purpose of having all this functionality straight in KODI user experience. The integration work that has been done so far is so incredible, it would be a real shame to have this bug in official release of Krypton.
Reply
#25
I've been using Krypton beta for a long time now including setting timers using kodi as a front end. I don't see this issue. Although as I said previously I am using a slightly modifed version of Janbar's code, I don't think anything I changed would affect this.
If there is still a problem it is probably to do with guide data as Janbar suggests, rather than a 'bug' in pvr.mythtv (although I am prepared to be corrected on this).

Possible Explanation
Duplicate channels happen for example if you get the same national channel via two different terrestrial transmitters (DVB-T) or via terrestrial and satelite (DVB-S). Guide data for the two channels is still captured and stored separately by mythfilldatabase.

To simplify the EPG listings you can set two or more channels to have the same channum/callsign/name fields so the mythbackend scheduler and EPG consider them 'equivalent'. This is the mythtv approved way to mark channels as '100% the same' and it will use guide data from one of them to decide what to record on any of the 'equivalent' channels.

Pvr.mythtv stores these channels in kodi as separate entities, but to avoid massive duplication of data and slowdown, only guide data for one of them.
I have noticed that on rare occasions when one of my video sources fails to update guide data properly (when I've messed up a config file), mythweb can show different guide data than kodi.
Assuming mythweb and mythbackend scheduler are using the same channel for guide data, this suggests pvr.mythtv may be picking 'the wrong one' to display in kodi.
Kodi only refreshes EPG data periodically (every 2 hours by default I think) so there may also be some lag between kodi and the backend. I haven't investigated enough to be sure if mythweb/kodi EPG lag is the culprit or kodi has picked the 'wrong' channel for EPG data.

If you are sourcing EPG data for these two channels from the same guide data which only seldom updates (e.g. schedules direct updated over night as I do) you shouldn't get a problem as it will be the same. If you have 'over the air' guide enabled as well / instead, guide data can differ slightly between DVB-T and DVB-S, and be updated at different times 'on the fly' e.g. as sports programmes slip... This could be where the problem starts...

Does any of this sound like it might explain the symptoms you are seeing?

PS: If you want to change any of the 'defaults' for a new recording, just edit the default recording rule using mythfrontend. Any new rules you set up via kodi will inherit this (as long as you have 'use template from backend' set).
Reply
#26
I am using Schedules Direct exclusively to pull my guide data.

Your input on duplicate channels may have some relation to the issue I am seeing. I have two tuner cards setup on my myth server. The first is OTA Hauppauge receiver setup to receive a handful of local digital broadcast channels. The second card I have is a CETON Infinitv with a cable card. There is some overlap on the local broadcast channels, and it so happens that with these channels I can seem to consistently get incorrect timers set. Channels that are completely unique as of my testing so far do not have this issue.

One additional note is that there are channels within my cable lineup that from guide / broadcast perspective appear to have different programming, but they have similar call sign letters KUHTDT3, KUHTDT2. In these instances I can also get the errors in timer setup. What I am unclear on is your suggestions on mythtv setup to eliminate some of these issues. Could you please provide a little more detail on that end.

Thanks for your insight on this. I feel like maybe I have finally found the common thread on my system. Although – I cannot get these incorrect timers to set on my systems running Jarvis which hits the same mythtv backend.
Reply
#27
Hi Metaron.
I don't think so, I'm using 3 Dual DVB-T Tuners all in the same group. So I don't have any duplicate info.
Like I said I think the issue is just a simple case of Kodi having it's own copy of the guide info that gets out of step with what the mythtv backend or mythtv.pvr plugin have.
I only saw these recording issues when there was a slight shift back in the start time of a program.
It is pretty hard to reliably duplicate unless you can manage to find a program that gets its timeslot shifted slightly.
Kodi seems to have it's own polling interface for the guide info, was set to 120mins by default I think on mine.. I've bought that back down to a lower number.
I'm still not sure why the correct guide info didn't get pulled in when I started Kodi though.. MythWeb was showing the correct time, and I'm sure mythtv is going and polling by itself at certain intervals..
I may have triggered an update in the Myth backend though when I switched to the channel in question, but this info didn't get "pushed" to the mythtv.pvr plugin.
I can't remember the exact order of thing and given it's random appearance it's hard to actually trigger!
Spose I could somehow hack a change to a guide time between 2 programs in the database and then see how things behave.
Perhaps the Backend had only scanned that morning and that is what got sent to Kodi when it started up.. a subsequent change to the channel updated the backend but not the plugin.. So when doing the record entry the plugin went looking for the program at a timeslot and picked the wrong one as it got an update when it did the search or does it query the backend directly at that point?
I'm not sure if the mythtv.pvr plugin actually always polls the backend when doing a search at the timeslot, or if it has it's own copy of the data?
There may need to be some way of noticing the difference between what Kodi has vs the plugin/backend and forcing an update perhaps..

Note I've also had instances where a complete program gets removed / replaced and you try and record it, but no timer gets added.
The only way to fix this is to flush Kodi's guide cache same as for small time shifts.

Theres a fair bit of code in there so I haven't wrapped my head around the guide part properly yet.
It's really great that this works as well as it does, this is just a strange corner case of somewhere being out of sync.

Cheers
Richard
Reply

Logout Mark Read Team Forum Stats Members Help
timer recordings 1 show off0