Opened 13 years ago
Closed 12 years ago
Last modified 12 years ago
#10016 closed Bug Report - Hang/Deadlock (Fixed)
First start of LiveTV failed when activeEIT enabled
Reported by: | Owned by: | danielk | |
---|---|---|---|
Priority: | critical | Milestone: | 0.26 |
Component: | MythTV - EIT | Version: | Master Head |
Severity: | high | Keywords: | |
Cc: | Ticket locked: | no |
Description
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.
Attachments (5)
Change History (20)
comment:1 Changed 13 years ago by
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.
comment:2 Changed 13 years ago by
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
comment:3 Changed 13 years ago by
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.
comment:4 Changed 13 years ago by
FYI, I tested 0.25 with backported ca27332496. While ca27332496 noticeable improves stability - issue described in comment #1 is still present. backtrace attached.
comment:5 Changed 13 years ago by
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
comment:6 Changed 13 years ago by
Milestone: | unknown → 0.26 |
---|---|
Owner: | changed from Stuart Auchterlonie to danielk |
Priority: | minor → critical |
Severity: | medium → high |
Status: | new → assigned |
Type: | Bug Report - General → Bug Report - Hang/Deadlock |
comment:7 Changed 13 years ago by
Resolution: | → Works for me |
---|---|
Status: | assigned → closed |
I can not reproduce this. And I can't see evidence of deadlock in trace_20120708.txt.
comment:8 Changed 13 years ago by
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 ?
comment:9 Changed 13 years ago by
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...
comment:10 Changed 13 years ago by
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
comment:11 Changed 13 years ago by
Resolution: | Works for me |
---|---|
Status: | closed → new |
comment:12 Changed 12 years ago by
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?
comment:13 Changed 12 years ago by
Daniel, I'm on holidays and I'll back after 08/08. I'll try this commit ASAP after my return. Thx !!!
comment:14 Changed 12 years ago by
Resolution: | → Fixed |
---|---|
Status: | new → closed |
warpme, ok. I'm going to close this as fixed by [445faaa47]. But please ping the ticket after you get back either way.
comment:15 Changed 12 years ago by
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 !
FE/BE logs