Opened 14 years ago

Closed 14 years ago

#1013 closed defect (fixed)

livetv does not work (svn 8575) [DVB]

Reported by: anonymous Owned by: cpinkham
Priority: blocker Milestone: 0.19
Component: dvb Version: head
Severity: medium Keywords:
Cc: Ticket locked: no

Description

when I try to watch TV, the osd comes up with the signal information (has signal and lock), and then the frontend freezes from a timeout waiting for prebuffer.

scheduling a recording and then watching that in quasi-live mode works fine. Livetv was working fine in 8553.

FE/BE logs attached.

Attachments (3)

frontend.txt (17.1 KB) - added by anonymous 14 years ago.
backend.txt (37.8 KB) - added by anonymous 14 years ago.
felog.011306.rtf (3.2 KB) - added by Mark de Jong <dejongm@…> 14 years ago.

Download all attachments as: .zip

Change History (14)

Changed 14 years ago by anonymous

Attachment: frontend.txt added

Changed 14 years ago by anonymous

Attachment: backend.txt added

comment:1 Changed 14 years ago by anonymous

Component: mythtvdvb
Milestone: 0.19
Owner: changed from Isaac Richards to danielk
Summary: livetv does not work (svn 8575)livetv does not work (svn 8575) [DVB]
Version: head

comment:2 Changed 14 years ago by anonymous

just tried 8566 build, livetv worked fine (I am the original poster).

comment:3 Changed 14 years ago by anonymous

is it possible this is caused by 8571 and a nonrecursive mutex?

comment:4 Changed 14 years ago by danielk

Owner: changed from danielk to cpinkham

I narrowed this down to [8573].

Chris, I didn't dig too deeply but this appears to be due to stream changes trying to lock avcodeclock when it is already holding a lock.

Anon, if you revert the changes to avformatdecoder.cpp from [8573], LiveTV works again.

comment:5 Changed 14 years ago by danielk

(In [8586]) References #1013.

Reverts the AvFormatDecoder? part of [8573] until cpinkham gets a chance to look at the problem.

comment:6 Changed 14 years ago by cpinkham

Resolution: fixed
Status: newclosed

(In [8590]) Because avcodec_open is called inside of ScanStreams?, and avcodeclock is locked and unlocked around ScanStreams?, then we need to not put locks around the call to avcodec_open. Instead, we add a second set of avcodeclock locks around the other call to ScanStreams? which was not protected before. The lock calls around avcodec_close have been uncommented again.

This should fix #1013 and references [8573].

comment:7 Changed 14 years ago by Mark de Jong <dejongm@…>

Resolution: fixed
Status: closedreopened

SVN: 8602 I'm still having this very same issue. FE log attached.

Changed 14 years ago by Mark de Jong <dejongm@…>

Attachment: felog.011306.rtf added

comment:8 Changed 14 years ago by cpinkham

(In [8604]) References #1013, reverts part of [8590] until we can get the deadlock figured out.

comment:9 Changed 14 years ago by cpinkham

Priority: minorblocker

Mark, can you update to SVN head and verify things work correctly again, then apply the attached avcodeclock.diff patch and see if it still works correctly after applying the patch. We need to lock around avcodec_open and avcodec_close, otherwise we get failures when multiple threads are trying to call one of those such as when we have multiple recordings ending at the same time and multiple preview generators firing off. This was the reason for the initial added locks. With this patch, we convert the lock to a recursive lock, so we can lock it once inside HandleStreamChange? which calls ScanStreams?, then inside ScanStreams?, we can lock it again around avcodec_open. This way when we call ScanStreams? outside of HandleStreamChange?, we still correctly lock around avcodec_open.

If this doesn't fix the issue, I'll have to defer to someone with DVB. I'm unable to replicate the issue on my system with either patch revision. We need to get locks around this call to avcodec_open somehow since it is a documented issue that it is not thread-safe. It is thread-aware in that it prints a nasty error message if called twice at the same time, so it doesn't segfault or anything, but it can and does break functionality in certain parts of Myth. Otherwise we'll have lots of users with multiple tuners getting the error I noted in [8573].

comment:10 Changed 14 years ago by anonymous

FWIW, after 8590 I no longer experienced prebuffering pause problems (I am the original poster). I just tried 8604 with and without the avcodeclock.diff, and in both cases live tv worked fine.

comment:11 Changed 14 years ago by cpinkham

Resolution: fixed
Status: reopenedclosed

(In [8622]) Convert avcodeclock into a recursive lock so we can call it multiple times from one thread. Re-enable the locking around avcodec_open in AVD. Closes #1013.

Note: See TracTickets for help on using tickets.