First start of LiveTV failed when activeEIT enabled

[warpme@…]

Recently I enabled active EIT scan on my system (v0.25pre-3260-ga15740a-dirty-20110829). Since this I notice every LiveTV start, when active scanner is running (I mean no ongoing recordings so EIT scanner is in active mode), causes LiveTV fail with dialog "waiting too long to open buffers". Consecutive attempts to start LiveTV are OK. It looks like there is pure correlation between failures of LiveTV and stopping active EIT scanning. BE/FE logs attached.

[warpme@…]

FE/BE logs

[warpme@…]

Hi, After some extensive period of usage I want little more specify issue:

-It appears that not every LiveTV start which meet EIT scanner in active mode ends with "Wait too long to open buffer" (some days it is almost every attempt, other days not at all).

-When it happens, recorder which is serving this LiveTV session stays occupied till EPG program end-time or till scheduled recording starts (I'm attaching BE trace with such "hung recorder" and rest rest system in idle). This is bad as it excludes whole phy tuner sometimes for long time :-(

-There is no rec. file for such failed LiveTV session so it looks like start of recorder is quite early "confused/blocked" by meeting running active EIT scanner.

[warpme@…]

Trace with hung recorder

[warpme@…]

Hi, just in case when it might be helpful. Week ago I moved active scan to tuner1 and make sure for livetv uses only tuner2. During week of tests (+450 rec.) no any issues with LiveTV nor recording. It looks like active scan has issue only with livetv. During that period, few times I was trying to use livetv on tuner1 (which has active scan enabled). Issue with livetv reappear and also I had 2 deadlocks with PROTOCOL_EMPTY_RESPONSE (trace called as trace20110920.txt attached). -br

[warpme@…]

MYTH_PROTO_EMPTY trace

[lomion@…]

I believe to see the same problem. My work-around is to set the "quick channel change" option in Myth-Setup to "Always". When setting to "Never" or "Only LiveTv?" I got your problem.

Remark: I use the german translation so the names above might not be 100% correct.

[warpme@…]

FYI, I tested 0.25 with backported ca27332496. While ca27332496 noticeable improves stability - issue described in comment #1 is still present. backtrace attached.

[warpme@…]

BT for 0.25 with ca27332496

[warpme@…]

BTW to current 0.25-fixes + ca27332496. I can also repeatably generate BE deadlock (not sure is it related to ca27332496 or not - but I believe not). Scenario:

1.Enable ActiveEIT scan

2.Wait till EIT scanner starts

3.Kick LiveTV. First lauch ends with "Video buffers failed too many tomes"

4.Kick LiveTV again. It starts OK.

5.Enter OSD and try to change to another phy tuner.

6.BE deadlocks in w way that FE stalls on any comm.request to BE

[danielk]

I can not reproduce this. And I can't see evidence of deadlock in trace_20120708.txt​.

[warpme@…]

Daniel, attached trace was for hung recorder - not for deadlocked BE. As "it works for You" I assume I shouldn't waste my time and generate trace from deadlocked BE, right ?

[danielk]

warpme, a backtrace from the deadlocked BE could very well identify the the problem. I can't reproduce, so without that backtrace no progress will be made...

[warped <warpme@…>]

Daniel, I'm attaching trace file for deadlocked BE. Scenario was like in comment #5 but I hat to use OSD few times to trigger deadlock. -br

[warped <warpme@…>]

trace for Deadlocked BE

[danielk]

warpme, this looks like the problem fixed in [445faaa47].

In thread 5, StreamHandler::Start() is waiting for the stream handler thread to start.

Can you try to reproduce with the latest master?

[warpme@…]

Daniel, I'm on holidays and I'll back after 08/08. I'll try this commit ASAP after my return. Thx !!!

[danielk]

warpme, ok. I'm going to close this as fixed by [445faaa47]. But please ping the ticket after you get back either way.

[warpme@…]

Daniel, I was using 0.25.2 durring last 2 weeks with this patch and no any restrictions on EIT scanner. I can confirm issue is solved. Thx !