[mythtv-commits] Ticket #10771: BE deadlocks after backporting #10541

MythTV noreply at mythtv.org
Fri Jul 6 10:02:45 UTC 2012

#10771: BE deadlocks after backporting #10541
 Reporter:  warpme@…                    |          Owner:  danielk
     Type:  Bug Report - Hang/Deadlock  |         Status:  infoneeded
 Priority:  major                       |      Milestone:  0.25.1
Component:  MythTV - EIT                |        Version:  0.25-fixes
 Severity:  medium                      |     Resolution:
 Keywords:  EIT                         |  Ticket locked:  0

Comment (by warpme@…):

 Stuart, #11d7795503h nicely improves user expierience as with this patch -
 when zapping LiveTV - I don't have deaf to Ch+/Ch- periods around full
 hours (when scheduler reschedules). Also "Opening video buffers failed too
 many times" when used zaps LiveTV around reschedule almost gone.
 Unfortunately it causes frequent BE deadlocks. So far I can describe 2
 1. I have applied #10076 with EIT scan window for 1:05AM-5:01AM. Scenario
 for deadlock is following:[[BR]]

 -Start BE, wait whole night to EIT scan[[BR]]

 -Launch LiveTV after night. It gets TLMSC but after 5-10sec of black
 screen going back to MainMenu with "Opening video buffers failed too many

 -Launching LiveTV again gives Popup "Connection to BE was lost" and BE
 stops to communicate with all FE (any action on FE gives 5-10sec stale and
 goes to MainMenu)[[BR]]

 2. Turning-off EIT scan at time window (original way of gathering EIT), I
 can trigger deadlock in following way:[[BR]]

 -Start BE and wait till EIT active scanner starts[[BR]]

 -Start LiveTV few times[[BR]]

 -After 1..3 LiveTV starts, I get "Opening video buffers failed too many
 times" and return to MainMenu[[BR]]

 -Now BE is in deadlock state where asking for LiveTV or recordings
 Playback gives immediate back to MainMenu.[[BR]]

 For this scenario I'm attaching BE.log & backtrace.

 Generally - after 10 months of living with #10016 I think root cause is
 related to how active EIT scanner is stopped when recorder starts on given
 tuner. Doing some tests on scenario 2 shows me that deadlock occurs when
 given tuner is just grabbing EIT and grabber is preempted by LiveTV

 If I'm reading code correctly - looking on eitscanner.cpp:83, main scanner
 loop can be ended in quite rare execution places. Lest imagine: if LiveTV
 recorder just tuning to new channel and eit scanner is just doing any
 action between eitscanner.cpp:86...151 - we have resource access conflict
 as tuner just grabbing EIT and in the same time is tuning to new channel.
 I believe issue described in #9480 comment #7 is exactly result of these
 conflicts (EIT is on Cyfra mplex while LiveTV tunes to Polsat).[[BR]]

 I think we should look how exactly EIT scanner is tear down when recorder

Ticket URL: <http://code.mythtv.org/trac/ticket/10771#comment:28>
MythTV <http://code.mythtv.org/trac>
MythTV Media Center

More information about the mythtv-commits mailing list