EPG123 Bug Reports
Forum rules
★ Download the latest EPG123 here: https://garyan2.github.io/ <> Setup guide here: https://garyan2.github.io/install.html ★
★ Download the latest EPG123 here: https://garyan2.github.io/ <> Setup guide here: https://garyan2.github.io/install.html ★
- garyan2
- Posts: 7474
- Joined: Fri Nov 27, 2015 7:23 pm
- Location:
- HTPC Specs:
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.
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
Keeping WMC alive beyond January 2020. https://garyan2.github.io
-
- Posts: 246
- Joined: Sun Jul 19, 2015 1:04 am
- Location: Schedules Direct
- HTPC Specs:
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.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
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.
-
- Posts: 138
- Joined: Sat Sep 08, 2012 7:23 pm
- Location:
- HTPC Specs:
Thanks for the update. Let me know if I can provide any more info.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.
-
- Posts: 2839
- Joined: Sun Jun 02, 2013 9:44 pm
- Location:
- HTPC Specs:
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).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.
...
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.
-
- Posts: 1708
- Joined: Fri Aug 24, 2012 7:35 pm
- Location:
- HTPC Specs:
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..
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..
-
- Posts: 14
- Joined: Sun Aug 25, 2013 11:57 pm
- Location:
- HTPC Specs:
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
Stopping the process with task manager and restarting brings the same results. any ideas?
thanks
jon
- garyan2
- Posts: 7474
- Joined: Fri Nov 27, 2015 7:23 pm
- Location:
- HTPC Specs:
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.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
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
Keeping WMC alive beyond January 2020. https://garyan2.github.io
-
- Posts: 138
- Joined: Sat Sep 08, 2012 7:23 pm
- Location:
- HTPC Specs:
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.
-
- Posts: 287
- Joined: Tue Sep 11, 2012 1:36 am
- Location:
- HTPC Specs:
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
- garyan2
- Posts: 7474
- Joined: Fri Nov 27, 2015 7:23 pm
- Location:
- HTPC Specs:
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.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
- Gary
Keeping WMC alive beyond January 2020. https://garyan2.github.io
Keeping WMC alive beyond January 2020. https://garyan2.github.io
-
- Posts: 287
- Joined: Tue Sep 11, 2012 1:36 am
- Location:
- HTPC Specs:
I wouldn't mind if they were suppressed. My log would be a lot smaller :>)
- garyan2
- Posts: 7474
- Joined: Fri Nov 27, 2015 7:23 pm
- Location:
- HTPC Specs:
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.mldenison wrote:I wouldn't mind if they were suppressed. My log would be a lot smaller :>)
- Gary
Keeping WMC alive beyond January 2020. https://garyan2.github.io
Keeping WMC alive beyond January 2020. https://garyan2.github.io
-
- Posts: 287
- Joined: Tue Sep 11, 2012 1:36 am
- Location:
- HTPC Specs:
That's a winner.
- Ladislaus
- Posts: 91
- Joined: Mon Jan 26, 2015 6:52 pm
- Location: NJ
- HTPC Specs:
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'.garyan2 wrote: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.mldenison wrote:I wouldn't mind if they were suppressed. My log would be a lot smaller :>)
-
- Posts: 548
- Joined: Sun Aug 28, 2011 8:48 pm
- Location:
- HTPC Specs:
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?
-
- Posts: 657
- Joined: Tue Dec 20, 2011 11:05 pm
- Location:
- HTPC Specs:
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
-
- Posts: 548
- Joined: Sun Aug 28, 2011 8:48 pm
- Location:
- HTPC Specs:
Yep, 0.76 was the first (and only) version I tried.
In Search: In Guide: 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.
In Search: In Guide: 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.
- garyan2
- Posts: 7474
- Joined: Fri Nov 27, 2015 7:23 pm
- Location:
- HTPC Specs:
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
Keeping WMC alive beyond January 2020. https://garyan2.github.io
-
- Posts: 548
- Joined: Sun Aug 28, 2011 8:48 pm
- Location:
- HTPC Specs:
Looks like you are on to something: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.
[ERROR] Error using schtasks.exe to start ReindexSearchRoot task. Exit code: 1
Any idea why this would fail?
-
- Posts: 369
- Joined: Sun Sep 23, 2012 2:54 pm
- Location:
- HTPC Specs:
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.3rob3 wrote:Any idea why this would fail?