Re: [Tlf-devel] TLF run mode problem

[Drew Arnett]

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.

Thanks and best regards,

Drew
kb9fko

On Thu, Aug 1, 2019 at 1:26 AM Drew Arnett <address@hidden> wrote:
>
> I just subscribed to the tlf-devel list, so I should get those emails
> in my mailbox now.  (I was using the archive web page.)
>
> I will respond to Ervin and Tom's emails.  Tom's first.
>
> Yes, your assumption is correct.  I am using CW.  NETKEYER works great!
>
> Yes, the bad behavior is reproducible.
>
> I tried CQWW (see below), but maybe if someone can provide config
> files, I can try that.
>
> Now, Ervin's.
>
> Yes, I'm running with live on RAMDISK which should be faster than SSD.
> I can install buster on a rotating disk drive and try that out to see
> if it makes a difference.  What specifically is being accessed on disk
> that might cause a race condition?  If it is something in the working
> directory where I have my config files and log file, I could get that
> onto a rotating disk drive without spending as much time and try that.
> But, if it is say /tmp or the file system with the binary or
> libraries, then I'll have to do the OS install.  I will try both and
> let you know.  And, when I used TLF late last winter, I may have been
> running off of a rotating hard disk, but I don't remember for sure.
>
> To try CQWW, I modified the files I provided earlier in this way:
> -----
> cp -R iaru2019 blah
> vi blah/rules/iaru
> diff --recursive blah/rules/iaru iaru2019/rules/iaru
> 1,2c1,2
> < CONTEST=cqww
> < LOGFILE=cqwwlog.txt
> ---
> > CONTEST=iaru
> > LOGFILE=iarulog.txt
> -----
> and have the same problem behavior unfortunately.  Do you have config
> files that I could try?
>
> I also reproduced Ervin's use of a dummy rig.  I used 'rigctld -m 1'
> to provide a rigctl daemon serving a dummy rig.  I used used 'rigctl
> -m 2' and 'F 14002000' and exited that client to set the VFO on the
> dummy rig.  I then modified logcfg.dat to change RIGMODEL=2 and
> RIGPORT=localhost.  When I started tlf, it connected to the dummy rig
> as evidenced by the different VFO value.  Unfortunately, still the
> same bad behavior.
>
> More details on the package installed per your request:
> -----
> user@debian:~$ apt-cache show tlf
> Package: tlf
> Version: 1.3.2-1
> Installed-Size: 945
> Maintainer: Debian Hamradio Maintainers <address@hidden>
> Architecture: amd64
> Depends: libc6 (>= 2.15), libglib2.0-0 (>= 2.35.9), libhamlib2,
> libncursesw6 (>= 6), libtinfo6 (>= 6), libxmlrpc-core-c3
> Recommends: sox, xplanet
> Description-en: console based ham radio contest logger
>  Tlf is a console (ncurses) mode general purpose CW/VOICE keyer, logging and
>  contest program for hamradio.
>  It supports the CQWW, the WPX, the ARRL-DX , the ARRL-FD, the PACC and the
>  EU SPRINT contests (single operator) as well as a LOT MORE basic contests,
>  general QSO and DXpedition mode.
>  It interfaces with a morse code generator, your sound card, a number of 
> radios,
>  and with a DX Cluster.
>  Tlf can project cluster data into the excellent Xplanet program, written by
>  Hari Nair.
>  Contest operation mimics the popular TR-Log program for DOS, the output file
>  is TR- as well as CABRILLO compatible. The user interface was designed with
>  over 30 years of experience in CW contesting.
>  The program was written for console mode on purpose, to make it run also on
>  smaller machines, or remotely via a modem link.
>  This version of Tlf supports the new native Fldigi interface for digital 
> modes.
> Description-md5: 4b4480a32b343c7aeca3161e12ba7877
> Homepage: http://tlf.github.io/
> Tag: uitoolkit::ncurses
> Section: hamradio
> Priority: optional
> Filename: pool/main/t/tlf/tlf_1.3.2-1_amd64.deb
> Size: 357000
> MD5sum: 229818b440314c79bba5a7a30349ce8f
> SHA256: 6682f1694d1f060f7d8265c484468a88903efdcc45caad6ae7108eef92ad96bd
>
> user@debian:~$ apt-cache showpkg tlf
> Package: tlf
> Versions:
> 1.3.2-1 
> (/var/lib/apt/lists/deb.debian.org_debian_dists_buster_main_binary-amd64_Packages)
> (/var/lib/dpkg/status)
>  Description Language:
>                  File:
> /var/lib/apt/lists/deb.debian.org_debian_dists_buster_main_binary-amd64_Packages
>                   MD5: 4b4480a32b343c7aeca3161e12ba7877
>  Description Language: en
>                  File:
> /var/lib/apt/lists/deb.debian.org_debian_dists_buster_main_i18n_Translation-en
>                   MD5: 4b4480a32b343c7aeca3161e12ba7877
>
>
> Reverse Depends:
>   hamradio-logging,tlf
> Dependencies:
> 1.3.2-1 - libc6 (2 2.15) libglib2.0-0 (2 2.35.9) libhamlib2 (0 (null))
> libncursesw6 (2 6) libtinfo6 (2 6) libxmlrpc-core-c3 (0 (null)) sox (0
> (null)) xplanet (0 (null))
> Provides:
> 1.3.2-1 -
> Reverse Provides:
> user@debian:~$
> -----
>
> To wrap up, sounds like one hypothesis is a race condition.  I will
> try putting just my local working directory (with logcfg.dat, rules,
> log file, cty and partials) on a disk drive to see if there is any
> change.  If not, then I will do a buster install on a disk drive and
> see if that makes a difference.
>
> No, I haven't looked at the source code, yet, myself.  More than happy
> to work on trouble shooting with you and leaning on your existing
> familiarity with the source code.  I could dig into the source
> eventually if need be.  No problem to patch and build from source to
> try out potential bugfixes.  I am quite literate in C and git.
>
> Thanks and best regards,
>
> Drew
> kb9fko
>
> On Wed, Jul 31, 2019 at 8:18 PM Ervin Hegedüs <address@hidden> wrote:
> >
> > Drew, Thomas, and all,
> >
> > On Tue, Jul 30, 2019 at 02:26:25PM +0000, Drew Arnett wrote:
> >
> > I don't have Debian Buster actually, but have a Debian SID - it's
> > not so far from Buster :), and all related components are same as
> > your side:
> >
> > # dpkg -l tlf *hamlib* | grep ^ii
> > ii  libhamlib++-dev:amd64 3.3-5+b1     amd64        Development C++ library 
> > to control radio transceivers and receivers
> > ii  libhamlib-dev:amd64   3.3-5+b1     amd64        Development library to 
> > control radio transceivers and receivers
> > ii  libhamlib-utils       3.3-5+b1     amd64        Utilities to support 
> > the hamlib radio control library
> > ii  libhamlib2:amd64      3.3-5+b1     amd64        Run-time library to 
> > control radio transceivers and receivers
> > ii  libhamlib2++c2:amd64  3.3-5+b1     amd64        Run-time C++ library to 
> > control radio transceivers and receivers
> > ii  libhamlib2-tcl        3.3-5+b1     amd64        Run-time Tcl library to 
> > control radio transceivers and receivers
> > ii  tlf                   1.3.2-1      amd64        console based ham radio 
> > contest logger
> >
> > On that machine, I don't have a phisycal connect with RIG, so
> > I've used `rigctld -m 1`, set up the "virtual" rig on another
> > terminal ("rigctl -m 2; F 14002000"), and started Tlf with Drew's
> > config.
> >
> > > Run mode has problems.  Start auto CQ which works fine.  As soon as I
> > > start typing in a callsign, the auto CQ stops and the "AUTO_CQ" marker
> > > in the upper left corner changes to "S&P".
> >
> > I can't reproduce this issue. When AUTO_CQ sent the CQ, and I
> > typed a foreign call, it switched to "LOG". I finished the
> > callsign, pressed TAB, entered the zone, pressed ENTER, then Tlf
> > sent "TU KB9FKO", and stayed in LOG mode.
> >
> > I pressed F12, Tlf switched to AUTO_CQ, and started to sent the
> > CQ again.
> >
> > > (Is this a clue?)  I type
> > > in his callsign and hit enter in the callsign box.  TLF sends mycall.
> > > Wrong behavior.  I'm expecting it to send his call and my exchange.  I
> > > enter his exchange and hit enter in the exchange box and it sends TU
> > > and my exchange.  Also wrong behavior.  In both cases, it sends the
> > > correct thing for S&P, but not the correct thing for run mode.
> >
> > sorry, I have no idea, what happened.
> >
> > > Am I doing something wrong?  Do I have something misconfigured?  Is it
> > > a bug in the SW?  Or if this should work, and it was a mistake in
> > > debian packaging deltas, should I file a debian bug?
> >
> > I don't know how many user uses Tlf from the Debian repository.
> > There is a popularity contest, but the number of users is under
> > 100:
> >
> > https://qa.debian.org/popcon.php?package=tlf
> >
> > but I think this issue would occured with these users.
> >
> > > My setup...
> > >
> > > OS:  debian buster live 10.0.0 xfce
> >
> > could you show me these outputs?
> >
> > apt-cache show tlf
> > apt-cache showpkg tlf
> >
> > Could you try it with another setup, eg CQWW (as Thomas proposed
> > too).
> >
> >
> > Just my 2cents: there was a similar issue at my side few years
> > ago, when I switched from SATA disk to SSD. I've worked on some
> > sprint contest (DARC Oestercontest...?), and the two modes
> > switched "too fastly", and sometimes it switched twice, so I got
> > back the original mode.
> >
> > As you wrote, you're using Debian Buster Live - em I right that
> > this uses RAMDISK? Which is faster than an SSD...?
> >
> > Do you have any permanent installed Debian? It should be in any
> > virtual system (VirtualBox, VMWare, ...). If yes, could you try
> > there?
> >
> >
> >
> > Thanks,
> >
> >
> > Ervin
> > HA2OS
> >