Also, in process explorer, it shows two of the sqlite.journal processes at times. 



Brad, N4PYI

Brad,

I am not seeing that here. I just spent 10 minutes starting at Process Explorer, with a refresh time of 0.5sec, and didn't see the journal file ever.

There is definitely something screwy with your system, but at this time I have no idea what.

Your image shows the old journal file as it was being deleted (red) and the newly created journal file (green). I am surprised to see both at the same time. This looks like some-sort of delay in file deletion.

The other Decodes open files listed looks similar to mine.

   


How long since you restarted Windows? If it has been days, try a restart.

de Laurie VK3AMA

On 21/06/2020 11:06 am, Brad Adams wrote:

I could try to go back to 2.16.6 and see if it comes back. What is the best way to go back to a previous version?

Thanks

Brad, N4PYI

Brad,

Don't go back to 2.16.6, 2.16.7 is better as it has a fix for loss of early first pass decodes of WSJT-X 2.2.1

You don't have to do anything special when downgrading, just run the Setup executable. 2.16.7 is available on HamApps.com to download, towards the bottom of the JTAlert download page.

You will note that with 2.16.7 there is no journal file, but there will be -shm & -wal files.
2.16.8 changed the journal type used with the decodes database to stop the loss of decodes display and occasional database corruption. Yours is the first report of problems with the new journal type in 2.16.8

de Laurie, VK3AMA

Thanks Laurie.  You nailed it.  Trying audio State alerts, the first one is clipped, then all others are fine as long as I test one after another.  I had swapped out a monitor and that's when the audio truncating began.  Switched back to the old monitor and all is well.  Looked around to learn how to shut off the sound driver power saver with no luck.  Seems I've got Realtec.  Downloaded an update for the Driver.  Now WSJTX is not decoding.  Did a system restore to go back to a good time.  No luck.  Not a JTA issue, but on my 3rd evening trying to get decodes working again.  Finding there was a Win10 update somewhere along the line. There us plenty of info on my forums with other having decode problems.  Atleast I learn everytime I run into a new snag, but I think I know just about all I want about computers.  I'd really rather make some QSO's.  Hi  73 Herb WB8ASI

I have a CMD file that will copy the current CONFIG file to a directory below the location on the active CONFIG file

