I'm using D1. Have not done any recent changes except to allow mpg to use the same viewer that I had set for avi.

1 gig ram
1.8 ghz amd
1 hauppage 250 tuner
nvidia video card

System works and has since october. But last night I had a weird situation occur that seems to be affecting it now.

The machine quit out of mythtv back to the knoppmyth logo and froze. Had to reboot with the reset switch.

On going back into mythtv, at 10:02, went to watch 30 rock. It had finished recording at 9pm. But there were 2 weird problems:

When I skipped past commercials, the amount of time of the recording showed as 12 hours and a few minutes. It also scrambled the video for 2 seconds before resolving into the normal video. It looked pixelated for that 2 seconds, as if the screen were showing a video on an 80x40 display.

I quit and restarted the program to see if it would correct itself, but it didn't.

I finished watching the show, and it ended at the correct time even though it seemed to show another 11 hours and 30 minutes. Deleted the show and watching another.

Every program seems to be doing this. If I skip ahead, it pixelates for 2 seconds before resolving to the picture.

I checked the status on the menu, and it's showing 98+% memory used, 1.6% free. Even restarting mythtv from the menu doesn't seem to help.

I did notice one thing on restarting...I saw the words budget flash past the screen.

I'm going through the log files right now trying to figure out what's wrong.

In the /home/mythtv# cat .xsession-errors file, I'm seeing a few:
/etc/gdm/Xsession: Beginning session setup...
Failed to load groupfile: (doesn't say what groupfile is for though.)

2007-02-02 14:05:37.669 Connected to database 'mythconverg' at host: localhost
Could not initialize /dev/input/js0
open: Permission denied
ioctl JSIOCGAXES: Bad file descriptor

SIP listening on IP Address 192.168.1.102:5060 NAT address 192.168.1.102
SIP: Cannot register; proxy, username or password not set

The only thing I can think of is that I've recently started using bitvise tunneler to connect to the mythtv box from my windows box as a graphical ftp program, but it's been at least a week since I did.

Anyone have any ideas? What should I look for? I'm just trying to figure out where to start looking.

I *may* have narrowed down the problem.

The housekeeping process seems to be repeating. The code below seems to be repeating every minute or two.

5 Query UPDATE recorded SET filesize = '655373576' WHERE chanid = '1057' AND starttime = '2007-02-02T15:00:00'
070202 15:17:01 14 Connect mythtv@localhost on mythconverg
14 Query SELECT data FROM settings WHERE value="RecordFilePrefix" AND hostname='mythtv'
14 Query SELECT * FROM recorded where recgroup != "LiveTV"
14 Quit
070202 15:17:02 5 Query INSERT INTO recordedmarkup (chanid, starttime, mark, type, offset) VALUES ( '1057' , '2007-02-02T15:00:00' , '2007' , 6 , '655640476' )

Well, I think I figured out part of what's going on.

The recordedmarkup table has no fields.

Edit: correction, the recordedmarkup file can't be opened by mysql.

Obviously the file got mucked up when the system crashed.

Now I just need to figure out if I should drop and restore the table, if I even can, or if I need to do something else.

I renamed the OS recordedmarkup.* files and recreated the table.

Had to restart mythtv again after that because it continued to loop, although it dropped to 65% utilization. I think it didn't attach the table because it hadn't existed when I recreated it.

On restart, it dropped further to 35% utilization, but the weird pixel issue with playing recorded scheduled tv still occurred. Turns out that the backend mysql process is still looping, but for other stuff now.

At least the housekeeping stuff seems to not be looping any longer.

I've set mythtv to record some tv and also set it to redo the commercial skip for a program it recorded last night. I'm theorizing that the pixel issue is due to missing data for the programs. At the very least, it will give me more data on what's happening either way.

I'm sort of surprised that mythtv didn't detect a failure on inserting/updating rows in the recordedmarkup table though. The error file is still empty. I'm guessing if it doesn't do failure checks on inserts, that mythtv self-repairing it's data is probably unlikely. I'm just hoping I won't need to wipe and reinstall to fix this.

Edit:
Gah. It's still doing housekeeping after all.

Getting closer to solving this thing.

Noticed that ALL shows that were already recorded have long amounts of time. Scrubs showed as over 11 hours. Even shows from Wednesday are having this problem. But new recordings recorded Friday are ok.

I'm reasonably sure that there's a mysql table with bad data. I just have to trace it down.

I could just watch the programs and delete them as I normally do, but some weird things were still happening. Scrubs, 11 minutes or so in, froze on an image and started playing just the sound at an double the speed. At least, it started at double, but finished at probably 20x. Couldn't interrupt it or anything. Let it finish and then jumped back into the program.

I *may* have accidentally hit the fast forward button, but I'm not sure.

Weird weird things.

The recordedmarkup table is kind of critical, especially with mpeg2 files. While the commercial marks aren't a big deal and can be reproduced given a bit of CPU time the start and end anchors that locate the first and last keyframe in the stream are a much tougher proposition. Here's how I solved this problem after a crash with an experimental version wiped my recodings table (but fortunately didn't damage the files) and a bunch of other stuff.

- Restore from your most recent DB backup. This will get you your settings and the like. With luck it will get you a fair percentage of your old recordings as well. Note that anything which has been editted since that backup will need special attention.

- Use myth.rebuilddatabase.pl to get the recordings back in the DB. This is kind of tedious but be careful to get the info as close to correct as you can. I blew a couple and it toook a certain amount of manual poking at the DB to get them back where they belonged

- Run the mythcommflag utility on the affected recordings to do what it can. For some recordings this is enough to get them back in decent shape.

- Finally for things where the seek tables and lengths still seem to be bogus run the lossless transcoding. If you do this without cut points it doesn't actually change anything, but it will reconstruct the anchor points and recalculate the length.

Well, running the commercial flagging option from the guide didn't fix ER, but it did update the data in the recordedmarkup table for it.

Or at least it seemed to. I have to go verify it still, but ER still shows as too long and screwy. As long as I play it straight through, it's fine though.

The recordings themselves are perfectly fine though. It's just some of the data in the tables that are whacked. Should be no reason why one couldn't simply run a program that goes through the program as if it were being recorded again.

I'm gonna poke around in the data and see what I can do. I don't know what myth.rebuilddatabase.pl does yet but I'll examine it. It's possible I can use something in it to just reprocess each recording. Since I don't really have that many recordings, that wouldn't be a problem for me.

Thanks tjc

That's the whole point of the lossless transcode trick. Try it. It should fix the recordings right up.

Hmm. Something isn't configured correctly then because I tried transcoding a show and it didn't fix it.

I'll try it again on another show.

One drawback to the transcoder is that if I use it, I can no longer burn it to dvd. At least when I tried before, it would fail if there were any transcoded programs in it.

That's odd. Over the summer I was burning DVDs of "Meerkat Manor" for a friend at work, using recordings that I'd already commercial cut with the lossless transcoding. I was using the "do not re-encode" option since they were already clipped, but otherwise it was flawless.

I'm sure it's just my own configuration. I've never been too worried about it, since normally I never needed the transcoding option. If I wanted to burn it to dvd, I wouldn't commercial cut it until that point. If I didn't want to burn it to dvd, I wouldn't bother commercial cutting it.