There is the known issue, that when the wsprd decoding program starts to decode the recorded Wav-file from wsprdaemon program it should finish it decoding after max 110sec. That is because the total wspr period is normally onty 2min = 120sec.

However when I experiment a bit with my Raspberry Pi 4b, I found in the terminal window running top, that if the wsprd decoder reaches 60sec. the decoding process is completely stopped and nothing is spotted for this 2min pediod.
I tested this with a merge of several receiver channels on only one band (40m)

As soon as I have more than 3 merged receiver channels running - the decoding is not finished with the above 60sec and nothing is uploaded/spotted

So - the timeout limit for wspr decoding is currently NOT 110sec but only 60sec according to my finding - is that really correct, or do I have something mis-configured ?!
I remember from earlier times, when wspr decoding really runs 80-100sec in busy evening times... but that doesn't work anymore - are there some changes in the todays wsprd code ?!

Having only 60sec left instead of the previous 110sec is really too short for running all my available rx-channels in merge mode, even with my fastest computer...

Is there anything wrong with my configuration ?!

Ulli, ON5KQ

Hey Ulli--

I have noticed this problem also, and posted about it back at the end of
March. You can increase the verbosity of the wsprdaemon logs with
./wsprdaemon -d and -D, and tail the wsprdaemon.log file, but it seems a
bit buggy. I never got the "v=2" option to work, shown on line 111.

My earlier email:

I've been staring at "htop" for too long, trying to track down a problem
where if wsprd runs for more than 1 minute, spots are not decoded or posted.

I'm running wsprdaemon on a Pi 2 from 40m-10m, which works fine for all
bands except 20 meters during the daytime when this problem happens. I
know I should upgrade my Pi2, but I can't seem to buy a Pi4....

Upping the verbosity levels of the logs, it appears that many things
happen 1 minute after the end of the WSPR period:

Thu Mar 31 00:49:00 UTC 2022: watchdog_daemon() is awake
Thu Mar 31 00:49:00 UTC 2022: running update_master_hashtable()
Thu Mar 31 00:49:01 UTC 2022: update_master_hashtable found no rx/band
directories
Thu Mar 31 00:49:01 UTC 2022: spawn_upload_daemons() start
Thu Mar 31 00:49:01 UTC 2022: spawn_upload_to_wsprnet_daemon() INFO:
uploading job with pid 12499 is already running
Thu Mar 31 00:49:01 UTC 2022: spawn_ftp_upload_to_wsprdaemon_daemon()
INFO: uploading job for
'/home/pi/wsprdaemon-bklofas/uploads.d/wsprdaemon.d' with pid 12502 is
already running

.......

Thu Mar 31 00:49:02 UTC 2022: check_for_zombies() Found running_pid
'12478' in expected_pids ' 12478 12499 12502 12565 12609 12699 12696'
Thu Mar 31 00:49:02 UTC 2022: check_for_zombies() Found running_pid
'12499' in expected_pids ' 12478 12499 12502 12565 12609 12699 12696'
Thu Mar 31 00:49:02 UTC 2022: check_for_zombies() Found running_pid
'12502' in expected_pids ' 12478 12499 12502 12565 12609 12699 12696'
Thu Mar 31 00:49:02 UTC 2022: check_for_zombies() Found running_pid
'12565' in expected_pids ' 12478 12499 12502 12565 12609 12699 12696'
Thu Mar 31 00:49:02 UTC 2022: check_for_zombies() Found running_pid
'12609' in expected_pids ' 12478 12499 12502 12565 12609 12699 12696'
Thu Mar 31 00:49:02 UTC 2022: check_for_zombies() Found running_pid
'12696' in expected_pids ' 12478 12499 12502 12565 12609 12699 12696'
Thu Mar 31 00:49:02 UTC 2022: check_for_zombies() Found running_pid
'12699' in expected_pids ' 12478 12499 12502 12565 12609 12699 12696'
Thu Mar 31 00:49:02 UTC 2022: check_for_zombies() WARNING: did not find
running_pid '3207' in expected_pids ' 12478 12499 12502 12565 12609
12699 12696'
pi        3207  0.0  0.0   6728   456 pts/1    S    00:48   0:00  \_
timeout 110 nice /home/pi/wsprdaemon-bklofas/bin/wsprd -c -C 500 -o 4 -d
-w -f 14.0956 220331_0046.wav
Thu Mar 31 00:49:02 UTC 2022: check_for_zombies() adding running zombie
'3207' to kill list
Thu Mar 31 00:49:02 UTC 2022: check_for_zombies() WARNING: did not find
running_pid '3208' in expected_pids ' 12478 12499 12502 12565 12609
12699 12696'
pi        3208  100  1.3  14944 13148 pts/1    RN   00:48   0:52      \_
/home/pi/wsprdaemon-bklofas/bin/wsprd -c -C 500 -o 4 -d -w -f 14.0956
220331_0046.wav
Thu Mar 31 00:49:02 UTC 2022: check_for_zombies() adding running zombie
'3208' to kill list
Thu Mar 31 00:49:02 UTC 2022: check_for_zombies() killing pids ' 3207 3208'
   PID TTY      STAT   TIME COMMAND
  3207 pts/1    S      0:00 timeout 110 nice
