locked Re: Decodes Window Will Not Open (Windows 10)


TomK
 

Hi All. I'm back!
This is a reply to everyone on this topic.
Found and Fixed the Problem

After 72 hours of little sleep, shooting repeatedly in the dark, methodically trying all permutations of my aforementioned actions, utilizing numerous old-hacker tricks, tracing UDP traffic with WireShark, and adding additional steps of uninstalling all apps used in my article "Digital Zen" (WSJT, JTAlert, ACLog, GridTracker), I've eventually arrived at my Eureka moment.

Final Journey:
After repeated failures of all combinations and sequencing of the above machinations, I followed a path subtly suggested by Laurie's query to another's report, "What UDP port does the help show".  I decoded that to mean JT Alert and JT Decodes might cavort via UDP.  I don't know for sure but found evidence of a changed port in my last bad session vs archived notes of an earlier successful config. However, having burnt through 3 days of reconnoitering I reached the point of no return. Losing the config to gain the DECODES was better than having no DECODES.

So, that brought me back, full circle, to my 1st idea of a deep uninstall of JT with deep erasure of its app data areas
 
- as Michael Black also made note of here. 

Analysis and Steps Taken (with some translation for those smart enough to avoid deep tech)

1. Scenario: Heavily loaded workstation quickly reveals slightest app issues
  • I run a typical mid-level but highly loaded workstation with following specs:
  • Intel Core i7 930 @ 3GHz (4 Cores, 8 threads, running at 3GHz);
  • 32GB of RAM; 12 TB DASD (internal and external SATA, USB2, USB3 drives)
  • mid-level NVIDIA GeForce GTX1050Ti graphics card pushing 2 mid-quality 24" monitors;
  • Running JT (16-24)/7/365 with 10-20 other foreground tasks and 50-100 background processes
2. CPU heavily taxed by digital workflow - maxing out with any media apps running
As such, Windows CPU threads and committed memory rapidly max out .
The slightest memory leaks or reduced garbage cleaning by apps can crash/freeze them out.
This happens routinely with WSJT+JTAlert running/decoding (16-24)/7/365.
Typically about 1/ week of continuous running JT crashed/freezes, requiring a hard process kill.

3. Item #2 above was scenario in place the day I lost DECODES 

JT crashed and I had to hard kill it. More specifically, JT Decodes process froze and would not exit.
Another symptom was (for several previous days) Window frame "X" command didn't exit JT.
Only Close Window command on JT's taskbar entry would close all JT Windows (most of the time).
On the day of the DECODES window loss, all the above occurred and ....
the DECODES sub-process kept running requiring a hard kill using the techie util ProcessExplorer.

4. Then my deepest hair pulling and visits here
Most important light bulb was that the config got corrupted, such as a UDP port change?
That may have occurred when orphaned DECODES sub-process hung around and dupe 2nd one started.
So on next run, a new UDP port may have been assigned - breaking the DECODE linkage.
Totally guessing here based only on techie gut and monitoring of the processes.
That "may" have broken JT communication with DECODES and the rest is history.
Whether or not there actually was a UDP port problem, the steps here did fix it.

5. Deep Cleaning
The goal here was to uninstall BOTH the JT Alert app as well as its system data folder.
WARNING: This loses ALL your JT your configuration settings - allowing for a virgin install.
This includes things like JT Macros, Call settings, etc --- everything!
A. Uninstall JT Alert program
  • Run Windows Programs & Features applet (via Windows > Settings Menu > Programs & Features)
  • Then locate JT Alert, double-click, then OK to Uninstall.
B. Renamed "HamApps" local program data folder (deletes w/o data loss by changing it to another name)
Your Windows account needs to be Administrator to access and rename this folder. (Usual case but not always).
  • Locate HamApps's AppData folder in File Explorer by entering path as "%LocalAppData%" (without quotes)
    That's a macro that expands to the path of your AppData\Local folder containing HamApps program data.
  • Locate HamApps folder and rename it to something else like HamApps [old]  (says yes if asked for permission)
At this point, you have removed the JT app as well as all of its configuration data.

C. For Good Measure .. I then ...
Closed all apps, backup programs, and anything else running!
Did a complete POWER DOWN to clear BIOS, USB pilot light, and all disk caches.
Waited a few minutes till all PC lights and fans were dead.

D.  Reboot, Install, Pray
I then reboot, hoping disk woke up again (never count on it, ha)
Reinstalled JT Alert
Ran wSJT & JT
Voila - It worked. Decodes windows back to normal.
The BAD. All custom setting gone. Took an hour to review and reset the all.
Advice: Perform a lot of screen captures of the JT setting screens for easy reference.

Nb. Trick that worked for me:  Don't advise it for non-techies.
I found the SQLite settings database in the old HamApps [old] JT-AlertX app data folder.
I copied it to the same place in the new HamApps folder.
That seemed to have restore all my settings EXCEPT Macros and the bad port assignment.
The former was bad but the latter good!

Laurie, if by chance, my thought on UDP port un-syncing makes any sense, is there a way to reset it?
Like telling us the location and allowing it to be cleared, force a search/reset on next run?
Just some random thoughts.
TomK 73

Join Support@HamApps.groups.io to automatically receive all group messages.