Thanks for digging in, Ervin. I will look at that pull request. Another difference in my case is that I'm using my pywinkeyerdaemon with a K1EL (www.hamcrafters.com) 'WinKeyer USB'. https://github.com/drewarnett/pywinkeyerdaemon (One diff though, as I need to update it for the later python-serial lib; timeout is now set by attribute, not method. I also need to publish a python3 version!) Interrupting auto_cq to respond would involve sending a message to NETKEYER/cwdaemon. Maybe my implementation has a subtle, problem causing difference? I'll either examine my code versus what cwdaemon does or just install the standard cwdaemon and see if there is any difference.
I've also finished the experiment where I installed buster on the hard disk and tlf and my config files. The problem still exists. So, maybe that confirms that it is not the same problem pull 84 fixed. I will pursue my idea regarding NETKEYER/cwdaemon/pywinkeyerdaemon both by experiment and by reviewing cwdaemon and pywinkeyerdaemon source. I would be interested in hypothesis or suggestions for what I may try. Thanks and best regards, Drew kb9fko On Thu, Aug 1, 2019 at 6:38 AM Ervin Hegedüs <airw...@gmail.com> wrote: > > Hi Drew, > > On Thu, Aug 01, 2019 at 02:17:13AM +0000, Drew Arnett wrote: > > I just tried a fairly new desktop hard disk (less than a year old) > > with an older USB 2.0 to SATA adapter. I put my local working > > directory there (logcfg.dat, rules, cty, partials, log), and the same > > bad behavior persists. Will install buster to hard disk (not via USB > > adapter) and see how that behaves. > > > meanwhile I searched our discussion with Thomas, it was in > January of 2018. > > The problem was not in the mode switching, but in the > backgroud_process() - the cleanup() function called faster than > the netkeyer sent the message to keyer. > > And that bug was fixed: > > https://github.com/Tlf/tlf/pull/84 > > > After read this mail from you, I'm sure in this case the problem > is totally different, but currently I don't have any idea. > > Reflect to your apt-cache outputs: looks like this package is > what I pushed to Debian (compared the hashes), not the another > build. And the source of package is equals with the upstream reelase. > > > To any other users: could someone check this version? > > > > Let's keep in touch, > > > 73, Ervin > _______________________________________________ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
