Yesterday I used WSJT-X 1.7.0-devel on a second system, running Windows
8.1, and the same behavior as originally reported by me occurs with
version r6662 on that system as well: the UTC time value displayed in
the Band Activity window becomes "stuck" after clicking on the Fast
Graph when running ISCAT, and the UTC time displayed in the Band
Activity window will not advance from that point on unless WSJT-X is
exited and restarted. So this behavior is present with WSJT-X on both
Windows 8.1 and Windows 10, and for versions r6659, r6662, and r66l74
at least. Additional details as given in my original posting,
reproduced below, have not changed and so are not repeated.

It does not seem to me that this would be expected, desired, or normal
behavior.

73,

Roger Rehr
W3SZ

On Fri, 6 May 2016 19:48:46 -0400
Roger Rehr <[email protected]> wrote:

> Hi All,
> 
> This is a posting to provide feedback, and not a complaint (as I am
> able to read a clock and don't "need" the UTC value displayed in the
> Band Activity window although it is nice to see it there).
> 
> Under the Windows 10 OS, when using WSJT-X 1.7.0-devel version r6659
> yesterday evening, and r6674 this morning, I am finding that when
> using ISCAT [either A or B, although I was using B when I first
> noticed this] the time displayed in the UTC column in the band
> activity window becomes "stuck" at its current value and won't
> advance after I have clicked on the Fast Graph. Decoding of new
> received data still occurs, but the displayed UTC value in the Band
> Activity window does not advance.  The UTC time that is displayed in
> the main WSJT-X Clock display continues to function normally.
> 
> Stopping Monitoring and then restarting Monitoring or doing any one
> of a variety of other maneuvers will not cause the UTC value that is
> displayed in the Band Activity window to begin advancing again. I need
> to exit WSJT-X and restart it to return things to normal.
> 
> This version of WSJT-X was built using JTSDK.
> 
> I cannot say that this behavior was not present prior to r6659 and
> that I am not just noticing something that was present before but
> unnoticed by me.
> 
> This behavior may be a result of something that I am doing incorrectly
> here, or maybe it is expected behavior, but I figured at should at
> least report this because I am not certain that it is expected and
> satisfactory.
> 
> 73,
> 
> Roger Rehr
> W3SZ


------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Reply via email to