Out of the blue I am having problems with playback on my R5D1 system. I haven't made any changes to the system recently. For system specs, see the Athlon in my sig. All of my shows are HD recordings, and the problem is occurring on all of them. Here is a description of the problem:

I start playing back a show, one of two things happens:
1) The screen is just black with audio, so I exit back to the menu; I see the picture flash briefly before the menu comes up.
2) Playback starts fine, but if I skip forward (either from remote or auto commercial skip) the hard drive goes crazy, and there is a long pause (up to 30 seconds). If I try a large skip forward (down arrow), it takes at least 30 seconds. With a short skip (right arrow), the pause is probably about 5 seconds.

After skipping forward a few times, the picture will freeze and audio will continue. The Audio will get faster and faster, until voices sound like "the chipmunks". I finally have to kill mythfrontend and restart it.

I checked SMART status on my hard drives (using "smartctl -a /dev/hdx"), and both are fine. I have 2GB free on root, 13GB free on /myth, and 60GB free on my second drive (mounted at /myth/tv).

I decided to just do an auto upgrade of R5D1 over the top of my R5D1 system to try to correct this problem. The auto-upgrade went smoothly, but the problem persists.

Other stuff I checked:
I checked /var/log/messages and syslog
-didn't find any strange messages, and nothing new pops up if I tail them while trying to watch a show
-I looked at my mesg, but there was nothing unusual in there

I should also note that if I connect my frontend box and try to watch a show, I have the same problems.

UPDATE: Additional things I've tried:
1) Scanned for badblocks with "e2fsck -c -f /dev/hdd"; no problems found
2) Forced fsck of all disks at boot with "shutdown -r -F now"; again, no problems found
3) Tested disk performance with "hdparm -Tt /dev/hdx"; both disks were running full speed

Any suggestions/ideas?

_________________
Mobile Athlon XP 2600 on A7N8X-E, pcHD2000, pcHD3000, FX5200 128MB (production) R5.5
EPIA Via EDEN 800Mhz Mini ITX, HD2000 (testing)
AMD Geode 1700 CPU, NVidia 6600GT, (testing)
HDHomerun (testing)

I decided to try logging mythfrontend during playback to try to find out more information about what's going on.

I ran mythfrontend like this:

[code]mythfrontend -v 1 > mythfrontenedlog.txt[/code]

When the video freezes and I get the chipmunk audio, here's what I see:

[code]2006-10-09 22:32:41.916 NVP::AddAudioData():p1: Audio buffer overflow, audio data lost!
2006-10-09 22:32:42.022 NVP::AddAudioData():p1: Audio buffer overflow, audio data lost!
2006-10-09 22:32:42.098 NVP::AddAudioData():p1: Audio buffer overflow, audio data lost!
2006-10-09 22:32:42.207 NVP::AddAudioData():p1: Audio buffer overflow, audio data lost!
2006-10-09 22:32:42.423 NVP::AddAudioData():p1: Audio buffer overflow, audio data lost!
2006-10-09 22:32:42.467 NVP::AddAudioData():p1: Audio buffer overflow, audio data lost![/code]

This repeats forever, and I have to kill mythfrontend (exit on remote or esc on keyboard will not get me back to the menu).

When I am having the long pauses during fast forward, I see stuff like this:

[code]2006-10-09 22:29:47.469 NVP: Prebuffer wait timed out 10 times.
2006-10-09 22:29:49.668 NVP: prebuffering pauseAAAAAAAAAAAAAAAAAAAAAAAAAAAAuLL
2006-10-09 22:29:59.117 NVP: prebuffering pauseALAAaALUAAAAAAAAAAAAAAAAAAAAAAA
2006-10-09 22:30:04.035 NVP: Prebuffer wait timed out 10 times.
2006-10-09 22:30:05.974 NVP: prebuffering pauseLAAALAAAAAAuAAAAAAAAAAAAAAAAAAA
2006-10-09 22:30:08.604 NVP: prebuffering pauseuAAAAALAAAAAAAAAAAAAAAAAAAAALAA
2006-10-09 22:30:10.801 NVP: prebuffering pauseAAAAAAAAAAAALAaAAAAAAAAAAAAAUAL
2006-10-09 22:30:17.511 NVP: prebuffering pauseAAAAAAAAAAAAAALAAAUAAAAAAAAAAAL[/code]

I've also noticed the following in the terminal I ran mythfrontend from. This seems to happen when I fast forward (during the long pause):

[code][mpeg2video @ 0xb6fee620]warning: first frame is no keyframe[/code]

There is some good news though: some of the new shows that have recorded yesterday/today are playing back fine. I only wish I knew why.

_________________
Mobile Athlon XP 2600 on A7N8X-E, pcHD2000, pcHD3000, FX5200 128MB (production) R5.5
EPIA Via EDEN 800Mhz Mini ITX, HD2000 (testing)
AMD Geode 1700 CPU, NVidia 6600GT, (testing)
HDHomerun (testing)

I finally have a solution. It looks like my "recordedseek" table must have somehow gotten screwed up, and this caused mythfrontend to have major problems when fast forwarding through shows. The following command will fix the "recordedseek" data for all shows:

mythcommflag --rebuild --all

Warning: This took a number of hours to run, as it has to scan through every single show stored on the Myth box.

I found the information here:

http://www.gossamer-threads.com/lists/m ... ers/230416

_________________
Mobile Athlon XP 2600 on A7N8X-E, pcHD2000, pcHD3000, FX5200 128MB (production) R5.5
EPIA Via EDEN 800Mhz Mini ITX, HD2000 (testing)
AMD Geode 1700 CPU, NVidia 6600GT, (testing)
HDHomerun (testing)

thanks for posting those links.

I had this problem today, a few weeks of upgrading to R5D1.
My symptoms were a little different. skip forwarding would actually make it go to the start of the program, but it was corrupted seek tables.

I was

A nightly optimize_mythdb.pl is recommended. so I think I will add that.

Thanks for the tips. This happened to me, possibly self-inflicted.
I had moved a home movie (halloween webcam avi) from my PC to /myth/video without checking disk space first. Everything recorded last night after that time had seek problems. I didn't realize it but the disk had finally filled up (I just upgraded disks last week and they've been gradually filling).
I know that Myth can deal with disk filling as it expires programs to meet the need. But by stealing another 500MB of disk unexpectedly, I may have set up a bad situation. Or, maybe it was just Halloween. I'm just mentioning "disk full" as a possible contribution to the seek corruption.
My commflag is rebuilding the table now, so I don't know if I've solved it or not, but I expect that it'll be ok.
I also ran optimize_mythdb.pl prior to mythcommflag --rebuild --all

Update: This KIND OF fixed it for me, but it's still a bit whacked. The skip/jump work now, but the time scale is "off". Some recordings think they're only 2 minutes long, so what is supposed to be a 30-sec skip is more like 15 minutes. Something went coo-coo with the commflag, but I can probably live with it.
I'm on .19, so this may be something that would be fixed in 0.20. I know there's a bug out there for 720P recordings that think they're twice as long as they are while recording, and this kind of reminds me of that.

Hmm. I don't even HAVE a recordedseek table. Is this bad? I'm at 0.19.

Ok, looks like prior to .20, it was "recordedmarkup". I've got that.