Opened 21 years ago
Closed 21 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 by , 21 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
comment:2 by , 21 years ago
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 by , 21 years ago
| 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.