That's entirely possible, Laurie. This afternoon WSJT-X decoded 62 stations when the radio was on 20 meter FT8, and that's a whole lot of stations to sort out between time slices. It wouldn't have bee

I'm seeing the same thing on FT8. But it happens so infrequently that I can't establish a pattern of necessary conditions to cause this behavior. There are no Decoding Options filters turned on. Jim W

Bill, you might want to reexamine the configurations of all of the security products that are on your system, to see if one of them needs to have its whitelist or blacklist updated. You probably know

For everyone's information, I downloaded the missing file using the directions in one of Laurie's latest support postings. Adding that file to the proper config directory location fixes the problem an

Excellent news, indeed. I'll wait for the latest version to be published before doing anything else. Thanks and 73, Jim W9FI

Mike, to what should it be renamed? Will the JTAlert app find the data that it needs when all of this needed information is filed under a different location name? Jim

OK, going in through the %localappdata%\HamApps\JTAlert\W9FI\Config\ pathway leads me to a different place. That config file only contains a 5k Decodes History V3.config file and nothing else. "Callsi

Thanks for the advice, Bill. I've already tried the uninstall/reinstall process, although in my case the earlier version was 2.16.14. The next step is probably to uninstall 2.50.3, install 2.50.2, and

Laurie, the config file only contains two more files, JTAlert and JTAlertX. Each of these files contains config.sqlite records. "Callsigns_1.config" & "Callsigns_1.config.json" are not not within the

Correction noted.

JTAlert is whitelisted, so PCMatic stays out of its way. Those warnings are just timestamped notes that an app on the exception list passed by. There is nothing on Event Viewer for any HamApps applica

I installed .NET 5.0.8 and there was no change in JTAlert's behavior. Same symptoms. Now I'm going to uninstall version 2.50.3 and replace it with version 2.50.2. Test results will follow. Jim W9FI

I backed up the event log and then erased it, so that I could get a fresh start on the current events. Then I started up WSJT-X and JTAlert. JTAlert behaved exactly the same as it did last night, with

Laurie, here's one more item that was buried in my notes to myself. Task Manager saw that HamApps "Decoder" was running consistently, but that HamApps "Audio and Visual Alerts for WSJT-X (32 bit)" was

I'll hold off on making this change and instead see how version 2.50.2 behaves. Jim W9FI

Thanks for your reply, Joe, and hello again on a different forum. I tried changing the UDP address to 224.0.0.1 without success, but that was before I turned off Windows Defender and got it out of the

Thanks for the quick response. Here are the answers to your questions. The CPU usage never topped 24%, with most of the load coming from WSJT-X's decoding engine at 12% -14%. JTAlert's usage typically

I've been using JTAlert with WSJT-X for several years without any problems at all, until last night when I updated to version 2.50.3, 64 bit. Several problems now have appeared. There is a general slu