My myth box is having several problems but before I start messing with stuff, I wanted to do a backup but unfortunatly thats not working either. When I run mythbackup, it gets all the way through and fails on the verification steps. I'm running r5d1 so this is the new backup script of course.


The other problems are varied and I think may be because I did an upgrade to ressurect a crashed system. The big ones are that randomly during playback, the video will jump like it missed a few frames or something but the sound continues normally which makes the sound off from the video. Saving the position and exiting and reentering the video gets it back on sync.

The other is that at seemingly random times on menu changes the frontend will either quit or freeze. Restarting the frontend sometimes fixes this but usually ends up with it just freezing again soon. I've setup mbemon so I'll have to see if that helps some.

I really have no idea what the problem is or where to start. My first hunch is that it may be hard drive or ram problems but I'm not entirely sure how to check them and I'm not entirely comfortable doing trial and error without a valid backup. I flagged to do a fsck on statup but because of the startup progress bar screen, I couldn't see the results and am not sure where a log of that would be if any.


Any help on any of these would be greatly appreciated, thanks.

Here's my feedback:

1. The warning you are getting from the backup script probably means that there is some other process running while the backup is running, and that other process is fiddeling with the files in the directory identified. I don't have a /home/mythtv/.aptitude directory, so I don't know what it's about, but the path names implies it is a temporary directory so it probably doesn't matter.

2. mbemon won't solve problems that are persistant, frequent and unrelated to failures of the backend process. mbemon probably will not help you with this problem.

3. I suggest you check various log files include the front-end log file, system log files, etc. There is an article in the wiki that explains the various log files. http://www.knoppmythwiki.org/index.php? ... ngLogFiles

4. Check to make sure your database doesn't have broken tables -- read the sticky here http://mysettopbox.tv/phpBB2/viewtopic.php?t=1043


Marc

Thanks for the reply.

1) I was hoping that it was just a garbage folder but I wasn't sure. So the backup should be fine then except for that one folder?

2) I had assumed, possibly incorrectly, that the frontend problems were associated with backend crashes as it usually did not restore it even with relaunching the frontend.

3) I found a couple things in the logs that may be related.
In /var/log/mythtv/mythbackend.log
a bunch of these:

and these:

etc...

Nothing else jumped out at me as being related.

4) Ran through that and found no broken tables.


Thanks again for your help.

That backup error should be harmless. Looks like you were running aptitude in another window or something.

In general you should be running the backup on an idle system. It shuts down the DB and the backend server as necessary, but since it runs from the frontend menus we can't knock the system down to single user mode. As a result we have to leave it up to the user not to do other stuff on the system that could interfer.

I did a google serach on "Warning MVs not available " and found the thread below. The subsequent message is a response where someone feels that it may be caused be poor signal.

Marc


http://www.mythtv.org/pipermail/mythtv- ... 40253.html

http://www.mythtv.org/pipermail/mythtv- ... 40259.html

So Tuesday this machine actually completely died and the backend refuses to startup even after an attempt to re-upgrade. Because of all the problems it's been having I don't think its worth all the effort to fix it and I'll just nuke the whole system and start over.

On that note, here's a question. I'm thinking of pulling out the existing recordings out of the pretty folder (either using samba or burning to dvd) then later restoring them to the video folder so as not to completely lose them but is there a set of instructions on how to back up the original .nuv's and reinsert them into a brand new database to maintain the show information?

You can do this with nuvexport but it was a one by one operation last time I played with it.

You can also do a DB backup and extract the information from that. The dump format used is executable SQL statements which reinsert the records into the DB. All you need to do is filter out the commands for the tables that you need and feed that into mysql. There is some discussion of this in the "how to take advantage of the new backup and restore" sticky thread under the "Hints & Tips" topic.

My backup before upgrading from R5B7 to R5E50 also "backup failed" but the upgrade worked. It was scary though. It failed on the verification step of backup as well. I would feel better if I could get the voice "backup verified."



How do I do these?

1. Run backup on an idle system:
okay, so I run the backup at a time when there is no recording, no commercial detection jobs, no transcoding jobs, no mythfilldatabase.

2. Run from single user mode
okay, so I could exit the mythfrontend, then run "mythbackup" from commandline. I assume it will automatically stop mythbackend and mysql as necessary. Do I run as root or as mythtv user? How do I "knock down to single user mode?"

The backup should be run as root, the FE GUI does this using "sudo". You can go to single user mode using the following command from a console as root:

You should also be sure to stop any mbemon, or other magic restart processes before attempting the backup.

I generally just run the backup from an ssh session and don't have any problems. YMMV if you've got a bunch of add-on daemon processes or cron jobs or a multiple BE/FE setup with multiple users.

As always, reporting the exact errors you're seeing would let us tell you more about what you're doing wrong...

I am also running mythbackup from an ssh session. I don't know what mbemon is, but I made sure that I didn't have any restart cron jobs running (I used to have a home-grown one, but I think that was before I switched to KM). A ps aux for mbemon doesn't find anything.

I stopped the Myth backend before embarking on the upgrade process, but I'm finding that it has started up again after mythbackup has been run. This is the verification output I get at the end of mythbackup:



If I run checkbackup immediately after this, I get



And then I'm returned to the prompt.

My suspicion is that I can continue with the upgrade in relative safety, since I don't really care if I've missed a recording. Or do you (meaning the community at large) think this could create problems? (This is my first upgrade ever of KM.) I'm running R5D1 right now, and am anxious to get upgraded so I can switch to the new Schedules Direct feed. (I was going to upgrade this summer, but decided instead to wait until the listings issue had been addressed.)

BTW, what are "inuseprograms" in my first quote above?

It looks kind of like you've got several front ends running, or commflag or transcode jobs. I'd do a quick check for this (it may pay to disconnect the network if you've got remote FEs) and rerun the backup. If you want to discard the previous one you can use the rollback.sh script.

Also, there's no need to manually shut down the BE or the database, since the backup script takes care of that itself, along with restarting them when it's done. The big concern is having some kind of outside piece restarting the BE or fooling with the DB in mid process. I would have the script automatically shut down the FE too to help avoid this, but it could be the parent process of backup script, or the FE could be remote, or ...

Before starting the upgrade process I had shut down the FE (I'm only using the one machine for Myth), then the Back End before doing a full backup of the entire system. Then I ran mythbackup (with both still shut down).

I'll try letting mythbackup shut down the BE on its own (the FE is still shut down) when I get the next window of no activity (about 36 hours from now). As I said, there are no cron jobs (other than what KM sets up), so I'm not seeing anything that looks to me like it would be altering the database.

Re: rollback.sh, I've just been deleting the contents of /myth/backup before starting running mythbackup again. Am I missing something else that rollback.sh does?

You really shouldn't need to do all those things. The only reason i suggested knocking out the FEs is in cased you had a number of other FE boxes with other people using them. The scripts generally take care of this themselves.

You also shouldn't need to delete the contents of the /myth/backup directory. The modern backup scripts normally keep a roll over stack of up to ten old numbered backups. The rollback.sh script just pops the head of that stack which lets you discard a bad one without creating gaps in the numbering.

Given the differences with the jobqueue and inuseprograms my guess would be that you have commercial marking or transcoding jobs running at the time. If you haven't retried the backup at an idle time I would strongly recommend it.

Was finally able to get a good backup. Thanks for all the help