trace.log entry: [WARNG] Time discontinuity

[rkulagow]

I've confirmed that this is an upstream bug and I've opened a ticket with Gracenote. There are actually two types of errors that I'm finding; an actual gap, where there should be a program, but isn't, and a duplicate, where one timeslot has more than one program in it.

For now I don't need any additional tickets opened; the ones I have already were sufficient to determine what was happening.

[webminster]

I've confirmed that this is an upstream bug and I've opened a ticket with Gracenote. There are actually two types of errors that I'm finding; an actual gap, where there should be a program, but isn't, and a duplicate, where one timeslot has more than one program in it.

For now I don't need any additional tickets opened; the ones I have already were sufficient to determine what was happening.

Just curious, if you got any traction with your upstream ticket...

[rkulagow]

I've been running my own updated code for looking for gaps and dupes, and haven't seen any in the last few days. Are you still seeing them in your log?

[schottjy]

I'm stilling seeing the same SPROUT time discontinuities reported for Time Warner Cable 27612.

[glorp]

I've been running my own updated code for looking for gaps and dupes, and haven't seen any in the last few days. Are you still seeing them in your log?

Yes as of the run a couple hours ago. The same ones now for a couple of weeks. Mostly SPROUT but also some from RTN and HBOHDP. Not channels I give a flying you-know-what about but it clutters up the log. I wish I could shut off warnings, or at least those warnings.

[Sammy2]

I've been running my own updated code for looking for gaps and dupes, and haven't seen any in the last few days. Are you still seeing them in your log?

Yes..

SPROUT and ELREYHD mostly.

[rkulagow]

Please send me the relevant portion of your log to rkulagow@gmail.com and I will compare that to the raw code so that I can see what's happening.

[garyan2]

I'm going to do a drive-by on this one. Just a quick question to rkulagow: If the upstream problem was corrected, did the md5 change? If not, then what we are seeing is residual from the initial problem. epg123 does not update the stations schedule if the md5 doesn't change.

For anyone seeing this issue, a quick check for this condition would be to clear out your cache and download everything again (force a refresh). If the warnings go away, then we are working with stale data and it will eventually die out. If not, then there is still an upstream issue.

[rkulagow]

Based on the file that was mailed to me by a user, I had a bug in my code. Although Gracenote said they couldn't reproduce my findings, they've asked me to provide them in a different format, which I'm programming now.

Once the upstream issue is fixed, then yes, the MD5 will change, and that will let you dynamically refresh the stations that need to be updated.

But, at this point this is still an upstream issue that needs to get resolved at the source.

[Sammy2]

Please send me the relevant portion of your log to rkulagow@gmail.com and I will compare that to the raw code so that I can see what's happening.

Based on the file that was mailed to me by a user, I had a bug in my code. Although Gracenote said they couldn't reproduce my findings, they've asked me to provide them in a different format, which I'm programming now.

Once the upstream issue is fixed, then yes, the MD5 will change, and that will let you dynamically refresh the stations that need to be updated.

But, at this point this is still an upstream issue that needs to get resolved at the source.

Do you need to take a look at mine too or is the one you already received sufficient for now?

[webminster]

Robert, just as a second data point, mailed you some logs as well. A lot are SPROUT, same as sammy2. Plus some others. Some are for a week away so may not be a real issue... like the SPOUT entries for several days on and after 4/17.

[Sammy2]

I sent one too just in case.

[rkulagow]

Thanks, everyone. I have enough data for now to go back to Gracenote again.

[schottjy]

Thank your Richard for your active support.

[Sammy2]

x1000 !!!!

[Sammy2]

Seeing a few time discontinuities for CSPAN in today's log. Not that I watch it but it is there.

[glorp]

Once the upstream issue is fixed, then yes, the MD5 will change, and that will let you dynamically refresh the stations that need to be updated.

But, at this point this is still an upstream issue that needs to get resolved at the source.

Is this just expected to be the case that these errors may or may not get fixed by the source? I've still got all these original SPROUT channel errors and those seem to be persistent and haven't changed since they started up a couple weeks ago. In the last couple of days a handful of other channels started with these same errors and another couple from before disappeared.

I guess if it's "regular" behavior I'd like to see these suppressed by EPG123 either by option or just get rid of the checks. There's nothing we can do about it except report it anyway.

[rkulagow]

garyan2, I have a system in place now which finds both duplicates and gaps in the schedule which I send to Gracenote so that they can determine what's happening on their end. If you'd like to make it optional in your client then I'm fine with it.

[garyan2]

garyan2, I have a system in place now which finds both duplicates and gaps in the schedule which I send to Gracenote so that they can determine what's happening on their end. If you'd like to make it optional in your client then I'm fine with it.

Yah, I'll probably have an option of error levels to trace. I'll have totally rework the tracing code, but it is not complicated.

[STC]

THIS is what makes EPG123 top banana thank you both.