[mythtv-users] "corrupt" recording causing fast forward to churn the disk then stop playback
robert.macaulay at gmail.com
Thu Mar 15 04:17:34 UTC 2007
I believe we ended up with a bad recording. Probably caused by the recorder
thread updating the database bug. Right around the start of the playback, I
got this message in logs
Mar 14 21:30:28 mythbackend kernel: ivtv0: Cause: the application is not
reading fast enough.
Mar 14 21:59:47 mythbackend kernel: ivtv0 warning: CX2341X_ENC_SET_VBI_LINE
took 163 jiffies (1000 per HZ)
Mar 14 22:30:14 mythbackend kernel: ivtv0: All encoder MPEG stream buffers
are full. Dropping data.
The setVBILine was new. I do not have CC turned on. It is a SD recording.
And VLC has no problems seeking through the stream.
Either way, I've seen this before, and there is usually a few seconds of
jumble, and then all is well. For this particular recording, it has taken
out the ability to fast forward. Shortly after starting the program, I
attempt to fast forward(30 sec, 10 minute, either have the same effect). The
playback freezes, the OSD says functional, hitting i brings the OSD up, so
its not a frontend lockup. The backend disks start churning for about 20-30
seconds, then the playback stops and we're dropped back to the recordings
screen. Here are the messages from the frontend.
2007-03-14 22:44:38.440 TV: Changing from None to WatchingPreRecorded
2007-03-14 22:44:38.447 Using realtime priority.
2007-03-14 22:44:38.626 Video timing method: SGI OpenGL
2007-03-14 22:46:04.562 WriteAudio: buffer underrun
2007-03-14 22:46:04.576 TV: Attempting to change from WatchingPreRecorded to
If you don't fast forward, the playback is fine. I tried on my remote
frontend, but it causes the network interface to go offline(r8169 just
barely makes onbard nicwork, buying a new nic tomorrow). ExtraAudioBuffering
is on. Seems like seeking in this file is causing some sort of problem.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mythtv-users