EPG123 Bug Reports

An evolving, supported alternative to Rovi
Forum rules
★ Download the latest EPG123 here: https://garyan2.github.io/ <> Setup guide here: https://garyan2.github.io/install.html
User avatar
garyan2

Posts: 7438
Joined: Fri Nov 27, 2015 7:23 pm
Location:

HTPC Specs: Show details

#61

Post by garyan2 » Fri Mar 18, 2016 5:32 pm

In the next build I have added tracing information when something like this happens. I just don't particularly know how to handle it just yet. If you notice "The Blacklist" ended at probably 9:01PM, but "Shades of Blue" was probably scheduled to start at 9:00PM ... hence, the guide funkiness. The error probably occurred a couple weeks ago and has just continued on. I'll have to look back at code changes, but originally I had allowed that to happen and there is not really any good way to correct it on updates.

The error that gets propagated is in the ScheduleEntries area. If you notice, the first entry has a startTime attribute and ideally all the following entries do not. The following start times are based off the original time and the summation of the program durations. Originally when I detected these discontinuities, I would start a new group of entries by timestamping the entry ("Shades of Blue") with 9:00PM which made it permanent ... regardless of the updated values. On an update, that overlap was probably corrected but epg123 is not aware enough to know that is should correct the start time of "Shades of Blue".

I changed v0.7.6 logic to just allow the overlap and only correct for schedule gaps ... that would have prevented the above observations but would have had everything in your guide offset by a minute for probably a day ... 13 days in the future. Just writing this sentence makes you realize just how little we probably care about this if we feel comfortable that it will correct itself.

EDIT: Looking at my mxf file from last night, "The Blacklist" should have started at 8:00PM and ended at 9:00PM, "Shades of Blue" should have start at 9:00PM and ended at 10:00PM. I'll have to try and recreate all this to find exactly what happened 2 weeks ago.
- Gary
Keeping WMC alive beyond January 2020. https://garyan2.github.io

rkulagow

Posts: 246
Joined: Sun Jul 19, 2015 1:04 am
Location: Schedules Direct

HTPC Specs: Show details

#62

Post by rkulagow » Fri Mar 18, 2016 6:02 pm

Space wrote: I think it usually happens when a show is changed in the Gracenote database from ending at one time to ending at another time, it sometimes updates that show to end at the new time, but does not change the show following it to start at the new time (at least not right away).
If the snapshot that is used to build the MXF file catches it in this state, it will include shows that overlap like this.

Example:

Show1 1:00pm - 2:00pm
Show2 2:00pm - 3:00pm

A schedule change happens, where Show1 is changed to end at 2:05pm instead of 2:00pm, but for some reason it does not also update the start time of Show2:

Show1 1:00pm - 2:05pm
Show2 2:00pm - 3:00pm
There are measures in place to prevent this from happening. If you're still seeing show overlap / underlap in the _raw_ JSON, then please let me know.

When I wrote my proof-of-concept grabber for MythTV, I couldn't find a reliable way to update timeslots that didn't potentially include a cascade effect, so I just load the schedule each time. Since the data is already local by that point, it's pretty fast, and I don't need to determine how to update a timeslot that was 60 minutes and is now 62 minutes, which means the next show has to go from 60 minutes to 58 minutes, etc, etc.

kmp14

Posts: 138
Joined: Sat Sep 08, 2012 7:23 pm
Location:

HTPC Specs: Show details

#63

Post by kmp14 » Fri Mar 18, 2016 8:10 pm

garyan2 wrote:In the next build I have added tracing information when something like this happens. I just don't particularly know how to handle it just yet. If you notice "The Blacklist" ended at probably 9:01PM, but "Shades of Blue" was probably scheduled to start at 9:00PM ... hence, the guide funkiness. The error probably occurred a couple weeks ago and has just continued on. I'll have to look back at code changes, but originally I had allowed that to happen and there is not really any good way to correct it on updates.

The error that gets propagated is in the ScheduleEntries area. If you notice, the first entry has a startTime attribute and ideally all the following entries do not. The following start times are based off the original time and the summation of the program durations. Originally when I detected these discontinuities, I would start a new group of entries by timestamping the entry ("Shades of Blue") with 9:00PM which made it permanent ... regardless of the updated values. On an update, that overlap was probably corrected but epg123 is not aware enough to know that is should correct the start time of "Shades of Blue".

I changed v0.7.6 logic to just allow the overlap and only correct for schedule gaps ... that would have prevented the above observations but would have had everything in your guide offset by a minute for probably a day ... 13 days in the future. Just writing this sentence makes you realize just how little we probably care about this if we feel comfortable that it will correct itself.

EDIT: Looking at my mxf file from last night, "The Blacklist" should have started at 8:00PM and ended at 9:00PM, "Shades of Blue" should have start at 9:00PM and ended at 10:00PM. I'll have to try and recreate all this to find exactly what happened 2 weeks ago.
Thanks for the update. Let me know if I can provide any more info.

