Re: Ticket #2335: LiveTV hangs when a recording is finished and a new on starts (no channel change)

On 7/26/07, Nick Morrott <knowledgejunkie [at] gmail> wrote:

Another issue I have noticed is that when a completely recorded program transitions without freezing (the key problem), a new ringbuffer is not (always?) created and Myth does not start or even update the recording with details of the new program but carries on using the old recording file. When I entered LiveTV when a program was already underway, the next program transition was successful. In my testing I entered LiveTV at 0926, and LiveTV successfully transitioned to the next program at 0930, using a new ringbuffer and updating program details accordingly. However, when this show (0930-1000) finished, at 1000 the recording again continued without freezing, but continued to use the same ringbuffer file from the 0930-1000 show. When I backed out of this show at 1007 and looked at the recordings list, instead of showing one entry for 0930-1000 and another for 1000-1007 (the next program), there was only a single entry with duration 0930-1007 with the details relating to the 0930-1000 program. I'm sure this will probably cause some issues if a user decides to try and record the 'new' program when it is still using the old ringbuffer.

I've been seeing this problem as well as the freeze on transition issue for the last month so. The freeze on transition is very consistent, however the problem of not creating a new file on transistion is very intermittant and has caused quite a problem as it has created files over 30GB when LiveTV was left on over night, resulting in the system running out of disk space and crashing myth. There were a mix of non-expirable shows, expirable shows and LiveTV plus the slave backend OS on a 120GB drive - so once the auto-expirable shows were deleted it couldn't delete anything else. So I don't think that the issue you found is due to Shane's patch since I've been seeing it for a while as well. I hope to try his patch this weekend as the entire family appreciation factor has gone down with the LiveTV freezes.

Are you sure about that? My rig uses the same transition type for all recorders (IVTV, V4L, DVB all use discont = 0), at least the log says so.

I think so, but you can know for sure by looking in the frontend log. If there are signs of a player reset occurring then the switch was discont. Should see FileChangedCallback for continous. eg. It's discont if you see this type of stuff with -v playback VideoOutputXv: ClearAfterSeek() VideoOutputXv: DiscardFrames(0) VideoBuffers::DiscardFrames(0): AAAAAAAAAAAUUUUUUUUUUUuuAAAAAAA VideoBuffers::DiscardFrames(0): AAAAAAAAAAAAAAAAAAAAAAaaAAAAAAA -- done VideoOutputXv: DiscardFrames() 3: AAAAAAAAAAAAAAAAAAAAAAaaAAAAAAA -- done() The discont'ness can be overridden later on, so the backend log is not reliable for that.

Still, I only get freezes (EVERY time) on my IVTV cards, but not on my V4L and DVB card.

Yeah, same here. Unfortunately it's beyond me to do much more useful debugging on the continuous transitions. Hmm, I wonder if they have ever been highly reliable? Shane

After some more testing, I must agree with you, Shane. I cannot trust the backend regarding discont.
I compiled mythtv without your one-line workaround, so in all tests below the backend reports discont = 0 (continuous recording)
I have attached some log files to this mail

Using the DVB card for recording, I have seen both continuous and discontinuous switching on the frontend - it seems that sometimes (not everytime) the frontend ignores the discont = 0 and resets the playback. For some reason I got five switches in a row at one time. Don't know if that was a different bug, and it doesn't seem related to this.

mythtv-DVB-continuous.txt
mythtv-DVB-multiple-changes-ignoring-continuous.txt

To be continued...