[pavlov70]

Hi,

I just got MythTV .28 on the backend up and running and am using the latest MythPVR from the Kodi repository. Everything works great except when I create a timer (either from search or from the guide), it creates the timer for the previous show on that channel.

For example, if I search for The Simpsons for 8pm and create a timer, the timer screen shows correctly with the title, etc. I click OK and it creates a timer. However, when I review the timer, it has created one for the show immediately prior on that channel. I have replicated this with the default Kodi skin and across multiple channels. The guide itself (from Schedules Direct) appears fine so I'm not exactly sure where to look next.

Any suggestions?

thanks
rob

[rpcameron]

This was a problem that frequently occurred (especially just after Daylight time changes). First things to double check is to ensure that both your client machine and your backends are all set to the same timezone. Checking that they are all on the same locale might help, too.

[pavlov70]

Thanks for the reply! I found an earlier thread also that mentioned the same thing. The times match up but I'll check to see if there's any DST setting in Ubuntu that I missed.

[pavlov70]

Just to follow up, I'm still experiencing the problem on my Win 10 machine after verifying time zone settings as per the Myth wiki. However, it works fine on Openelec. As I use Openelec on all my TV's, I'm not too concerned about getting it working on my Win10 box.

[rpcameron]

Since you're running 0.28, another option is to use the WebFrontend at http://$myth_backend_ip:6544

[spastic]

I too am having this same issue on a WIN10 machine running V17 beta2 and Mythbuntu 27. I have checked my myth server settings and they appear to all be set accordingly. It is intermittent and does not always happen but makes the search and scheduling function not usable. I do not see the issue on any of my openelec machines running v16. any help would be appreciated.

[rtresidd]

Getting this also.
Did some digging with debug log on.
Potentially something wrong in the BreakBroadcastID function??
eg this is from the debug dump: note I'm at +8 (perth) as can be seen in this log the title passed into AddTimer is "Undateable - New" hmm sad choice for example but it was a 30 minute program and It happened to be the one the issue trigerred on while I was doing wireshark captures etc.. anyway..
21:21:22 T:236 DEBUG: AddOnLog: MythTV PVR Client: PVRClientMythTV::AddTimer: title: Undateable - New, start: 1474905540, end: 1474906805, chanID: 1009 now: 1474896142
21:21:22 T:236 DEBUG: AddOnLog: MythTV PVR Client: PVRClientMythTV::AddTimer: Submitting new timer
21:21:22 T:236 DEBUG: AddOnLog: MythTV PVR Client: PVRClientMythTV:VRtoTimerEntry: EPG=1 CHAN=1 TS=1 SEARCH=0
21:21:22 T:236 DEBUG: AddOnLog: MythTV PVR Client: PVRClientMythTV:VRtoTimerEntry: broadcastid=377422833 chanid=1009 localtime=2016-09-26T23:58:59
21:21:22 T:236 DEBUG: AddOnLog: MythTV PVR Client: PVRClientMythTV:VRtoTimerEntry: original chanid is overridden with id 1009
21:21:22 T:236 DEBUG: AddOnLog: MythTV PVR Client: PVRClientMythTV:VRtoTimerEntry: Found EPG program: 1009 0 Doctor Doctor - Encore (Includes Sneak Peek - Hyde & Seek at 11:33 PM)

New Start of 1474905540 is: 2016-09-26T15:59:00+00:00 yep 11:59pm

So by my math code in BreakBroadcastID does this

now (from log)= 26/9/2016, 13:21:22 = 1474896082 /60 &0xFFFF = 5601 goes into ntc
broadcastid=377422833 >> 16 & 0xFFFF = 5759 goes into ptc
distance =ptc-ntc = 158 minutes

so attime = 1474905599 (now -(21*60) - 22 + (21+158)*60+59) [now rounded down to minute + distance(minutes) + 59(seconds)]
which is 26/9/2016, 15:59:59 utc 26/9/2016, 23:59:59 local
so why is the result thats spat out in the debug: broadcastid=377422833 chanid=1009 localtime= ****** 2016-09-26T23:58:59 ******
it's out by 1 minute early.. so we now end up picking the program before the one we want..

strange...
Maybe need to setup a build and get some more debug happening.. Kodi is current 16.1 release with 3.4.14 mythtv plugin

More digging required..
Richard

[rtresidd]

Hmm sigh
So after using the Jarvis branch of pvr.mythtv and building it all under vs c++ 2015 I can't get it to fail..
Note I had to manually copy the dll into the folder as I couldn't install the generated package file..
So I'm not sure what version is actually shipped with Jarvis..
The addon.xml seems to be consistent in the one that comes with Jarvis and the the one I've built locally..
But I can get the preinstalled version to consistently record the wrong program.. Not so with the one I generated.