Space

Posts: 2838
Joined: Sun Jun 02, 2013 9:44 pm
Location:

HTPC Specs: Show details

#64

Post by Space » Fri Mar 18, 2016 9:03 pm

garyan2 wrote:...
I changed v0.7.6 logic to just allow the overlap and only correct for schedule gaps ... that would have prevented the above observations but would have had everything in your guide offset by a minute for probably a day ... 13 days in the future. Just writing this sentence makes you realize just how little we probably care about this if we feel comfortable that it will correct itself.
...
I don't feel comfortable that it will be corrected, but I guess the log can be monitored to see how often it happens and is not corrected (if any). Having the entire day for a single channel be offset by 15 minutes (or however many minutes) could be really frustrating if it stays that way until the end. But even on future days, it can be a problem for setting up Series that record at a specific time (and perhaps even one-off records, but I'm not sure about those).

One way to "fix" this problem is to assume that the latest update is correct. So if a show used to be 9-10pm and the start time changes to 8:55-10pm, then you can assume that is correct and automatically adjust the preceding show to end at 8:55 instead of 9pm. This may not be the correct action (it may be that the latest update was a mistake), but at least you won't have overlap anymore. Of course this doesn't work if the overlap is there from the start. But I think this fix would be better done on the Gracenote or SD side. rkulagow said there were measures in place that should have prevented this, but I am not sure what it is attempting to do.

Sammy2

Posts: 1708
Joined: Fri Aug 24, 2012 7:35 pm
Location:

HTPC Specs: Show details

#65

Post by Sammy2 » Mon Mar 21, 2016 9:55 am

Not sure if it is related or not but after installing EPG123 both of my HDHR Prime tuners and tuning adapters needed to be reset in order to be able to tune Switched Digital Video.

I've been busy on other tasks since after installing EPG123 and haven't had time until this morning to follow up with resetting the tuners and adapters but thus far it is working well.

Still need to run through Guide Tool to fix my line up numbering and MCL XL to put my logos back in though..

ja216

Posts: 14
Joined: Sun Aug 25, 2013 11:57 pm
Location:

HTPC Specs: Show details

#66

Post by ja216 » Mon Mar 21, 2016 3:34 pm

TV setup is stuck downloading TV setup data for hours. I followed your steps on this page http://epg123.garyan2.net/?page_id=5.

Stopping the process with task manager and restarting brings the same results. any ideas?

thanks
jon

User avatar
garyan2

Posts: 7438
Joined: Fri Nov 27, 2015 7:23 pm
Location:

HTPC Specs: Show details

#67

Post by garyan2 » Mon Mar 21, 2016 5:29 pm

ja216 wrote:TV setup is stuck downloading TV setup data for hours. I followed your steps on this page http://epg123.garyan2.net/?page_id=5.

Stopping the process with task manager and restarting brings the same results. any ideas?

thanks
jon
Here I thought my laptop was dying on me. I was running a lot of test runs of the future v0.9.0 and that step would take forever ... mostly due to TrustedInstaller and CABMaker. Looks like MS is pushing some updates to MC at this step. My setups never took that long, but it was easily 25-30 minutes just to get through that step.

This will be a result of deleting the directory I think. Maybe have to alter our Step 0 process for this issue.
- Gary
Keeping WMC alive beyond January 2020. https://garyan2.github.io

kmp14

Posts: 138
Joined: Sat Sep 08, 2012 7:23 pm
Location:

HTPC Specs: Show details

#68

Post by kmp14 » Mon Mar 21, 2016 8:30 pm

ja216 wrote:TV setup is stuck downloading TV setup data for hours. I followed your steps on this page http://epg123.garyan2.net/?page_id=5.

Stopping the process with task manager and restarting brings the same results. any ideas?

thanks
jon

I did NOT do step 0, but I also had a hang when walking through the guide setup. I am impatient, so I assumed it was a hard hang, so I killed Media Center and just continued on the next step, and everything is working great. I cannot, however, remember exactly where in the TV setup it hung.

mldenison

Posts: 287
Joined: Tue Sep 11, 2012 1:36 am
Location:

HTPC Specs: Show details

#69

Post by mldenison » Thu Mar 24, 2016 2:23 am

I noticed my log has a large number of these entries for different stationID's. Does this mean my guide is not updating for some reason?

Code: Select all

[3/21/2016 12:01:13 PM] [WARNG] Failed to parse the schedule Md5 return for stationId 26197 on 2016-04-05. message: Cannot perform runtime binding on a null reference

User avatar
garyan2

Posts: 7438
Joined: Fri Nov 27, 2015 7:23 pm
Location:

HTPC Specs: Show details

#70

Post by garyan2 » Thu Mar 24, 2016 3:22 am

mldenison wrote:I noticed my log has a large number of these entries for different stationID's. Does this mean my guide is not updating for some reason?

Code: Select all

