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<br><br>Mar 14 21:30:28 mythbackend kernel: ivtv0: Cause: the application is not reading fast enough.
<br>Mar 14 21:59:47 mythbackend kernel: ivtv0 warning: CX2341X_ENC_SET_VBI_LINE took 163 jiffies (1000 per HZ)<br>Mar 14 22:30:14 mythbackend kernel: ivtv0: All encoder MPEG stream buffers are full. Dropping data.<br><br>
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.<br><br>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.
<br><br>2007-03-14 22:44:38.440 TV: Changing from None to WatchingPreRecorded<br>2007-03-14 22:44:38.447 Using realtime priority.<br>2007-03-14 22:44:38.626 Video timing method: SGI OpenGL<br>2007-03-14 22:46:04.562 WriteAudio: buffer underrun
<br>2007-03-14 22:46:04.576 TV: Attempting to change from WatchingPreRecorded to None<br><br>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.
<br><br>Robert<br><br><br>