The one I generated is a bit bigger even in release mode.. so perhaps some slightly different libs have been built in.
Maybe something to do with building via 2015 vs 2013??
But I have the same issue on the pre built pi version and android version, so maybe whoever is building these packages has a slightly different branch without updating the version number or something??

[spastic]

I have just reinstalled Version 17 Beta 3 by deleting previous install and reinstalling clean. Still seeing the same behavior.

Does anyone know if this behavior has been reported as a bug to the development team?

[metaron]

The 'PVRtoTimerEntry' and 'BreakBroadcastID' code talked about above is in the pvr.mythv client addon, rather than kodi core.

I did some digging about in this part of the code a while back (in the pre-Jarvis days) after seeing similar symptoms although I can't remember quite what the cause was.

Eventually I got so frustrated by how this worked (or didn't) and other aspects of the timer features in general that I wrote a revised version of 'PVRtoTimerEntry' and some of the surrounding functions and haven't had any problems like this since. I haven't touched 'BreakBroadcastID' so I would be surprised if this was the route cause. (I'm using Kodi 17 beta and 0.27.6 mythtv)

If anyone wants to review my changes you can find the version of the pvr.mythtv client I'm running at https://github.com/metaron-uk/pvr.mythtv/tree/krypton which is based on Janbar's https://github.com/janbar/pvr.mythtv/tree/doityourself

I'd be interested in feedback if anyone tries to use or improve on this code, but don't have much time to play with kodi or code in general at the moment, so please don't expect me to provide any support for it - sorry.

[nickr]

Sorry I am late to this show, but have you just transitioned in or out of daylight savings? If so, reboot your backend.

[rtresidd]

Nope we don't have daylight savings in Perth, and have confirmed this across numerous different platforms.
Definitely not on, and has never been on for either client or server, as they're fresh installs since we waded into some DST trials years back.
2 separate server installations, mine and another family member.
All running Jarvis 16.1 on client end, windows 7, windows 10, Android tv, Rasp Pi, and samsung android tablet.

I'm annoyed I didn't save the log files of the incidents I originally captured. I'll revert the dll and try and capture some more failures
However you can see at the beginning of the record event debug it actually prints out the correct program and time it should start.
Its only after transitioning through that BreakBroadcastID that things seem to get broken.
That was based on my manually working through the calcs based on the values from the debug line: New, start: 1474905540, end: 1474906805, chanID: 1009 now: 1474896142
Which I don't believe should've resulted in an outputted value : localtime=2016-09-26T23:58:59

I can see the dates going in and out of that function end up being out by 1 minute, not 1 hour.
However when I added some code and rebuilt locally using VC 2015 I'm yet to get it to fault again.
Handed the dll to my father who has also had a week of no problems. It's a bit larger than what comes with kodi..
I really can't see how this is a fix though, as it's an issue across multiple platforms..

So either we've just been lucky this week or simply rebuilding with 2015 seems to have changed something.
Note I did a completely clean release build with no changes to test with first and thats what we've been using.
I also added some code to dump out some of the calcs that occur during that BreakBroadcastID code but haven't had that version capture anything wrong yet either..

So I'm trying to rebuild openelec locally at the moment to chuck onto a pi and see if I can get it to break again there.

I could see the time values seemingly end up wrong going in and out of that function.
Though honestly I can't see how in the world it'd get the calcs wrong, theres nothing particularly special going on in there.
I find it unusual that it actually needs to go into that path anyway, it already has a valid time etc.

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..
I'll try to install 17 on a windows machine and build your branch later this week.
sigh more arguing with Git.. I really need to wrap my head around it..


Cheers
Richard

[nickr]

Looked more carefully at your post.

What is your standard pre-roll in mythtv? It doesn't hurt to start a minute early and stop 5 minutes late, to allow for TV company being out a bit.

[rtresidd]

I start 5 minutes before and end 5 minutes after,
But the time values going in and out of that function are related to actual program time and don't yet take into account those adjustments from what I can see.
That seems to happen elsewhere.

I did try fiddling with that to make sure, by setting it at 0 or 10 etc, didn't seem to make a difference.
Also tried recording either side of programs that were really short, like 5 minute items and still had the issue of it picking the time 1 minute before..

I'll try and install the old dll during the week and capture some more logs.
Rather time consuming as it didn't always seem to chuck a wobbly on me, other times it never got it right.

[nickr]

OK.

Anyway, I set my recordings from mythweb, does that make a differnce?