Opened 19 years ago
Closed 19 years ago
#399 closed defect (fixed)
Quick state change can result in backend looping
Reported by: | Owned by: | danielk | |
---|---|---|---|
Priority: | major | Milestone: | unknown |
Component: | mythtv | Version: | head |
Severity: | high | Keywords: | |
Cc: | Ticket locked: | no |
Description
The switch from RecordingOnly? to None and then a quick switch from None to RecordingOnly? (the sort you get with consecutive schedules) seems to currently cause a certain amount of badness.
Results vary from a few slightly bad log messages, to a spiraling death loop.
Log attached (removed scheduler calls, otherwise unaltered).
Attachments (2)
Change History (5)
comment:1 Changed 19 years ago by
Owner: | changed from Isaac Richards to danielk |
---|---|
Status: | new → assigned |
comment:2 Changed 19 years ago by
All cards in that machine are pvrX50s.
I added some debug code and I don't actually see it ever close readfd or chanfd. I don't think MpegRecorder? is currently being destroyed (I see the fds increment). I'm attaching the log, I've truncated the end (the death spiral, apart from the device name cycling it goes on and on and is really very boring).
The debugging output I added was for each real open (not the dummy mpeg file), and each real close (as well as one for ~MpegRecorder?). You can see that opens are logged, it never closes and you never see ~MpegRecorder?.
comment:3 Changed 19 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Is this with a framegrabber card? (Wendy reported tuning problems with a bttv)
Can you generate a log with "-v record,channel"
Also upgrade to the latest SVN, I don't think this is a RingBuffer? shutdown problem, but I added a little more debugging output in the RingBuffer? shutdown changes commit.