[mythtv-users] Need help with failed attempt to fix tuner problem

Craig Huff huffcslists at gmail.com
Sat Apr 9 00:45:40 UTC 2016


Background:
I use an IguanaIR IR transceiver to control four tuners that are connected
to it with direct connections so there's no IR crosstalk problems.

Problem:
I'm running into race conditions that result in the wrong tuner getting
commanded to change channel.

Attempted solution:
I use change-channel-lirc.pl to do the channel changes, invoking the
appropriate LIRC commands.  I thought to fix this by adding a flock call to
lock a dummy file I made up (/var/lib/mythtv/channel_changer.lock) before
doing the channel change and then unlocking it when done.

If I invoke the script like this to try and change all four tuners to an
arbitrary channel, say 54, at one time:
    # for f in 1 2 3 4; do
    >     ./modified-channel-change-lirc.pl $f 54 &
    > done
then the four tuners take turns (not necessarily in order 1-2-3-4, but
that's not a problem) doing their processing as evidenced by messages I
print to a log file.  This happens whether I'm logged in as the lowly
mythtv user, or as root. All well and good.  But...

When the system first boots up, the backend process wants to establish that
all four tuners are in a known state, so it invokes the channel change
routine for each of the four tuners to set them to their last assigned
channel.  That's fine, too, but...  When I look at the log file, in this
instance there is no orderly tuning of one after the other, but rather
messages for all four requests to lock the file appear, mixed up with
messages reporting each tuner/channel combination requested, in no
particular order (as when I tried the for-loop), random channel digit
transmission messages and messages about the four invocations of flock to
release the file lock.

I'd greatly appreciate it if someone could clue me in on why the perl
script misbehaves when mythbackend invokes it vs. me invoking it on the
command line.

Attached is my current test script.

--
Craig.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20160408/8dd40357/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.pl
Type: text/x-perl
Size: 2295 bytes
Desc: not available
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20160408/8dd40357/attachment.bin>


More information about the mythtv-users mailing list