EPG123 Bug Reports

[Space]

This error simply is telling you that there have been a lot of lineup changes since the last time you saved the configuration of EPG123.

If you run the EPG123 Configuration GUI and look at your lineups and they look good to you (not missing any channels that should not be missing) then you can simple press the "Save & Execute" button and this will save the existing lineup as the new baseline and you should no longer see that error until more lineup changes occur that exceed the percentage threshold to abort the update.

The purpose of this is to protect against a whole bunch of channels being removed from your lineup incorrectly and unexpectedly, causing WMC to not record many of your shows due to a bad lineup mistake at the provider side. So if you have 100 channels in your lineup and 50 of them are removed by the provider, that is an indication of a possible problem, so EPG123 aborts the update so that you can look at it and verify the removal of those 50 channels was valid or not.

[jea101]

Thanks Space
Save and execute fixed the problem.

Does updating to a new version of epg123 do the same cleanup?
I have been using epg123 for several years and I don’t believe I ever did this before.
Also, is there a user guide/manual that explain what the errors and warnings mean.

My current procedure for trying to fix guide update errors.
Rename trace.log.
Check Internet access.
Manually run the update scheduled task
If update still fails check to see if there is a newer version of epg123.
If latest version fails come to this web site to see if others are having the problem.

[Space]

I don't believe updating to a new version of EPG123 would clear this issue. As I indicated, this is on purpose. It is meant as a fail-safe mechanism so that you don't miss recordings due to active channels being mistakenly removed from your lineup.

I don't think there is one place to go to find the explanation of the errors in the log, but searching the forums on this site would probably help.

[garyan2]

Actually, I've been looking at adding action items in the log for common "failures". In the beta 1.8.2.8, the log would have looked like this:

Code: Select all

[1/29/2024 8:04:44 AM] [ERROR] Of the expected 850 stations to download, there are only 796 stations available from Schedules Direct. Aborting update for review by user.
[1/29/2024 8:04:44 AM] [ERROR] ACTION: Review log file to see what stations have been added and removed from your lineup(s) since you last saved your configuration.
[1/29/2024 8:04:44 AM] [ERROR] ACTION: Open configuration GUI and review lineup(s). If lineup channels and stations are accurate, click [Save] to rebaseline the expected number of stations to download.

[IT Troll]

That should save you a few posts.
Now you just need to get folks to read the log...

[garyan2]

That should save you a few posts.
Now you just need to get folks to read the log...

Yah, that's the frustrating part. I can put quite a bit of thought and work into these log "action" items but it doesn't mean anything if the user doesn't read, or attempt to understand, what information is being provided. If emails were on paper, I'd have a pretty tall stack of "My EPG is gone. Help." messages.

[garyan2]

Gary,

I have had my StorageWarningGB set to 120 since I started using it, however, recently I noticed that I hadn't gotten any warnings mailed to me in a while, so checked the log and saw that free space was down to around 73 GB.

First thing I did was check the EPG123 log to see when the free space dropped below 120GB and it was on 1/25. I then checked if the email settings in EPG123 were correct and they were, and I was able to successfully send a test email from EPG123.

I then looked at the storage setting in the client, and that is where I saw the problem, somehow the StorageWarningGB was set to -1 instead of 120.

Do you have any idea what might have caused this change?

It looks like the config.json file was touched today, during the last automatic update, so I was unable to use the modification timestamp to determine when this config change might have happened. Does the client modify this file every time it runs for some reason?

I'm running version 1.8.2.7.

I finally had a chance to take a look at this. It appears that if you send a test email for the notification it overwrites your storage & conflicts settings to default. I'll get this fixed in next release.

[Space]

...
I finally had a chance to take a look at this. It appears that if you send a test email for the notification it overwrites your storage & conflicts settings to default. I'll get this fixed in next release.

Hmmm, I'm not sure this was my problem, though... It was working fine, as far as I can remember, before it just stopped working. I didn't send the test email until I already was having the problem.

I did change my email password at some point, so had to update that in EPG123, maybe it happened then, but that was a while ago and I would be surprised if I wasn't getting the disk space emails since then... Unfortunately I don't save most of the EPG123 emails and I don't recall if I got any since that change, so I suppose it might be related to this bug... Hopefully this will be the cause.

Thanks!

[technodevotee]

Microsoft defender refuses to download epg123setup_v1.8.2.9.zip because it says it contains Trojan:Script/Wacatac.B!ml

The portable version seems OK.

[IT Troll]

Downloaded fine for me just now with Defender using definitions created 16/02/2024 20:48.

[technodevotee]

Very odd - I tried it on two different PCs and had the same error but it downloaded fine today.

[Engineer]

EPG123 v1.8.2.10 Beta upon system boot is generating a Windows Event Viewer ID1026:

Application: epg123Server.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.ObjectDisposedException
at System.Net.Sockets.UdpClient.EndReceive(System.IAsyncResult, System.Net.IPEndPoint ByRef)
at epg123Server.UdpServer.ProcessDatagram(System.IAsyncResult)
at System.Net.LazyAsyncResult.Complete(IntPtr)
at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
at System.Net.ContextAwareResult.Complete(IntPtr)
at System.Net.LazyAsyncResult.ProtectedInvokeCallback(System.Object, IntPtr)
at System.Net.Sockets.BaseOverlappedAsyncResult.CompletionPortCallback(UInt32, UInt32, System.Threading.NativeOverlapped*)
at System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32, UInt32, System.Threading.NativeOverlapped*)

My system:
Windows 10 Pro x64, all updates installed
.NET v8.0.2
Media Center v8.9.1

This has been occurring for some time - sorry, I do not know for how long. Everything seems to be working fine - guide is updating, Media Center playing/recording, no other errors in Event Viewer.

[garyan2]

I was able to observe this on my virtual machine. It appears to only be when the service is shutting down. The UDP listener (as well as the HTTP listener) will try to complete a call that doesn't exist on an object that has been disposed while disposing the listener. I'll throw some catches in the code to prevent the error logging a something that appears expected.