The backup also has an added feature that it will save it as xxxxx,YYYYMMDD-HHMMSS (Note that the xxxxx is the actual CONFIG file's name.

Thus you can save it multiple time thru time.

If you with I will post a copy of it here

John R. Petrocelli - WA2HIP
¶¶¶¶¶¶¶¶¶¶
Primary Home Page:
   http://wa2hip.com

I have my JTAlert configured and would like to save a copy of my configuration to give to my daughter and son-in-law so that their config looks like mine. Is there a file that has that info? Not my database.

Also, in process explorer, it shows two of the sqlite.journal processes at times. 



Brad, N4PYI

Laurie,

I added the exclusions for all of the JT Alert folders and then disabled anti-virus altogether and restarted JT Alert. After one pass with the decodes window open, it decoded the first pass and stopped. The Sqlite.journal file stayed open and in windows explorer, the file selection was bouncing back and forth between the sqlite.journal file and the reference.sqlite file. This only started after updating to 2.16.8. It was working perfectly with 2.16.6, which is what I upgraded from to 2.16.8.

I could try to go back to 2.16.6 and see if it comes back. What is the best way to go back to a previous version?

Thanks

Brad, N4PYI

I have my JTAlert configured and would like to save a copy of my configuration to give to my daughter and son-in-law so that their config looks like mine. Is there a file that has that info? Not my database.

%localappdata%\HamApps\YOUR_CALLSIGN\config\JTAlertX\config.sqlite

de Laurie VK3AMA

I have my JTAlert configured and would like to save a copy of my configuration to give to my daughter and son-in-law so that their config looks like mine. Is there a file that has that info? Not my database.

Laurie....what do you think about doing a QRZ lookup to ensure a callsign is valid before sending out a User Alert?  

We're getting false decodes and email/text messages about the decode when a QRZ lookup would have eliminated the bad decode.

Mike W9MDB

Mike,

I am reluctant for a couple of reasons

• An online lookup would need to go into the JTAlertV2.Manager code (that is what is executing your provided script) and that is .NET Framework based with the code being a port of old JTAlertV3 code. JTAlertV3 has migrated over to .NET Core and I am no longer maintaining the Framework based code. That is, I don't really want to code this sort of JTAlertV2 specific change as it takes my focus away from the current JTAlertV3 coding effort.
  
  
• Everything known about a Callsign/decode is provided in the environment variables set by JTAlert that your script consumes. Why not extend your script to perform additional callsign validation (eg regex pattern matching) and/or an online lookup? You then become responsible for handling the complexities of the callsign validation and an online lookup and its potential failures and your script (i.e. you) then take the responsibility for a failed alerting on a needed and valid decode/callsign.
  
  

Is it the job of JTAlert to decide if the Callsign/decode is valid in this situation, it has already passed through the main JTAlert processing without being rejected? If JTAlert decides it is invalid due to a QRZ lookup failure (new DX operation not yet listed or network/server is down) and the Alert is not generated for what turns out to be a valid decode, I really don't want to wear that responsibility.

de Laurie VK3AMA

When i changed my call from NU4N to NU4N/qrp I lost the "Calling you" announcement. What can I do about that??
Thanks

--
DAVE NU4N

Check the Callsign settings under the "Alerts -> Own Call" section of the Settings. If there is a chance that people will be using the short or the long versions of your callsign when responding, set both as suitable callsigns. Callsign #1 = NU4N/QRP and Callsign #2 = NU4N

de Laurie VK3AMA

Update:

I tried deleting the decodes sqlite files in the jtalert\mycallsign\decodes directory and restarted JT Alert. Decodes window stopped populating altogether after this. I then deleted the files again and ran the install of version 2.16.8. The decodes window began populating, but again stopped at about 1,000 records. It then started populating again after several minutes. Watching the jtalert\mycallsign\decodes directory while JT Alert is decoding, you can see that when the decodes window is populating, the "decodes.sqlite-journal" file comes up, then disappears and the decodes.sqlite file grows in size. When the window is not populating, the  "decodes.sqlite-journal" file is always there and the decodes.sqlite file still grows in size. I watched this for a while and saw that when the record count got to 2,112 the window stopped populating again and the "decodes.sqlite-journal" file was always present in the folder and actively counting up and down in size.

I failed to mention previously that my operating system is Windows 10 Professional.

Has anyone else seen this in 2.16.8?

Thanks
Brad, N4PYI

Brad,

You should rarely see the "decodes.sqlite-journal" as it is automatically deleted by the sqlite database engine. AT most you should see brief glimpses of it if you have an Explorer window open.

Once you observe the "decodes.sqlite-journal" never being deleted, then the decodes database has likely lost control of the file and will no longer shown new decodes in in the Decodes window. That looks to me like PC protection software interference.

I suggest you look to adding an exclusion to your PC protect software to exclude the decodes directory.

de Laurie VK3AMA

Good evening, although I see that there are problems with the sound, I remain the same for previous versions.

I have observed in About that "JTAlertV2.Manager.exe" does not have "UDP Ports used" activated, as seen in the attached files ...

Could it be the cause? Can it be activated?

 

Cordially,

Jesus, EA1YR

Jesus,

With no "JTAlertV2.Manager" UDP port listed in the status shown by the main JTAlert Help->About window, then very likely either JTAlertV2.Manager is not running or the communications back to JTAlert,exe with the current port number was never received or blocked. With no port listed then none of the modules of the Manager will ever receive an instruction from the JTAlert.exe process and that includes playing audio.

Check Windows Task Manager (details tab) and check that JTAlertV2.Manager.exe is running. If it isn't that is the problem.  It should always be running and if the process is killed JTAlert automatically restarts it, so you should never see it not running. If JTAlertV2.Manager.exe never shows in Task Manager the likely cause is your PC protection software interring.

   

If Task Manager does show that JTAlertV2.Manager.exe is running, try a right-click on JTAlertV2.Manager.exe and use the "End Task" menu. You should observe that JTAlertV2.Manager.exe automatically reappears. Then go back and reopen the JTAlert Help->About and check is a port now listed? If no port listed after killing JTAlertV2.Manager.exe that suggests that something is blocking the  the communications between the Manager and JTAlert, very likely your PC protection software.

de Laurie VK3AMA

I was speculating that updating HRD with QSO's not currently noted from LOTW would be the means of rectifying this... just was hoping that there might be a scan option to upgrade the data rather than to replace / rebuild. 

FYI, The JTAlert "Scan Log" operation considers your Log to be the definitive source of your QSOs and that is the only source of QSO data examined during the scan. There are no attempts to examine online services (like LoTW) and NO plans to add such a mechanism, doing so would greatly increase the time to scan plus add to user confusion when QSOs don't exist in the master Log, but do on some online service resulting in perceived incorrect or no alerting of some stations.

de Laurie VK3AMA

I've recently found that new log entries no longer appear in the logbook unless I hit the refresh button.  I first noticed this three days ago when I saw three FT8 QSO's were missing from the log.

Auto-refresh of the HRDLogbook after logging via its TCP interface (as used by JTAlert) is controlled by HRD itself, there is nothing JTAlert can do to force the refresh. Either there is a setting that has changed in HRD, or you viewing the wrong log in HRDLogbook.

de Laurie VK3AMA

I have the same problem as you, but i'm using version 5 of HRD logbook.  I would like also to update automatically and refresh itself without me pressing the refresh button.  If you get an answer, I would appreciate the feedback

HRD 5 logging with JTAlert involves direct writing to the log file (there is no logging API available with the old HRD5) and that has always needed the log to be refreshed manually.

de Laurie VK3AMA

I accidentally found why JTAlert was not working right. JTDX rc151 had unchecked the "Accept UDP Requests" box. Rechecked it and JTAlert is working now.

BUT... for some reason, I am getting double logging into my HRD Logbook. It does not date the entries and does not send them to eQSL (probably because the date is missing). I have noting turned on in JTDX for logging that I am aware of. I sent you two support requests (sorry to be such a PITA and whiner).

The only thing that gets loaded from here on out is your JTAlert updates!

Fred - KK5AA

Double logging will likely be happening because HRDLogbook is set to automatically log QSOs direct from WSJTX/JTDX. You can confirm this by examining the 2 log records, one will likely have more data (from JTAlert) than the other. As to where in HRDLogbook to turn that off, I have no idea, I don't own a copy of HRD to test. Hopefully, one of the groups HRD users will chime in with the info you need.

de Laurie VK3AMA

Laurie,

I accidentally found why JTAlert was not working right. JTDX rc151 had unchecked the "Accept UDP Requests" box. Rechecked it and JTAlert is working now.

BUT... for some reason, I am getting double logging into my HRD Logbook. It does not date the entries and does not send them to eQSL (probably because the date is missing). I have noting turned on in JTDX for logging that I am aware of. I sent you two support requests (sorry to be such a PITA and whiner).

The only thing that gets loaded from here on out is your JTAlert updates!

Fred - KK5AA

No issues with latest versions of everything here...
Bill W2CQ