Opened 15 years ago

Closed 14 years ago

Last modified 14 years ago

#10016 closed Bug Report - Hang/Deadlock (Fixed)

First start of LiveTV failed when activeEIT enabled

Reported by: warpme@… 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)

logs.zip​ (45.4 KB ) - added by warpme@… 15 years ago.
FE/BE logs
hung_recorder.trace.zip​ (2.6 KB ) - added by warpme@… 15 years ago.
Trace with hung recorder
trace20110920​ (36.7 KB ) - added by warpme@… 15 years ago.
MYTH_PROTO_EMPTY trace
trace_20120708.txt​ (31.8 KB ) - added by warpme@… 14 years ago.
BT for 0.25 with ca27332496
trace_20120713-1.txt​ (64.1 KB ) - added by warped <warpme@…> 14 years ago.
trace for Deadlocked BE

Download all attachments as: .zip

Change History (20)

by warpme@…, 15 years ago

Attachment: logs.zip​ added

FE/BE logs

comment:1 by warpme@…, 15 years ago

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.

by warpme@…, 15 years ago

Attachment: hung_recorder.trace.zip​ added

Trace with hung recorder

comment:2 by warpme@…, 15 years ago

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

by warpme@…, 15 years ago

Attachment: trace20110920​ added

MYTH_PROTO_EMPTY trace

comment:3 by lomion@…, 14 years ago

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 by warpme@…, 14 years ago

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

by warpme@…, 14 years ago

Attachment: trace_20120708.txt​ added

BT for 0.25 with ca27332496

comment:5 by warpme@…, 14 years ago

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 by stuartm, 14 years ago

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 by danielk, 14 years ago

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 by warpme@…, 14 years ago

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 by danielk, 14 years ago

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 by warped <warpme@…>, 14 years ago

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

by warped <warpme@…>, 14 years ago

Attachment: trace_20120713-1.txt​ added

trace for Deadlocked BE

comment:11 by danielk, 14 years ago

Resolution: Works for me
Status: closed → new

comment:12 by danielk, 14 years ago

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 by warpme@…, 14 years ago

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

comment:14 by danielk, 14 years ago

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 by warpme@…, 14 years ago

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 !

Note: See TracTickets for help on using tickets.