|
Team:
I am noticing that under some conditions, the date field is omitted from ALL.TXT for monitored calls, but not for transmissions I make.
What is a little more odd, this did happen when switching from 160 meter FT8 to 6 meter MSK144.
Is this a known issue?
I have just downloaded and installed the rc4 version in case the issue is resolved.
(I use the ALL.TXT file to recreate QSOs that don't get properly logged due to an xquartz crash. Usually I run WSJTX on Intel NUCs running Ubuntu after doing "ssh -Y <linux-host>" and xterm. Works most of the time, but xquartz on mac has proven to be unexpectedly crash-worthy.)
--w8lvn--
--
|
|
|
Hi Bill,
I ran into this problem when I tested some function in my Alltext.exe program that I sued for the same function.
I found that when I used WSJT-X 2.3 rc1 (or rc2). The Date and time was only included in the TX record that
was written to the All.txt file.
I believe the problem was fixed when 2.3 rc3 was released.
-----Original Message-----
From: Bill Lederer <w8lvn.9@...>
To: WSJTX@groups.io
Sent: Sun, Apr 18, 2021 9:54 pm
Subject: [WSJTX] #bugreport ALL.TXT
Team:
I am noticing that under some conditions, the date field is omitted from ALL.TXT for monitored calls, but not for transmissions I make.
What is a little more odd, this did happen when switching from 160 meter FT8 to 6 meter MSK144.
Is this a known issue?
I have just downloaded and installed the rc4 version in case the issue is resolved.
(I use the ALL.TXT file to recreate QSOs that don't get properly logged due to an xquartz crash. Usually I run WSJTX on Intel NUCs running Ubuntu after doing "ssh -Y <linux-host>" and xterm. Works most of the time, but xquartz on mac has proven to be unexpectedly crash-worthy.)
--w8lvn--
--
|
|
|
Well, my issue was in the RC3 release. I'm now running with RC4, and will see if it iis still there.
w8lvn
Hi Bill,
I ran into this problem when I tested some function in my Alltext.exe program that I sued for the same function.
I found that when I used WSJT-X 2.3 rc1 (or rc2). The Date and time was only included in the TX record that
was written to the All.txt file.
I believe the problem was fixed when 2.3 rc3 was released.
73,
-----Original Message-----
From: Bill Lederer < w8lvn.9@...>
To: WSJTX@groups.io
Sent: Sun, Apr 18, 2021 9:54 pm
Subject: [WSJTX] #bugreport ALL.TXT
Team:
I am noticing that under some conditions, the date field is omitted from ALL.TXT for monitored calls, but not for transmissions I make.
What is a little more odd, this did happen when switching from 160 meter FT8 to 6 meter MSK144.
Is this a known issue?
I have just downloaded and installed the rc4 version in case the issue is resolved.
(I use the ALL.TXT file to recreate QSOs that don't get properly logged due to an xquartz crash. Usually I run WSJTX on Intel NUCs running Ubuntu after doing "ssh -Y <linux-host>" and xterm. Works most of the time, but xquartz on mac has proven to be unexpectedly crash-worthy.)
--w8lvn--
--
|
|
|
This issue still exists for Rc4, but apparently only for MSK144.
Looks fine for FT8, but not MSK144
210419_070415 1.840 Tx FT8 0 0.0 1612 CQ W8LVN EN62
210419_070445 1.840 Tx FT8 0 0.0 1612 CQ W8LVN EN62
210419_070515 1.840 Tx FT8 0 0.0 1612 CQ W8LVN EN62
50.260 Rx MSK144 -6 7.0 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144 -5 11.3 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144 -6 9.8 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144 -5 13.7 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144 -2 1.1 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144 -1 2.5 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144 -2 0.7 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144 -7 13.3 1440 VE9GJ K2DRH RRR
50.260 Rx MSK144 -1 26.4 1475 N0AN K1RZ +02
50.260 Rx MSK144 0 23.0 1472 N0AN N1KWF FN32
50.260 Rx MSK144 -1 22.6 1460 N0AN N1KWF FN32
50.260 Rx MSK144 1 28.9 1464 N0AN N1KWF FN32
50.260 Rx MSK144 -8 28.6 1443 Z4VUR/R RH0BDY/R R DH26
50.260 Rx MSK144 8 22.6 1462 VE4CY W9DR EM78
50.260 Rx MSK144 11 22.9 1462 VE4CY W9DR EM78
50.260 Rx MSK144 12 27.0 1462 VE4CY W9DR EM78
50.260 Rx MSK144 15 27.3 1460 VE4CY W9DR EM78
50.260 Rx MSK144 13 15.5 1460 VE4CY W9DR EM78
50.260 Rx MSK144 14 26.1 1462 VE4CY W9DR EM78
50.260 Rx MSK144 3 16.0 1462 VE4CY W9DR EM78
50.260 Rx MSK144 4 16.0 1463 VE4CY W9DR EM78
50.260 Rx MSK144 6 16.6 1461 VE4CY W9DR EM78
50.260 Rx MSK144 7 16.7 1461 VE4CY W9DR EM78
50.260 Rx MSK144 13 18.4 1463 VE4CY W9DR EM78
50.260 Rx MSK144 14 18.4 1463 VE4CY W9DR EM78
50.260 Rx MSK144 -3 15.5 1463 VE4CY W9DR EM78
50.260 Rx MSK144 5 20.8 1462 VE4CY W9DR RRR
50.260 Rx MSK144 6 29.2 1462 VE4CY W9DR RRR
50.260 Rx MSK144 7 29.3 1460 VE4CY W9DR RRR
210419_140330 18.100 Rx FT8 -6 0.2 780 N5HHS N3GX R+05
210419_140330 18.100 Rx FT8 -11 0.2 1591 KB2M KI4KDR EM45
210419_140330 18.100 Rx FT8 -12 0.1 1261 CQ N3NVA FN20
210419_140400 10.136 Rx FT8 14 0.1 1328 CQ VA3MJR FN03
210419_140400 10.136 Rx FT8 1 0.1 607 KG0TR VE3RXO R-13
Thanks, w8lvn
Well, my issue was in the RC3 release. I'm now running with RC4, and will see if it iis still there.
w8lvn
Hi Bill,
I ran into this problem when I tested some function in my Alltext.exe program that I sued for the same function.
I found that when I used WSJT-X 2.3 rc1 (or rc2). The Date and time was only included in the TX record that
was written to the All.txt file.
I believe the problem was fixed when 2.3 rc3 was released.
73,
-----Original Message-----
From: Bill Lederer < w8lvn.9@...>
To: WSJTX@groups.io
Sent: Sun, Apr 18, 2021 9:54 pm
Subject: [WSJTX] #bugreport ALL.TXT
Team:
I am noticing that under some conditions, the date field is omitted from ALL.TXT for monitored calls, but not for transmissions I make.
What is a little more odd, this did happen when switching from 160 meter FT8 to 6 meter MSK144.
Is this a known issue?
I have just downloaded and installed the rc4 version in case the issue is resolved.
(I use the ALL.TXT file to recreate QSOs that don't get properly logged due to an xquartz crash. Usually I run WSJTX on Intel NUCs running Ubuntu after doing "ssh -Y <linux-host>" and xterm. Works most of the time, but xquartz on mac has proven to be unexpectedly crash-worthy.)
--w8lvn--
--
--
|
|
|
this has been this way for quite a while, I would have to look at release notes. but sounds normal. if the date does not change why append with it and slow the process..
Dave Garber VE3WEJ / VE3IE
On Mon, Apr 19, 2021 at 5:47 PM Bill Lederer < w8lvn.9@...> wrote: This issue still exists for Rc4, but apparently only for MSK144.
Looks fine for FT8, but not MSK144
210419_070415 1.840 Tx FT8 0 0.0 1612 CQ W8LVN EN62
210419_070445 1.840 Tx FT8 0 0.0 1612 CQ W8LVN EN62
210419_070515 1.840 Tx FT8 0 0.0 1612 CQ W8LVN EN62
50.260 Rx MSK144 -6 7.0 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144 -5 11.3 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144 -6 9.8 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144 -5 13.7 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144 -2 1.1 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144 -1 2.5 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144 -2 0.7 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144 -7 13.3 1440 VE9GJ K2DRH RRR
50.260 Rx MSK144 -1 26.4 1475 N0AN K1RZ +02
50.260 Rx MSK144 0 23.0 1472 N0AN N1KWF FN32
50.260 Rx MSK144 -1 22.6 1460 N0AN N1KWF FN32
50.260 Rx MSK144 1 28.9 1464 N0AN N1KWF FN32
50.260 Rx MSK144 -8 28.6 1443 Z4VUR/R RH0BDY/R R DH26
50.260 Rx MSK144 8 22.6 1462 VE4CY W9DR EM78
50.260 Rx MSK144 11 22.9 1462 VE4CY W9DR EM78
50.260 Rx MSK144 12 27.0 1462 VE4CY W9DR EM78
50.260 Rx MSK144 15 27.3 1460 VE4CY W9DR EM78
50.260 Rx MSK144 13 15.5 1460 VE4CY W9DR EM78
50.260 Rx MSK144 14 26.1 1462 VE4CY W9DR EM78
50.260 Rx MSK144 3 16.0 1462 VE4CY W9DR EM78
50.260 Rx MSK144 4 16.0 1463 VE4CY W9DR EM78
50.260 Rx MSK144 6 16.6 1461 VE4CY W9DR EM78
50.260 Rx MSK144 7 16.7 1461 VE4CY W9DR EM78
50.260 Rx MSK144 13 18.4 1463 VE4CY W9DR EM78
50.260 Rx MSK144 14 18.4 1463 VE4CY W9DR EM78
50.260 Rx MSK144 -3 15.5 1463 VE4CY W9DR EM78
50.260 Rx MSK144 5 20.8 1462 VE4CY W9DR RRR
50.260 Rx MSK144 6 29.2 1462 VE4CY W9DR RRR
50.260 Rx MSK144 7 29.3 1460 VE4CY W9DR RRR
210419_140330 18.100 Rx FT8 -6 0.2 780 N5HHS N3GX R+05
210419_140330 18.100 Rx FT8 -11 0.2 1591 KB2M KI4KDR EM45
210419_140330 18.100 Rx FT8 -12 0.1 1261 CQ N3NVA FN20
210419_140400 10.136 Rx FT8 14 0.1 1328 CQ VA3MJR FN03
210419_140400 10.136 Rx FT8 1 0.1 607 KG0TR VE3RXO R-13
Thanks, w8lvn
Well, my issue was in the RC3 release. I'm now running with RC4, and will see if it iis still there.
w8lvn
Hi Bill,
I ran into this problem when I tested some function in my Alltext.exe program that I sued for the same function.
I found that when I used WSJT-X 2.3 rc1 (or rc2). The Date and time was only included in the TX record that
was written to the All.txt file.
I believe the problem was fixed when 2.3 rc3 was released.
73,
-----Original Message-----
From: Bill Lederer < w8lvn.9@...>
To: WSJTX@groups.io
Sent: Sun, Apr 18, 2021 9:54 pm
Subject: [WSJTX] #bugreport ALL.TXT
Team:
I am noticing that under some conditions, the date field is omitted from ALL.TXT for monitored calls, but not for transmissions I make.
What is a little more odd, this did happen when switching from 160 meter FT8 to 6 meter MSK144.
Is this a known issue?
I have just downloaded and installed the rc4 version in case the issue is resolved.
(I use the ALL.TXT file to recreate QSOs that don't get properly logged due to an xquartz crash. Usually I run WSJTX on Intel NUCs running Ubuntu after doing "ssh -Y <linux-host>" and xterm. Works most of the time, but xquartz on mac has proven to be unexpectedly crash-worthy.)
--w8lvn--
--
--
--
|
|
|
I has not been this way for a long time. It was a bug that was corrected but seems to be still in the version that bill is using.
I was running the Windows version and it was corrected in a later RC release.
If appending the date and time slows the process on your PC, then you have a problem with your hardware.
-----Original Message-----
From: Dave Garber <ve3wej@...>
To: WSJT-x group <main@wsjtx.groups.io>
Sent: Mon, Apr 19, 2021 7:17 pm
Subject: Re: [WSJTX] #bugreport ALL.TXT
this has been this way for quite a while, I would have to look at release notes. but sounds normal. if the date does not change why append with it and slow the process..
Dave Garber
VE3WEJ / VE3IE
On Mon, Apr 19, 2021 at 5:47 PM Bill Lederer < w8lvn.9@...> wrote:
This issue still exists for Rc4, but apparently only for MSK144.
Looks fine for FT8, but not MSK144
210419_070415 1.840 Tx FT8 0 0.0 1612 CQ W8LVN EN62
210419_070445 1.840 Tx FT8 0 0.0 1612 CQ W8LVN EN62
210419_070515 1.840 Tx FT8 0 0.0 1612 CQ W8LVN EN62
50.260 Rx MSK144 -6 7.0 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144 -5 11.3 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144 -6 9.8 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144 -5 13.7 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144 -2 1.1 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144 -1 2.5 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144 -2 0.7 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144 -7 13.3 1440 VE9GJ K2DRH RRR
50.260 Rx MSK144 -1 26.4 1475 N0AN K1RZ +02
50.260 Rx MSK144 0 23.0 1472 N0AN N1KWF FN32
50.260 Rx MSK144 -1 22.6 1460 N0AN N1KWF FN32
50.260 Rx MSK144 1 28.9 1464 N0AN N1KWF FN32
50.260 Rx MSK144 -8 28.6 1443 Z4VUR/R RH0BDY/R R DH26
50.260 Rx MSK144 8 22.6 1462 VE4CY W9DR EM78
50.260 Rx MSK144 11 22.9 1462 VE4CY W9DR EM78
50.260 Rx MSK144 12 27.0 1462 VE4CY W9DR EM78
50.260 Rx MSK144 15 27.3 1460 VE4CY W9DR EM78
50.260 Rx MSK144 13 15.5 1460 VE4CY W9DR EM78
50.260 Rx MSK144 14 26.1 1462 VE4CY W9DR EM78
50.260 Rx MSK144 3 16.0 1462 VE4CY W9DR EM78
50.260 Rx MSK144 4 16.0 1463 VE4CY W9DR EM78
50.260 Rx MSK144 6 16.6 1461 VE4CY W9DR EM78
50.260 Rx MSK144 7 16.7 1461 VE4CY W9DR EM78
50.260 Rx MSK144 13 18.4 1463 VE4CY W9DR EM78
50.260 Rx MSK144 14 18.4 1463 VE4CY W9DR EM78
50.260 Rx MSK144 -3 15.5 1463 VE4CY W9DR EM78
50.260 Rx MSK144 5 20.8 1462 VE4CY W9DR RRR
50.260 Rx MSK144 6 29.2 1462 VE4CY W9DR RRR
50.260 Rx MSK144 7 29.3 1460 VE4CY W9DR RRR
210419_140330 18.100 Rx FT8 -6 0.2 780 N5HHS N3GX R+05
210419_140330 18.100 Rx FT8 -11 0.2 1591 KB2M KI4KDR EM45
210419_140330 18.100 Rx FT8 -12 0.1 1261 CQ N3NVA FN20
210419_140400 10.136 Rx FT8 14 0.1 1328 CQ VA3MJR FN03
210419_140400 10.136 Rx FT8 1 0.1 607 KG0TR VE3RXO R-13
Thanks,
w8lvn
Well, my issue was in the RC3 release. I'm now running with RC4, and will see if it iis still there.
w8lvn
Hi Bill,
I ran into this problem when I tested some function in my Alltext.exe program that I sued for the same function.
I found that when I used WSJT-X 2.3 rc1 (or rc2). The Date and time was only included in the TX record that
was written to the All.txt file.
I believe the problem was fixed when 2.3 rc3 was released.
73,
-----Original Message-----
From: Bill Lederer < w8lvn.9@...>
To: WSJTX@groups.io
Sent: Sun, Apr 18, 2021 9:54 pm
Subject: [WSJTX] #bugreport ALL.TXT
Team:
I am noticing that under some conditions, the date field is omitted from ALL.TXT for monitored calls, but not for transmissions I make.
What is a little more odd, this did happen when switching from 160 meter FT8 to 6 meter MSK144.
Is this a known issue?
I have just downloaded and installed the rc4 version in case the issue is resolved.
(I use the ALL.TXT file to recreate QSOs that don't get properly logged due to an xquartz crash. Usually I run WSJTX on Intel NUCs running Ubuntu after doing "ssh -Y <linux-host>" and xterm. Works most of the time, but xquartz on mac has proven to be unexpectedly crash-worthy.)
--w8lvn--
--
--
--
|
|
|
So if adding the date to the beginning of a log file takes more than a handful of microseconds, I would be surprised. The bulk of time would be actually taking the underlying unix time (in seconds) and converting it to a string. This is already done for the display of the signal on the left panel.
Secondly, the date is not changing on either the 1.840 lines, nor on the 18.100 or the 10.136 FT8 lines, but the time is put on those lines. Clearly the time changes, however.
Further, for the MSK144 lines, they occupy the clock time between 210419_140330 and 240419_070515, which is on the order of 7 hours. At what time does the line Z4VUR/R RH0BDY/R R DH26 occur? There is no way to tell from ALL.TXT.
Finally, why would it behave differently on FT8 as opposed to MSK144?
With respect to the release notes, for RC3 it says:
- Repair regression with missing time-stamps in the ALL.TXT journal.
It would appear from my RC3 use and now RC4, that there are situations still exhibiting the behavior.
I am thinking this is a bug.
On Mon, Apr 19, 2021 at 6:18 PM Dave Garber < ve3wej@...> wrote: this has been this way for quite a while, I would have to look at release notes. but sounds normal. if the date does not change why append with it and slow the process..
Dave Garber VE3WEJ / VE3IE
On Mon, Apr 19, 2021 at 5:47 PM Bill Lederer < w8lvn.9@...> wrote: This issue still exists for Rc4, but apparently only for MSK144.
Looks fine for FT8, but not MSK144
210419_070415 1.840 Tx FT8 0 0.0 1612 CQ W8LVN EN62
210419_070445 1.840 Tx FT8 0 0.0 1612 CQ W8LVN EN62
210419_070515 1.840 Tx FT8 0 0.0 1612 CQ W8LVN EN62
50.260 Rx MSK144 -6 7.0 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144 -5 11.3 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144 -6 9.8 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144 -5 13.7 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144 -2 1.1 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144 -1 2.5 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144 -2 0.7 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144 -7 13.3 1440 VE9GJ K2DRH RRR
50.260 Rx MSK144 -1 26.4 1475 N0AN K1RZ +02
50.260 Rx MSK144 0 23.0 1472 N0AN N1KWF FN32
50.260 Rx MSK144 -1 22.6 1460 N0AN N1KWF FN32
50.260 Rx MSK144 1 28.9 1464 N0AN N1KWF FN32
50.260 Rx MSK144 -8 28.6 1443 Z4VUR/R RH0BDY/R R DH26
50.260 Rx MSK144 8 22.6 1462 VE4CY W9DR EM78
50.260 Rx MSK144 11 22.9 1462 VE4CY W9DR EM78
50.260 Rx MSK144 12 27.0 1462 VE4CY W9DR EM78
50.260 Rx MSK144 15 27.3 1460 VE4CY W9DR EM78
50.260 Rx MSK144 13 15.5 1460 VE4CY W9DR EM78
50.260 Rx MSK144 14 26.1 1462 VE4CY W9DR EM78
50.260 Rx MSK144 3 16.0 1462 VE4CY W9DR EM78
50.260 Rx MSK144 4 16.0 1463 VE4CY W9DR EM78
50.260 Rx MSK144 6 16.6 1461 VE4CY W9DR EM78
50.260 Rx MSK144 7 16.7 1461 VE4CY W9DR EM78
50.260 Rx MSK144 13 18.4 1463 VE4CY W9DR EM78
50.260 Rx MSK144 14 18.4 1463 VE4CY W9DR EM78
50.260 Rx MSK144 -3 15.5 1463 VE4CY W9DR EM78
50.260 Rx MSK144 5 20.8 1462 VE4CY W9DR RRR
50.260 Rx MSK144 6 29.2 1462 VE4CY W9DR RRR
50.260 Rx MSK144 7 29.3 1460 VE4CY W9DR RRR
210419_140330 18.100 Rx FT8 -6 0.2 780 N5HHS N3GX R+05
210419_140330 18.100 Rx FT8 -11 0.2 1591 KB2M KI4KDR EM45
210419_140330 18.100 Rx FT8 -12 0.1 1261 CQ N3NVA FN20
210419_140400 10.136 Rx FT8 14 0.1 1328 CQ VA3MJR FN03
210419_140400 10.136 Rx FT8 1 0.1 607 KG0TR VE3RXO R-13
Thanks, w8lvn
Well, my issue was in the RC3 release. I'm now running with RC4, and will see if it iis still there.
w8lvn
Hi Bill,
I ran into this problem when I tested some function in my Alltext.exe program that I sued for the same function.
I found that when I used WSJT-X 2.3 rc1 (or rc2). The Date and time was only included in the TX record that
was written to the All.txt file.
I believe the problem was fixed when 2.3 rc3 was released.
73,
-----Original Message-----
From: Bill Lederer < w8lvn.9@...>
To: WSJTX@groups.io
Sent: Sun, Apr 18, 2021 9:54 pm
Subject: [WSJTX] #bugreport ALL.TXT
Team:
I am noticing that under some conditions, the date field is omitted from ALL.TXT for monitored calls, but not for transmissions I make.
What is a little more odd, this did happen when switching from 160 meter FT8 to 6 meter MSK144.
Is this a known issue?
I have just downloaded and installed the rc4 version in case the issue is resolved.
(I use the ALL.TXT file to recreate QSOs that don't get properly logged due to an xquartz crash. Usually I run WSJTX on Intel NUCs running Ubuntu after doing "ssh -Y <linux-host>" and xterm. Works most of the time, but xquartz on mac has proven to be unexpectedly crash-worthy.)
--w8lvn--
--
--
--
|
|
|
Hi Bill,
Yes, it is a bug. I would suggest you test the RC release of ver 2.4 and see if it is in there as well.
I had to make special provisions in my Alltext.exe program to accommodate that bug.
73,
-----Original Message-----
From: Bill Lederer <w8lvn.9@...>
To: main@wsjtx.groups.io
Sent: Mon, Apr 19, 2021 8:11 pm
Subject: Re: [WSJTX] #bugreport ALL.TXT
So if adding the date to the beginning of a log file takes more than a handful of microseconds, I would be surprised. The bulk of time would be actually taking the underlying unix time (in seconds) and converting it to a string. This is already done for the display of the signal on the left panel.
Secondly, the date is not changing on either the 1.840 lines, nor on the 18.100 or the 10.136 FT8 lines, but the time is put on those lines. Clearly the time changes, however.
Further, for the MSK144 lines, they occupy the clock time between 210419_140330 and 240419_070515, which is on the order of 7 hours. At what time does the line Z4VUR/R RH0BDY/R R DH26 occur? There is no way to tell from ALL.TXT.
Finally, why would it behave differently on FT8 as opposed to MSK144?
With respect to the release notes, for RC3 it says:
- Repair regression with missing time-stamps in the ALL.TXT journal.
It would appear from my RC3 use and now RC4, that there are situations still exhibiting the behavior.
I am thinking this is a bug.
On Mon, Apr 19, 2021 at 6:18 PM Dave Garber < ve3wej@...> wrote:
this has been this way for quite a while, I would have to look at release notes. but sounds normal. if the date does not change why append with it and slow the process..
Dave Garber
VE3WEJ / VE3IE
On Mon, Apr 19, 2021 at 5:47 PM Bill Lederer < w8lvn.9@...> wrote:
This issue still exists for Rc4, but apparently only for MSK144.
Looks fine for FT8, but not MSK144
210419_070415 1.840 Tx FT8 0 0.0 1612 CQ W8LVN EN62
210419_070445 1.840 Tx FT8 0 0.0 1612 CQ W8LVN EN62
210419_070515 1.840 Tx FT8 0 0.0 1612 CQ W8LVN EN62
50.260 Rx MSK144 -6 7.0 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144 -5 11.3 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144 -6 9.8 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144 -5 13.7 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144 -2 1.1 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144 -1 2.5 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144 -2 0.7 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144 -7 13.3 1440 VE9GJ K2DRH RRR
50.260 Rx MSK144 -1 26.4 1475 N0AN K1RZ +02
50.260 Rx MSK144 0 23.0 1472 N0AN N1KWF FN32
50.260 Rx MSK144 -1 22.6 1460 N0AN N1KWF FN32
50.260 Rx MSK144 1 28.9 1464 N0AN N1KWF FN32
50.260 Rx MSK144 -8 28.6 1443 Z4VUR/R RH0BDY/R R DH26
50.260 Rx MSK144 8 22.6 1462 VE4CY W9DR EM78
50.260 Rx MSK144 11 22.9 1462 VE4CY W9DR EM78
50.260 Rx MSK144 12 27.0 1462 VE4CY W9DR EM78
50.260 Rx MSK144 15 27.3 1460 VE4CY W9DR EM78
50.260 Rx MSK144 13 15.5 1460 VE4CY W9DR EM78
50.260 Rx MSK144 14 26.1 1462 VE4CY W9DR EM78
50.260 Rx MSK144 3 16.0 1462 VE4CY W9DR EM78
50.260 Rx MSK144 4 16.0 1463 VE4CY W9DR EM78
50.260 Rx MSK144 6 16.6 1461 VE4CY W9DR EM78
50.260 Rx MSK144 7 16.7 1461 VE4CY W9DR EM78
50.260 Rx MSK144 13 18.4 1463 VE4CY W9DR EM78
50.260 Rx MSK144 14 18.4 1463 VE4CY W9DR EM78
50.260 Rx MSK144 -3 15.5 1463 VE4CY W9DR EM78
50.260 Rx MSK144 5 20.8 1462 VE4CY W9DR RRR
50.260 Rx MSK144 6 29.2 1462 VE4CY W9DR RRR
50.260 Rx MSK144 7 29.3 1460 VE4CY W9DR RRR
210419_140330 18.100 Rx FT8 -6 0.2 780 N5HHS N3GX R+05
210419_140330 18.100 Rx FT8 -11 0.2 1591 KB2M KI4KDR EM45
210419_140330 18.100 Rx FT8 -12 0.1 1261 CQ N3NVA FN20
210419_140400 10.136 Rx FT8 14 0.1 1328 CQ VA3MJR FN03
210419_140400 10.136 Rx FT8 1 0.1 607 KG0TR VE3RXO R-13
Thanks,
w8lvn
Well, my issue was in the RC3 release. I'm now running with RC4, and will see if it iis still there.
w8lvn
Hi Bill,
I ran into this problem when I tested some function in my Alltext.exe program that I sued for the same function.
I found that when I used WSJT-X 2.3 rc1 (or rc2). The Date and time was only included in the TX record that
was written to the All.txt file.
I believe the problem was fixed when 2.3 rc3 was released.
73,
-----Original Message-----
From: Bill Lederer < w8lvn.9@...>
To: WSJTX@groups.io
Sent: Sun, Apr 18, 2021 9:54 pm
Subject: [WSJTX] #bugreport ALL.TXT
Team:
I am noticing that under some conditions, the date field is omitted from ALL.TXT for monitored calls, but not for transmissions I make.
What is a little more odd, this did happen when switching from 160 meter FT8 to 6 meter MSK144.
Is this a known issue?
I have just downloaded and installed the rc4 version in case the issue is resolved.
(I use the ALL.TXT file to recreate QSOs that don't get properly logged due to an xquartz crash. Usually I run WSJTX on Intel NUCs running Ubuntu after doing "ssh -Y <linux-host>" and xterm. Works most of the time, but xquartz on mac has proven to be unexpectedly crash-worthy.)
--w8lvn--
--
--
--
--
|
|
|
Dave sorry disagree
If you ‘filter’ all.txt to get all MSK entries - to see what was sent etc - no date there.
Your argument assumes there will be details ON THE SAME day before/after the MSK entries to allow you to find the date - what is to say the details before (or after) are for the same day.
The log file should show the date/time for each entry.
Tom
GM8MJV
toggle quoted messageShow quoted text
On 20 Apr 2021, at 00:17, Dave Garber <ve3wej@...> wrote:
this has been this way for quite a while, I would have to look at release notes. but sounds normal. if the date does not change why append with it and slow the process..
Dave Garber
VE3WEJ / VE3IE
On Mon, Apr 19, 2021 at 5:47 PM Bill Lederer <w8lvn.9@...> wrote:
This issue still exists for Rc4, but apparently only for MSK144.
Looks fine for FT8, but not MSK144
210419_070415 1.840 Tx FT8 0 0.0 1612 CQ W8LVN EN62
210419_070445 1.840 Tx FT8 0 0.0 1612 CQ W8LVN EN62
210419_070515 1.840 Tx FT8 0 0.0 1612 CQ W8LVN EN62
50.260 Rx MSK144 -6 7.0 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144 -5 11.3 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144 -6 9.8 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144 -5 13.7 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144 -2 1.1 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144 -1 2.5 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144 -2 0.7 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144 -7 13.3 1440 VE9GJ K2DRH RRR
50.260 Rx MSK144 -1 26.4 1475 N0AN K1RZ +02
50.260 Rx MSK144 0 23.0 1472 N0AN N1KWF FN32
50.260 Rx MSK144 -1 22.6 1460 N0AN N1KWF FN32
50.260 Rx MSK144 1 28.9 1464 N0AN N1KWF FN32
50.260 Rx MSK144 -8 28.6 1443 Z4VUR/R RH0BDY/R R DH26
50.260 Rx MSK144 8 22.6 1462 VE4CY W9DR EM78
50.260 Rx MSK144 11 22.9 1462 VE4CY W9DR EM78
50.260 Rx MSK144 12 27.0 1462 VE4CY W9DR EM78
50.260 Rx MSK144 15 27.3 1460 VE4CY W9DR EM78
50.260 Rx MSK144 13 15.5 1460 VE4CY W9DR EM78
50.260 Rx MSK144 14 26.1 1462 VE4CY W9DR EM78
50.260 Rx MSK144 3 16.0 1462 VE4CY W9DR EM78
50.260 Rx MSK144 4 16.0 1463 VE4CY W9DR EM78
50.260 Rx MSK144 6 16.6 1461 VE4CY W9DR EM78
50.260 Rx MSK144 7 16.7 1461 VE4CY W9DR EM78
50.260 Rx MSK144 13 18.4 1463 VE4CY W9DR EM78
50.260 Rx MSK144 14 18.4 1463 VE4CY W9DR EM78
50.260 Rx MSK144 -3 15.5 1463 VE4CY W9DR EM78
50.260 Rx MSK144 5 20.8 1462 VE4CY W9DR RRR
50.260 Rx MSK144 6 29.2 1462 VE4CY W9DR RRR
50.260 Rx MSK144 7 29.3 1460 VE4CY W9DR RRR
210419_140330 18.100 Rx FT8 -6 0.2 780 N5HHS N3GX R+05
210419_140330 18.100 Rx FT8 -11 0.2 1591 KB2M KI4KDR EM45
210419_140330 18.100 Rx FT8 -12 0.1 1261 CQ N3NVA FN20
210419_140400 10.136 Rx FT8 14 0.1 1328 CQ VA3MJR FN03
210419_140400 10.136 Rx FT8 1 0.1 607 KG0TR VE3RXO R-13
Thanks,
w8lvn
On Mon, Apr 19, 2021 at 10:59 AM Bill Lederer via groups.io<w8lvn.9@...> wrote:
Well, my issue was in the RC3 release. I'm now running with RC4, and will see if it iis still there.
w8lvn
On Mon, Apr 19, 2021 at 6:41 AM Sam Birnbaum via groups.io<w2jdb@...> wrote:
Hi Bill,
I ran into this problem when I tested some function in my Alltext.exe program that I sued for the same function.
I found that when I used WSJT-X 2.3 rc1 (or rc2). The Date and time was only included in the TX record that
was written to the All.txt file.
I believe the problem was fixed when 2.3 rc3 was released.
73,
Sam W2JDB
-----Original Message-----
From: Bill Lederer <w8lvn.9@...>
To: WSJTX@groups.io
Sent: Sun, Apr 18, 2021 9:54 pm
Subject: [WSJTX] #bugreport ALL.TXT
Team:
I am noticing that under some conditions, the date field is omitted from ALL.TXT for monitored calls, but not for transmissions I make.
What is a little more odd, this did happen when switching from 160 meter FT8 to 6 meter MSK144.
Is this a known issue?
I have just downloaded and installed the rc4 version in case the issue is resolved.
(I use the ALL.TXT file to recreate QSOs that don't get properly logged due to an xquartz crash. Usually I run WSJTX on Intel NUCs running Ubuntu after doing "ssh -Y <linux-host>" and xterm. Works most of the time, but xquartz on mac has proven to be unexpectedly crash-worthy.)
--w8lvn--
--
--w8lvn--
--
--w8lvn--
--
--w8lvn--
|
|
|
