Opened 8 years ago

Closed 7 years ago

Last modified 7 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@… 8 years ago.
FE/BE logs
hung_recorder.trace.zip (2.6 KB) - added by warpme@… 8 years ago.
Trace with hung recorder
trace20110920 (36.7 KB) - added by warpme@… 8 years ago.
MYTH_PROTO_EMPTY trace
trace_20120708.txt (31.8 KB) - added by warpme@… 7 years ago.
BT for 0.25 with ca27332496
trace_20120713-1.txt (64.1 KB) - added by warped <warpme@…> 7 years ago.
trace for Deadlocked BE

Download all attachments as: .zip

Change History (20)

Changed 8 years ago by warpme@…

Attachment: logs.zip added

FE/BE logs

comment:1 Changed 8 years ago by 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.

Changed 8 years ago by warpme@…

Attachment: hung_recorder.trace.zip added

Trace with hung recorder

comment:2 Changed 8 years ago by 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

Changed 8 years ago by warpme@…

Attachment: trace20110920 added

MYTH_PROTO_EMPTY trace

comment:3 Changed 8 years ago by 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.

comment:4 Changed 7 years ago by warpme@…

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

Changed 7 years ago by warpme@…

Attachment: trace_20120708.txt added

BT for 0.25 with ca27332496

comment:5 Changed 7 years ago by 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

comment:6 Changed 7 years ago by stuartm

Milestone: unknown0.26
Owner: changed from Stuart Auchterlonie to danielk
Priority: minorcritical
Severity: mediumhigh
Status: newassigned
Type: Bug Report - GeneralBug Report - Hang/Deadlock

comment:7 Changed 7 years ago by danielk

Resolution: Works for me
Status: assignedclosed

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

comment:8 Changed 7 years ago by 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 ?

comment:9 Changed 7 years ago by 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...

comment:10 Changed 7 years ago by 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

Changed 7 years ago by warped <warpme@…>

Attachment: trace_20120713-1.txt added

trace for Deadlocked BE

comment:11 Changed 7 years ago by danielk

Resolution: Works for me
Status: closednew

comment:12 Changed 7 years ago by 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?

comment:13 Changed 7 years ago by warpme@…

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

Resolution: Fixed
Status: newclosed

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 7 years ago by 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 !

Note: See TracTickets for help on using tickets.