/home/pi/wsprdaemon-bklofas/bin/wsprd -c -C 500 -o 4 -d -w -f 14.0956
220331_0046.wav
  3208 pts/1    RN     0:52 /home/pi/wsprdaemon-bklofas/bin/wsprd -c -C
500 -o 4 -d -w -f 14.0956 220331_0046.wav


So from what I can tell, the WSPR period is 00:46 to 00:48, then wsprd
gets called at 00:48:06. So far so good. But then at 00:49:01, it tries
to upload the decoded spots for this period. But wsprd hasn't finished,
so there are no spots to upload.

Then at 00:49:02 zombies are checked for, and the running wsprd process
is found and killed.

Is my analysis of the logs correct? So even though wsprd is called with
"timeout 110" and nice, it actually needs to finish within 52 real
seconds (because wsprd gets started 6 seconds after the WSPR period
ends). Is it possible to push this 1 minute to 100 seconds or a bit longer?

I'm not sure which is the bigger issue: uploading spots before wsprd is
finished, or killing wsprd. Allowing wsprd to go for 100 seconds
wouldn't matter if the spot uploader checks at 52 seconds.

Thanks!

--
Bryan Klofas

On 4/21/22 01:18, ON5KQ wrote:
> Hi Rob,
> good morning from Belgium!
> I just upgraded from Vers 2.10l to version 3.0a
>
> A new wsprd version was uploaded and installed on the Rpi
> This new wsprd version is now running the wsprd process normally and
> doesn't stop after 60sec....
> So = Problem solved!
>
> I am now running Vers 3.0a
>
> Reading the help file of the new version with:
> ,/wsprdaemon.sh -h
>
> ... and learning of the new reporting functions....
> ./wsprdaemon.sh -l n   (for example)
>
> It is great!
> Thank you !
>

Hey Rob--

Thanks for the confirmation about the 60 seconds.

I did just switch over to WD_3.0a, it seems to be working fine for me.
Lots of spots are being uploaded, and it seems like reducing the 6200
line bash script will make it easier on everyone! Running it on a
i3-5010U is plenty fast enough, I'll try my older Pis soon.

I was initially dissuaded for trying v3.0 because the README says "The
client mode is running at AI6VN/KH6 but it isn't really ready for even
alpha testing at other sites." I guess that's not true anymore.

Thanks for keeping wsprdaemon updated, you're doing a great job!
--
Bryan Klofas KF6ZEO

