EPG123 exception and 0 cache entries

[Space]

Code: Select all

[9/21/2020 7:51:29 PM] Entering buildAllProgramEntries() for 49853 programs.
[9/21/2020 7:51:40 PM] [ INFO] Found 46856 cached program descriptions.
[9/21/2020 7:56:40 PM] [ INFO] SD API WebException Thrown. Message: The remote server returned an error: (504) Gateway Timeout. , Status: ProtocolError
[9/21/2020 7:56:45 PM] [ INFO] Successfully retrieved 2997 program descriptions. (0:00:05:04.9404209 /     5.014 MB)
[9/21/2020 7:56:47 PM] [ INFO] Processed 49853 program descriptions.
[9/21/2020 7:56:47 PM] Exiting buildAllProgramEntries(). SUCCESS.

Gary,

Seems that the SD server was very slow during today's update, but other than the increased time it took to do it's thing (and a time discontinuity for one of the channels), I only saw the above exception in the log.

I did not see any warnings or errors related to this exception so I assume it retried and was successful. Am I correct in this assumption?

Is this slowness and timeout normal if the server is updating it's data? Or might there be some other server issue during this time?

For instance, getAllScheduleEntryMd5s() normally takes around 20 seconds to complete and today it took over 6 minutes.

Code: Select all

[9/21/2020 7:45:20 PM] Entering getAllScheduleEntryMd5s() for 21 days on 365 stations.
[9/21/2020 7:48:54 PM] [ INFO] Successfully retrieved Md5s for 238 station's daily schedules. (0:00:03:33.8902951 /   455.516 KB)
[9/21/2020 7:49:04 PM] [ INFO] Successfully retrieved 238 station's daily schedules.          (0:00:00:10.7000148 /    22.313 MB)
[9/21/2020 7:51:12 PM] [ INFO] Successfully retrieved Md5s for 127 station's daily schedules. (0:00:01:52.5001553 /   243.089 KB)
[9/21/2020 7:51:17 PM] [ INFO] Successfully retrieved 127 station's daily schedules.          (0:00:00:05.0000069 /     8.071 MB)
[9/21/2020 7:51:23 PM] [ INFO] Found 0 cached daily schedules.
[9/21/2020 7:51:23 PM] [ INFO] Downloaded 6570 daily schedules.
[9/21/2020 7:51:23 PM] [WARNG] Time discontinuity detected. Service 10161 (CSPAN) SH012857740000 (entry 17) ends at 2020-09-22 01:15:00Z, SH025236580000 (entry 18) starts at 2020-09-22 00:45:00Z. No further discontinuities on CSPAN will be reported for the date 2020-09-22.
[9/21/2020 7:51:28 PM] [ INFO] Processed 6570 daily schedules for 365 stations.
[9/21/2020 7:51:28 PM] Exiting getAllScheduleEntryMd5s(). SUCCESS.

It also "Found 0 cached daily schedules" during this section, which is unusual, since for the past 5 updates if found around 5000 cached entries. Is there a reason EPG123 would ignore cached entries, or may there be a problem with loading the cache for some reason? Note that it did find cached entries for the other stuff:

[9/21/2020 7:51:23 PM] [ INFO] Found 0 cached daily schedules.
[9/21/2020 7:51:40 PM] [ INFO] Found 46856 cached program descriptions.
[9/21/2020 7:56:47 PM] [ INFO] Found 6674 cached series descriptions.
[9/21/2020 7:57:10 PM] [ INFO] Found 4261 cached movie poster links.
[9/21/2020 7:57:11 PM] [ INFO] Found 6674 cached series image links.

If EPG123 had a problem opening the cache file, would it report an error or just silently indicate it found 0 entries? I believe there is just one file that stores the cache, so I would think it would be a bit strange to have a problem with the daily schedules cache entries and not the others.

I'm hoping there is not some sort of disk issue here, as I've had disk issues in the past. Note that I am currently using EPG123 version 1.3.9.30.

[garyan2]

Sometime between 1120Z and 1420Z, the servers for the md5 basically stopped. I let rkulagow know what I was seeing and he was working on it. Apparently Gracenote changed how they did season/episode numbers and this was causing a buffer overflow. He got it back up but it is probably still rebuilding quite a few things. With the rebuilds and adapting to the s/e changes, all the md5's got recalculated so since they all changed you will have 0 cached.

EPG123 will give a 5 minute timeout for a response from SD. If it fails, it will try 1 more time before proceeding to the next stage if it is allowed.

So right now, the servers may be a bit slow but it will get back to normal soon, hopefully.

[Space]

Ahh, OK, that explains it then. Hopefully making changes and not notifying their customers is not a regular thing for Gracenote.

If the retry fails, I assume it will then log either a warning or error, correct?

It is a little confusing to see that INFO message but then everything else seems to go fine, as if nothing is wrong. Perhaps a message about the successful retry (which is what I assume happened here) might make it clearer.

[garyan2]

If it fails a second attempt, it will log the error, and the icon will be red because of it, but it will continue to complete as much as it can. An incomplete update is still an update and it won't delete anything from WMC. It will shrink the cache file a bit which will cause more to be download next time.