[mythtv-commits] Ticket #8142: Frontend timeout when changing backend channels (bt878)

MythTV mythtv at cvs.mythtv.org
Wed Jun 16 05:42:40 UTC 2010


#8142: Frontend timeout when changing backend channels (bt878)
-------------------------------------------------+--------------------------
 Reporter:  Chris Picton <chrisp@…>              |       Owner:  janne     
     Type:  defect                               |      Status:  assigned  
 Priority:  minor                                |   Milestone:  unknown   
Component:  MythTV - Recording                   |     Version:  0.22-fixes
 Severity:  medium                               |     Mlocked:  0         
-------------------------------------------------+--------------------------

Comment(by dgatwood <dgatwood@…>):

 It's not just while Live TV is running.  I was about to file basically the
 same bug because of Live TV refusing to start at all.  It turns out that
 my problems are also caused by the channel change script taking too long
 and the front end timing out.

 Changing the timeout (as suggested in the related bug) would lock up the
 front end, and is thus highly undesirable.  However, blaming it on the
 script doesn't solve this very real and common problem.  Channel changing
 scripts with an IR blaster may take several seconds to execute, and
 apparently, some other types of receivers have an inherent problem with
 this as well, so this bug does need to be addressed.

 Ultimately, the best way to solve the problem is to not block the backend
 while the channel changing script is executing at all.  This requires two
 or three changes:

 1.  Start the channel change script asynchronously (spawn a helper thread)
 and return control immediately to allow normal backend operation.  If the
 frontend really needs to know when the channel change is complete, it
 could periodically poll for the status of the command (not sure if that
 would require changes to the protocol or not), but it's probably not
 important enough to bother.

 2.  Immediately reject any attempts to change the channel if an instance
 of the channel change script (or the helper thread that controls it) is
 still running.  This is critical to prevent scripts that use irsend from
 interleaving multiple channel numbers during rapid channel changes.

 3.  You might consider adding a brief delay after the channel change
 before allowing the next one.  Some scripts may need to add additional
 delays on a per-device basis as needed, but a small delay in the backend
 itself might reduce the number of scripts that would require changes.  Or
 don't, and just tell script writers to add the delay as needed.


 If there are weird setups that this sort of scheme would break, I'd be
 okay with a checkbox to control whether to run it asynchronously.  If so,
 please put it right beside/below the command field, and provide an
 explanation of why you may want to check the checkbox so that folks won't
 waste so much time trying to figure out what's wrong.  That said, I
 wouldn't think that would be necessary.


 As a workaround for anyone running into this:

 mv channel_change_script.sh channel_change_script_guts.sh

 cat <<EOF > channel_change_script.sh[[BR]]
 #!/bin/sh

 /path/to/channel_change_script_guts.sh "$@" &

 exit 0[[BR]]
 EOF

 chmod a+rx channel_change_script.sh

-- 
Ticket URL: <http://svn.mythtv.org/trac/ticket/8142#comment:6>
MythTV <http://www.mythtv.org/>
MythTV


More information about the mythtv-commits mailing list