Hi Jakob,
Welcome to this list, and thanks for your suggestion and patch.
We will certainly put an appropriate fix for the uninitialized value of
'wisfile' (when jt9[.exe] is called without arguments) into the source
code before the next release of WSJT-X.
-- 73, Joe, K1JT
On 7/26/2020 8:41 AM, Jakob Ketterl DD5JFK wrote:
Good day everybody,
since I'm new to the list, just a quick introduction: My name is Jakob,
I have been developing the OpenWebRX project for about a year now, and
have included a bunch of new features, among them decoding of most
WSJT-X modes.
For this purpose, I have been including the jt9 / wsprd command line
decoders, feeding them with wave files, which is working great.
Another feature is the ability to automatically run decoders in the
background, either following the users' frequency choice, or
automatically tuning to selected frequencies when idle. This also works
fine and allows feeding back received data into spotting networks
(currently only pskreporter, but that's a different story).
It has been brought to my attention that certain systems will generate
large amounts of stale files in their temporary directories. (see:
https://github.com/jketterl/openwebrx/issues/130)
Debugging has shown that there are multiple sources of such files, with
the "jt9" command line decoder being one of them, which is why I am
writing to this list today.
On some setups, the jt9 decoder, when called without arguments, will
leave behind exactly one file containing fftw wisdom data in the cwd.
The filename seems to be garbled, randomly composed of many special or
unprintable characters, certainly not human-readable. OpenWebRX calls
"jt9" without any arguments simply to detect if the decoder is
installed, and the corresponding modes should be enabled.
The "wsprd" tool does not seem to be affected by this, but I have found
the same problem to be present in JS8Call, which is not surprising after
having looked at the code. (I am aware that JS8Call is a different
project, but I'm hoping that by addressing this issue here, a potential
fix would propagate there eventually.)
Now, unfortunately, I don't have any experience in Fortran, but I did
have a look at the source (version 2.2.2 for line number reference), and
this seems to be a very simple issue of an uninitialized variable.
Looking at "lib/jt9.f90", I can see that the variable "wisfile" is
declared in line 22 and receives its value in line 168. However, the
code jumps to "999" when the usage instructions have been output (no
arguments on the commandline), which is in line 334. The variable is
then used in line 343, with the only assignment having been skipped.
Given the simple nature of the problem, I did give it a try and came up
with a minimal fix for it, see the provided attachment. Once again, I
don't have any Fortran experience, so I guess that'll be about as much
as I can do right now. I have been able to compile and run it, and I can
at least report that it fixes the issue for me.
I'd be very happy if this patch was considered, or if the underlying
problem could be mended in another way.
73s
Jakob DD5JFK
P.S. I previously attempted to send this message to the list, but it got
caught up in moderation because I was using the wrong sender address. I
have canceled the previous message, but if there's still any duplicate
showing up somewhere, I apologize.
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
