jhoyt4 commented 2 years ago

Upon restart, mythbackend appears to be issuing two calls to the channel change script when scheduling the first recording after the backend starts. The same occurs if entering Live TV after the backend restarts.

This is occurring with an external recorder .

Platform: Ubuntu 22.04 (Linux mythtv 5.15.0-37-generic 39-Ubuntu SMP Wed Jun 1 19:16:45 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux)
MythTV version: fixes/32
Package version: mythbuntu ppa: v32.0+fixes.202206060103.7077a824d2~ubuntu22.04.1
Component: mythbackend

What steps will reproduce the bug?

1) restart mythbackend 2) start Live TV

or

1) restart mythbackend 2) schedule a recording to start immediately

How often does it reproduce? Is there a required condition?

Every time after mythbackend restarts

What is the expected behaviour?

Only a single call to the channel change script

What do you see instead?

Two calls to the channel change script

Jun 11 16:09:55 mythtv mythbackend: mythbackend[3537]: I MetadataDownload metadatagrabber.cpp:377 (RunGrabber) Running Grabber: /usr/share/mythtv/metadata/Television/ttvdb4.py -l en -a US -N Chicago Fire Retaliation Hit Jun 11 16:09:55 mythtv mythbackend: mythbackend[3537]: D MetadataDownload mythsystemunix.cpp:808 (Fork) Launching: /usr/share/mythtv/metadata/Television/ttvdb4.py -l en -a US -N Chicago Fire Retaliation Hit Jun 11 16:09:55 mythtv mythbackend: mythbackend[3537]: I MetadataDownload mythsystemunix.cpp:965 (Fork) Managed child (PID: 3623) has started! command=/usr/share/mythtv/metadata/Television/ttvdb4.py -l en -a US -N Chicago Fire Retaliation Hit, timeout=0 Jun 11 16:09:55 mythtv mythbackend: mythbackend[3537]: I SystemManager mythsystemunix.cpp:354 (run) Managed child (PID: 3552) has exited! command=/usr/local/bin/ir_channel_change.bash 510, status=0, result=0 Jun 11 16:09:59 mythtv mythbackend: mythbackend[3537]: D TVRecEvent mythsystemunix.cpp:808 (Fork) Launching: /usr/local/bin/ir_channel_change.bash 550 Jun 11 16:09:59 mythtv mythbackend: mythbackend[3537]: I TVRecEvent mythsystemunix.cpp:965 (Fork) Managed child (PID: 3638) has started! & command=/usr/local/bin/ir_channel_change.bash 550, timeout=0 Jun 11 16:09:59 mythtv mythbackend: mythbackend[3537]: D TVRecEvent mythsystemunix.cpp:808 (Fork) Launching: /usr/local/bin/ir_channel_change.bash 550 Jun 11 16:09:59 mythtv mythbackend: mythbackend[3537]: I TVRecEvent mythsystemunix.cpp:965 (Fork) Managed child (PID: 3641) has started! & command=/usr/local/bin/ir_channel_change.bash 550, timeout=0

Additional information

I've been seeing missed channel changes for several months, and unfortunately only now tracked down the culprit.

jhoyt4 commented 1 year ago

Looks like others are experiencing the same issue: https://forum.mythtv.org/viewtopic.php?f=29&t=5289&p=25490#p25490

rwis42 commented 1 year ago

I'm experiencing the same thing. Ubuntu 22.04.1 LTS MythTV 32.0 + fixes package: mythtv/jammy,now 2:32.0+fixes.20220325.f69ce764b7-0ubuntu1 all [installed]

SteveErl commented 4 months ago

I can explain why it's happening. Your script is invoked by HandleScript(), which is only called in one place

libs/libmythtv/recorders/dtvchannel.cpp

157 bool DTVChannel::SetChannelByString(const QString &channum)
158 {
...
381     HandleScript(freqid);
382 
383     return ok; 
384 }

The SetChannelByString() is called in several places, but I believe the significant one for your scenario is in tv_rec.cpp:

libs/libmythtv/tv_rec.cpp
3705 void TVRec::TuningFrequency(const TuningRequest &request)
3706 {
...
3711     if (dtvchan)
3712     {   
...
3718         // Tune with SI table standard (dvb, atsc, mpeg) from database, see issue #452
3719         m_channel->SetChannelByString(request.m_channel);
...
3739     }   
...
3764     if (m_channel)
3765     {   
3766         m_channel->Open();
3767         if (!channum.isEmpty())
3768             ok1 = m_channel->SetChannelByString(channum);
3769         else
3770             ok1 = false;
3771     }

Notice that for normal operation of the TuningFrequency() routine, SetChannelByString() is being called twice. There is a helpful comment just before the first call which tells us to look at Issue #452. It looks like the solution to that issue added in the first call to SetChannelByString(). Ever since that solution was merged in, every time I tune into a Live TV channel, the device tuning has been performed twice. If I had a channel change script, it would be invoked twice, as well.

It's difficult for me to code up a solution because Issue

452 has something to do with DVB tuning, which I

don't have access to. I could eliminate the double tuning on my system, but that might break something for users with DVB tuners. Maybe the second invocation of SetChannelByString() could be done only for DVB tuners?

bennettpeter commented 4 months ago

FWIW I use a script that includes a check for this. This can save time by avoiding retuning.

    if [[ "$tunestatus" == tuned  ]] ; then
        if [[ "$tunechan" == "$channum" ]] ; then
            echo `$LOGDATE` "Tuner already tuned, all ok"
            exit 0
        else
            echo `$LOGDATE` "WARNING tuner already tuned to $tunechan, will retune"
            adb connect $ANDROID_DEVICE
            capturepage
            if [[ "${pagename,,}" != "$NAVTYPELC" ]] ; then
                $scriptpath/adb-sendkey.sh BACK
                sleep 3
            fi
        fi
    fi
....code to actually tune after this

jhoyt4 commented 4 months ago

I ended up putting a lock function on my script to prevent two instances from running simultaneously. When they ran simultaneously channel digits from the two calls ended up being interleaved messing up the channel change.

This was discussed on the user's mailing list back in 2022 when I originally generated the issue. I'd post a link but the archive search function is down at the moment.

MythTV / mythtv

double call to channel change script #584