[3/21/2016 12:01:13 PM] [WARNG] Failed to parse the schedule Md5 return for stationId 26197 on 2016-04-05. message: Cannot perform runtime binding on a null reference
Typically means there is no schedule data for that station on those dates. Looks like that grab was 15 days in the future. Station 26197 is GAME1 which is pay-per-view sports ... I would expect a lot of these, I guess ... wondering if I should suppress them.
- Gary
Keeping WMC alive beyond January 2020. https://garyan2.github.io

mldenison

Posts: 287
Joined: Tue Sep 11, 2012 1:36 am
Location:

HTPC Specs: Show details

#71

Post by mldenison » Thu Mar 24, 2016 12:11 pm

I wouldn't mind if they were suppressed. My log would be a lot smaller :>)

User avatar
garyan2

Posts: 7438
Joined: Fri Nov 27, 2015 7:23 pm
Location:

HTPC Specs: Show details

#72

Post by garyan2 » Fri Mar 25, 2016 3:03 am

mldenison wrote:I wouldn't mind if they were suppressed. My log would be a lot smaller :>)
How 'bout if I only report the first day without any guide data? Or just suppress anything greater than 14 days out? ... thinking that would be better.
- Gary
Keeping WMC alive beyond January 2020. https://garyan2.github.io

mldenison

Posts: 287
Joined: Tue Sep 11, 2012 1:36 am
Location:

HTPC Specs: Show details

#73

Post by mldenison » Fri Mar 25, 2016 12:13 pm

That's a winner.

User avatar
Ladislaus

Posts: 91
Joined: Mon Jan 26, 2015 6:52 pm
Location: NJ

HTPC Specs: Show details

#74

Post by Ladislaus » Fri Mar 25, 2016 1:09 pm

garyan2 wrote:
mldenison wrote:I wouldn't mind if they were suppressed. My log would be a lot smaller :>)
How 'bout if I only report the first day without any guide data? Or just suppress anything greater than 14 days out? ... thinking that would be better.
What if you simply reported the issue once with a count of how many times the issue occurred? That way you would know if it occurred once, twice, or 25 times. Just thinking 'out loud'.

3rob3

Posts: 548
Joined: Sun Aug 28, 2011 8:48 pm
Location:

HTPC Specs: Show details

#75

Post by 3rob3 » Fri Mar 25, 2016 8:38 pm

I noticed what may be a bug today. After I set up EPG123 I re-added all my TV series recordings. The Last Man on Earth was on break so I couldn't add it. It comes back on April 3rd, and is now there in the guide, but searching for it in Add Recordings turns up no results. Any ideas?

webminster

Posts: 657
Joined: Tue Dec 20, 2011 11:05 pm
Location:

HTPC Specs: Show details

#76

Post by webminster » Fri Mar 25, 2016 11:33 pm

Not sure about your case... I tried doing a search by title (directly and via Add Recording / Search / Title) and it found by title, searching for "The Last Man" or even "Last Man". Running 0.7.6?
-Alan

3rob3

Posts: 548
Joined: Sun Aug 28, 2011 8:48 pm
Location:

HTPC Specs: Show details

#77

Post by 3rob3 » Sat Mar 26, 2016 12:16 am

Yep, 0.76 was the first (and only) version I tried.
In Search:
LastMan.jpg
In Guide:
InGuide.jpg
Thanks for taking the time to check though! Whenever 0.9 comes out I will start fresh again and see if that clears anything up.

User avatar
garyan2

Posts: 7438
Joined: Fri Nov 27, 2015 7:23 pm
Location:

HTPC Specs: Show details

#78

Post by garyan2 » Sat Mar 26, 2016 1:49 am

Anything in the trace.log file to indicate the indexing task is not running? That's the only time I've seen a search fail is the indexing didn't run/complete.
- Gary
Keeping WMC alive beyond January 2020. https://garyan2.github.io

3rob3

Posts: 548
Joined: Sun Aug 28, 2011 8:48 pm
Location:

HTPC Specs: Show details

#79

Post by 3rob3 » Sat Mar 26, 2016 1:09 pm

garyan2 wrote:Anything in the trace.log file to indicate the indexing task is not running? That's the only time I've seen a search fail is the indexing didn't run/complete.
Looks like you are on to something:
[ERROR] Error using schtasks.exe to start ReindexSearchRoot task. Exit code: 1

Any idea why this would fail?

glorp

Posts: 369
Joined: Sun Sep 23, 2012 2:54 pm
Location:

HTPC Specs: Show details

#80

Post by glorp » Sat Mar 26, 2016 2:30 pm

3rob3 wrote:Any idea why this would fail?
There's another thread here with a post from Sammy2 with his log that shows the same error. Unfortunately I can't find it now. garyan2 should look at this because I thought it was odd then and yours is the second instance. Permissions for what he's doing to kick it off from from scheduled tasks I'd bet, but that's just a wild guess on my part.

Post Reply