livetv does not work (svn 8575) [DVB]

[anonymous]

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.

[anonymous]

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

[anonymous]

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

[danielk]

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.

[danielk]

(In [8586]) References #1013.

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

[cpinkham]

(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].

[Mark de Jong <dejongm@…>]

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

[cpinkham]

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

[cpinkham]

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].

[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.

[cpinkham]

(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.