Opened 16 years ago
Closed 16 years ago
Last modified 16 years ago
#4566 closed defect (fixed)
Multirec merge: Backend gets stuck tuning channel
Reported by: | Owned by: | danielk | |
---|---|---|---|
Priority: | minor | Milestone: | 0.21 |
Component: | mythtv | Version: | head |
Severity: | medium | Keywords: | |
Cc: | Ticket locked: | no |
Description
The backend can at times get stuck while tuning a channel. The attached logs show an example tuning 5330. The frontend after a few seconds shows the standard error while displaying video message and the backend hangs on:
2008-02-01 15:29:42.388 TVRec(5): SetFlags?(WaitingForRecPause?,) -> RunMainLoop?,CancelNextRecording?,WaitingForRecPause?,RecorderRunning?,
The backend at this point has to be kicked in order to use tuner 5 again. Backend, frontend and bt attached.
Attachments (13)
Change History (26)
Changed 16 years ago by
Attachment: | backend.txt added |
---|
comment:1 Changed 16 years ago by
Milestone: | unknown → 0.21 |
---|---|
Owner: | changed from Isaac Richards to danielk |
Status: | new → assigned |
comment:2 Changed 16 years ago by
Mark, can you try the latest SVN? Based on the logs, I believe [15760] may have fixed this...
Changed 16 years ago by
Backtraces and step.. look at the end of the file.
comment:3 Changed 16 years ago by
Daniel, I will. I've gathered more info and attached it. If 15760 doesn't fix this bug, log.txt should be reveling. Look at the bottom of the file - thread 12 is the stuck thread.
- Mark.
comment:4 Changed 16 years ago by
Daniel, looking through that patch, I'm uncertain it fixes this issue. The frontend doesn't happily wait, it actually exits with the standard "error while displaying..." quite quickly (I suspect after the "quick" timeout). The backend, however, looks to be looping between SetChannel?(), WaitForEventThreadSleep?()and HasFlags?() within TVRec even after the frontend exits and even after it's restarted. The backed stays stuck until it's restarted.
I'll give it a try tonight anyway.
- Mark.
comment:5 Changed 16 years ago by
Daniel, this is still an issue for me. This time, however, it looks like it cycling somewhere else. It's still stuck tuning but the frontend is, with this one, completely unusable since it keeps timing out on socket communications (quick).
- Mark.
comment:6 Changed 16 years ago by
Added latest backtrace and backend log. This time it seems to be stuck in yet a third place.
- Mark.
comment:7 Changed 16 years ago by
Mark, does this happen when EIT is disabled?
I think maybe recent changes in the EIT handling may have caused the problem and the multirec code is either just an aggravating factor or a red herring.
comment:8 Changed 16 years ago by
Status: | assigned → infoneeded |
---|
comment:9 Changed 16 years ago by
Added logs & bt as requested. It does indeed get stuck with all EIT disabled.
comment:10 Changed 16 years ago by
Status: | infoneeded → assigned |
---|
note: From tracing Mark did and discussed on #mythtv
It seems to be getting stuck in DRB::WaitForUsed?() after listeners should have been removed, probably because neither true=>request_pause nor false=>running are set when the last Listener on DVBStreamHandler() is removed, or some listener is not getting removed when it should be.
comment:11 Changed 16 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
(In [16058]) Fixes #4566. Makes sure that the DeviceReadBuffer? stops reading the dvb device when the DVBStreamHandler is stopped.
Before it was possible that the DRB never received the signal because the stream handler was waiting for the DRB to stop blocking before sending the signal and the DRB would only stop blocking if it recieved data on the file handle, or got the stop/paused signal. This change makes sure we send the stop signal to the DRB before we try to stop the stream handler so that shutdown does not depend on there being data in the DVB driver's buffers.
Backend log