On 4/21/22 09:08, Rob Robinett wrote:
> Hi Ulli and Bryan,
>
> I'm sorry that I didn't respond to Bryan's earlier email about the
> problem he identified in V2.10.  He seems to have correctly identified
> the zombie check function which runs every odd minute as the source of
> the 'terminates after 60 seconds' problem.
>
> Like much of the WD code, the zombie checking has been extensively
> revised in WD 3.0.  So for those running WD 2.10 who experience this
> problem, I would suggest trying WD 3.0
>
> Rob
>
> On Thu, Apr 21, 2022 at 8:58 AM Bryan Klofas <bklofas@...
> <mailto:bklofas@...>> wrote:
>
>     Hey Ulli--
>
>     I have noticed this problem also, and posted about it back at the
>     end of
>     March. You can increase the verbosity of the wsprdaemon logs with
>     ./wsprdaemon -d and -D, and tail the wsprdaemon.log file, but it
>     seems a
>     bit buggy. I never got the "v=2" option to work, shown on line 111.
>
>     My earlier email:
>
>     I've been staring at "htop" for too long, trying to track down a
>     problem
>     where if wsprd runs for more than 1 minute, spots are not decoded or
>     posted.
>
>     I'm running wsprdaemon on a Pi 2 from 40m-10m, which works fine for all
>     bands except 20 meters during the daytime when this problem happens. I
>     know I should upgrade my Pi2, but I can't seem to buy a Pi4....
>
>     Upping the verbosity levels of the logs, it appears that many things
>     happen 1 minute after the end of the WSPR period:
>
>     Thu Mar 31 00:49:00 UTC 2022: watchdog_daemon() is awake
>     Thu Mar 31 00:49:00 UTC 2022: running update_master_hashtable()
>     Thu Mar 31 00:49:01 UTC 2022: update_master_hashtable found no rx/band
>     directories
>     Thu Mar 31 00:49:01 UTC 2022: spawn_upload_daemons() start
>     Thu Mar 31 00:49:01 UTC 2022: spawn_upload_to_wsprnet_daemon() INFO:
>     uploading job with pid 12499 is already running
>     Thu Mar 31 00:49:01 UTC 2022: spawn_ftp_upload_to_wsprdaemon_daemon()
>     INFO: uploading job for
>     '/home/pi/wsprdaemon-bklofas/uploads.d/wsprdaemon.d' with pid 12502 is
>     already running
>
>     .......
>
>     Thu Mar 31 00:49:02 UTC 2022: check_for_zombies() Found running_pid
>     '12478' in expected_pids ' 12478 12499 12502 12565 12609 12699 12696'
>     Thu Mar 31 00:49:02 UTC 2022: check_for_zombies() Found running_pid
>     '12499' in expected_pids ' 12478 12499 12502 12565 12609 12699 12696'
>     Thu Mar 31 00:49:02 UTC 2022: check_for_zombies() Found running_pid
>     '12502' in expected_pids ' 12478 12499 12502 12565 12609 12699 12696'
>     Thu Mar 31 00:49:02 UTC 2022: check_for_zombies() Found running_pid
>     '12565' in expected_pids ' 12478 12499 12502 12565 12609 12699 12696'
>     Thu Mar 31 00:49:02 UTC 2022: check_for_zombies() Found running_pid
>     '12609' in expected_pids ' 12478 12499 12502 12565 12609 12699 12696'
>     Thu Mar 31 00:49:02 UTC 2022: check_for_zombies() Found running_pid
>     '12696' in expected_pids ' 12478 12499 12502 12565 12609 12699 12696'
>     Thu Mar 31 00:49:02 UTC 2022: check_for_zombies() Found running_pid
>     '12699' in expected_pids ' 12478 12499 12502 12565 12609 12699 12696'
>     Thu Mar 31 00:49:02 UTC 2022: check_for_zombies() WARNING: did not find
>     running_pid '3207' in expected_pids ' 12478 12499 12502 12565 12609
>     12699 12696'
>     pi        3207  0.0  0.0   6728   456 pts/1    S    00:48   0:00  \_
>     timeout 110 nice /home/pi/wsprdaemon-bklofas/bin/wsprd -c -C 500 -o
>     4 -d
>     -w -f 14.0956 220331_0046.wav
>     Thu Mar 31 00:49:02 UTC 2022: check_for_zombies() adding running zombie
>     '3207' to kill list
>     Thu Mar 31 00:49:02 UTC 2022: check_for_zombies() WARNING: did not find
>     running_pid '3208' in expected_pids ' 12478 12499 12502 12565 12609
>     12699 12696'
>     pi        3208  100  1.3  14944 13148 pts/1    RN   00:48   0:52   
>        \_
>     /home/pi/wsprdaemon-bklofas/bin/wsprd -c -C 500 -o 4 -d -w -f 14.0956
>     220331_0046.wav
>     Thu Mar 31 00:49:02 UTC 2022: check_for_zombies() adding running zombie
>     '3208' to kill list
>     Thu Mar 31 00:49:02 UTC 2022: check_for_zombies() killing pids '
>     3207 3208'
>         PID TTY      STAT   TIME COMMAND
>        3207 pts/1    S      0:00 timeout 110 nice
>     /home/pi/wsprdaemon-bklofas/bin/wsprd -c -C 500 -o 4 -d -w -f 14.0956
>     220331_0046.wav
>        3208 pts/1    RN     0:52 /home/pi/wsprdaemon-bklofas/bin/wsprd
>     -c -C
>     500 -o 4 -d -w -f 14.0956 220331_0046.wav
>
>
>     So from what I can tell, the WSPR period is 00:46 to 00:48, then wsprd
>     gets called at 00:48:06. So far so good. But then at 00:49:01, it tries
>     to upload the decoded spots for this period. But wsprd hasn't finished,
>     so there are no spots to upload.
>
>     Then at 00:49:02 zombies are checked for, and the running wsprd process
>     is found and killed.
>
>     Is my analysis of the logs correct? So even though wsprd is called with
>     "timeout 110" and nice, it actually needs to finish within 52 real
>     seconds (because wsprd gets started 6 seconds after the WSPR period
>     ends). Is it possible to push this 1 minute to 100 seconds or a bit
>     longer?
>
>     I'm not sure which is the bigger issue: uploading spots before wsprd is
>     finished, or killing wsprd. Allowing wsprd to go for 100 seconds
>     wouldn't matter if the spot uploader checks at 52 seconds.
>
>     Thanks!
>
>     --
>     Bryan Klofas
>
>     On 4/21/22 01:18, ON5KQ wrote:
>      > Hi Rob,
>      > good morning from Belgium!
>      > I just upgraded from Vers 2.10l to version 3.0a
>      >
>      > A new wsprd version was uploaded and installed on the Rpi
>      > This new wsprd version is now running the wsprd process normally and
>      > doesn't stop after 60sec....
>      > So = Problem solved!
>      >
>      > I am now running Vers 3.0a
>      >
>      > Reading the help file of the new version with:
>      > ,/wsprdaemon.sh -h
>      >
>      > ... and learning of the new reporting functions....
>      > ./wsprdaemon.sh -l n   (for example)
>      >
>      > It is great!
>      > Thank you !
>      >
>
>
>
>
>
>
>
> --
> Rob Robinett
> AI6VN
> rob@... <mailto:rob@...>
> mobile: +1 650 218 8896
>