Laurie,

 

I embarked on installing this version with some trepidation after all these reports of no sound/sound loss.

 

It installed without a hitch, but no sound… then I got the warning panel and set the sound device to the Realtek device, still no joy, then picked a couple of other devices and went back to RealTek… still no joy. Restarted JTAlert and THEN noticed that I had never turned on the sound.

 

After turning on the sound… it worked.

 

Machine is a Dell i7 based desktop with more than enough memory and storage running the most current update drop of Win10 64 bit. What is the problem now? I just turned on my sound… (I never really used it before anyway).

 

Oh Well, <headsmack, facepalm>

 

KD4IZ

Jack Spitznagel

FM19oo

I've received the error below with version 2.15.3 and with version 2.15.4. I've tried uninstalling and reinstalling. Does anyone have any other suggestions?

After upgrading to 2.15.4, I noticed that there is much delay from when WSJT-X "prints" calls to when JTAlert prints calls in the display slots/lines.  No other windows running on JTAlert (no decodes history, callsign history, band activity windows).  It's not until about second 5 or 6 or 7 into the cycle (FT8) when JTAlert starts printing calls from the prior sequence.

I reverted back to 2.15.0 and it printed calls starting at second 2.
Re-loaded 2.15.4 and it's back to 5 or 6 seconds.

73,
Chad WE9V

I just updated to Version 2.15.4, where you fixed my issue of:

    - Mode not written to the B4Log.mdb file when logging is disabled.

Made a contact this morning, and your software properly captured and identified the station as a Worked B4 entity.

Again, thank you so very much for all your effort on this excellent software tool, and being so responsive to the users.

73,

Jan Blair
WA8RZR

Jan,

Thanks for confirming the fix.

I suggest you create a new B4Log.mdb file then perform an import of an ADIF export from your primary logger. This will correct the previously recorded entries with the missing mode.

de Laurie VK3AMA

Installed the new 2.15.4 version – sound stopped working. Reverted back to 2.15.3 – works perfectly.

 

I use the onboard Realtek sound card for my alerts/system sounds etc – it is the Windows Default sound card, but is selected by name in JTAlert.

 

Before reverting back I tried restarting the PC, to no avail. Running Windows 10 64 Bit (1909 update), 16Gb RAM, JTDX 2.1.0-rc144 and logging to DXKeeper.

 

73 de BARRY MURRELL ZS2EZ

Barry,

Please try the following after installing 2.15.4

1. Stop JTAlert if it is running.
   
2. Use Windows File Explorer, go to the %localappdata%\HamApps\cache directory and delete the AudioDevices.txt file in that directory
3. Start JTAlert
4. Under the Sound Menu select your Realtek device, the name may be truncated to 32 characters as with previous versions of JTAlert, that is ok.
5. Use the Test menu.
6. If the test sound does not play, select another device then reselect the Realtek and repeat the test.

If the above doesn't get you working, then rollback to 2.15.3 until I am able to reproduce the defect and code a fix.

Let me know how you get on.

de   

That did not work here .. Tnx  Dwight   Back to .3
--
73
Ron, W3RJW

Laurie, - follow-up to this reported issue

I just updated to Version 2.15.4, where you fixed my issue of:

    - Mode not written to the B4Log.mdb file when logging is disabled.

Made a contact this morning, and your software properly captured and identified the station as a Worked B4 entity.

Again, thank you so very much for all your effort on this excellent software tool, and being so responsive to the users.

73,

Jan Blair
WA8RZR

 

Try going into settings-soundcard and click on a couple of sound cards there, even if Realtek is already checked, ending up with the Realtek.

Started working fine after that.

73 Dwight NS9I

Same problem here  Windows default also happens to be Realtek ... 

Went back to 2.15.3 and selected either Windows default or the Realtek and they both work.  Realtek does not work in 2.15.4


Win 8.1
--
73
Ron, W3RJW

Laurie,
At the present time I do not use FT4, I of course use FT8 and that is where the problem is.
TNX
Neil   N4FN

The Latest JTAlert version 2.15.4 is now available @ https://hamapps.com/JTAlert/

This release has a critical fix for "NO Log" users.

Please review the Release notes at the end of this message.

de Laurie VK3AMA

The Release Notes...

2.15.4 (04-DEC-2019)

  *** Includes Callsign database file version 2019-12-02 (2019-December-02)

  Changes:

    - The Windows Default Sound Device is NO longer supported as one of the
       selected audio devices. A specific named device must be set.
       JTAlert will now present a dialog to change the device whenever it
       encounters (at startup) the last used named device is no longer found
       or was never set (ie was using the Windows default).

    - JTAlert no longer uses fixed UDP ports for inter-process communications
       between JTAlert.exe and JTAlertV2.Manager.exe. Ports are now assigned
       by the Windows OS from free ports in the range 49152 to 65535.

  Fixes:

    - Mode not written to the B4Log.mdb file when logging is disabled.

de Laurie VK3AMA

Hi Mike and Laurie,
No, I had not done a "Scan Log and Rebuild" I will. And Laurie, Yes I see one or two as worked "B4". I use Ham Radio Deluxe...latest version, and have for many years.
Neil   N4FN

Neil,

A scan Log & rebuild will NOT resolve any B4 issues your having, it only affects the internal lists used by the Wanted Alerts.

If your seeing some B4s on the Band and not a total absence of B4s suggests the likely cause is within your Log file and JTAlert is not finding suitable entries when it does a B4 check.

Are the missing B4s for previously logged FT4 QSOs? If so you will likely find that HRDLogbook has them recorded as MFSK without a submode (the HRD Log schema doesn't have a SUBMODE column).

If an incorrect logged mode is not the answer, send me a copy of your HRD log file for analysis (only if it is an MSAccess type). Don't send the log via the group, send it to me direct.

Let me know what you find.

de Laurie VK3AMA

Thinking about the problem.....I used Revo Uninstall to remove an Acom program.  I think in the list of 

"leftovers" was an important file for JTAlert.  It wasn't listed as such or I would have removed it before 

deleting the other files. Any idea what I did wrong?  

To answer your question, JTAlert 2.14.5 and WSJT 2.1.2 worked perfectly.

Revo removing needed JTAlert files would not cause JTAlert to stop receiving UDP data from WSJT-X, if anything it would produce a critical error dialog from JTAlert which would subsequently close. A rerunning of the JTAlert installer will restore any lost files/directories.

There have not been any recent changes in how JTAlert receives WSJT-X UDP traffic, internally 2.15.3 is exactly the same as 2.14.5.

The most likely cause is another application having exclusive access to the WSJT-X UDP port (2237) or WSJT-X is running with elevated privileges (set to run as administrator). There is never any need to run WSJT-X elevated.

If you haven't done so already, perform a PC restart, especially if your running Win10 as that is now the most common fix for unexpected or changed behavior.

If you still have no success, use the "Help" (or "? ") -> "Contact Support" menu, on the main JTAlert window, to send me your JTAlert files for analysis.

de Laurie VK3AMA