Migrate MythTV Recordings to a New Server

Want to install MythTV onto a new system, or install things from scratch on the same system? The big problem is loosing all your recordings and data.

It not as simple as just copying your recording files over. You need to have the database information about each file for them to work.

It's fairly easy to transfer your important database information to a new server. Here's how.

Migrate your MythTV recordings in 3 easy steps:

  1. Backup the important database information from the old database
  2. Copy the files into the new install directory
  3. Restore the database information into the new database

Step 1 - Backup your existing data

I've seen a couple different ways to do this in the MythTV documentation, both of which seem a little awkward. I think I have a better way, which has worked fine for me once.

Basically what we need to do is export the information about the existing recordings, previous recordings, and future recordings. This data will be imported into an already setup database on the new system.

mysqldump -u mythtv -p -t mythconverg record recorded \ 
oldrecorded recordedprogram recordedrating \
recordedmarkup recordedseek > recordings.sql

That's all a single command that needs to be run on the command line. If you use a different database user, substitue your username in place of "mythtv" after the -u argument. If you use a different database name, replace mythconverg with your database name.

That command, after prompting for your database password, will export all the data you need to migrate into a file name recordings.sql. This is the file you will need to import on the new server when we get to that step. How to copy the file will be an exercise for you to figure out, since each situation may be different.

Step 2 - Copy your video files to the new MythTV recordings directory

Again, each situation may be different in terms of copying files over.

One tip is to find where you think they are going to be recorded, then start recording a show to see if a file shows up there. If a file shows up in that directory then you've got the right place. Copy all your video files over.

This may take a while if you are going between drives or over a network, but you can import the database records while files are copying. When I migrated to a new system, it took about 8 hours to copy all my recordings over the network.

Until everything is copied over, you will just get an error if you try to watch a recording that hasn't been copied yet if you go ahead and import the recording data.

Step 3 - Import the recording data into the new database

Start by copying the recordings.sql file to the target server if it's not already there. Then all we need to do is import it to the target database.

mysql -u mythtv -p mythconverg < recordings.sql

Provide your password, and the recording data will be imported.

Watch Your MythTV Recordings

That's it. If everything went as planned, all your recording will be in your new system as if nothing had changed.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

2 Easy steps instead of 3...

In step 1, instead of creating the recorded.sql file, you can send the output of the sql query directly into the new database by piping it into another mysql command line.

From the NEW server's command line do:

newserver # mysqldump -h oldserverIP -umythuser -pmythpass mythconverg \
record recorded oldrecorded recordedprogram recordedrating \
recordedmarkup recordedseek | \
mysql -umythuser -pmythpass mythconverg

Hope this helps. :)

--
Bill Arlofski

MySQL Pipe

Bill's correct. I presented it this way because in many cases, and mine in particular, you might not have access to both databases at the same time.

Thanks Bill, I appreciate your feedback.

moving among different versions

In case you're moving recordings to a different version of MythTV where the database layout has changed, you'll get an import error if the number of columns doesn't match.

You can work around that by adding the "-c" (--complete-insert) option to mysqldump when exporting the files. It'll leave the missing column(s) blank, but at least you'll be able to import the data.

Moving files

I found the smbget command useful for moving files between two recent versions of KnoppMyth (R5F1 and R5F27, I think.) Neither installation had ftp. Type 'smb' and hit 'TAB' to see a short list of the smb commands available on your machine. I used user mythtv, and the only prep I had to do was use smbpasswd to set that users smb password on the old machine. Then I executed the smbget command from the new machine. Over fast ethernet I moved about a G every two minutes or so. Of course, doing it over IDE would probably be faster, but that requires a screwdriver.

thanks!

Thanks for this information! It helped me a great deal. Here's my one piece of advice in case others encounter this problem. I attempted to transfer recordings from an existing mythtv installation to another--which had already made some recordings. When I tried to run "mysql" to import the old database into the new, I got the following error:

ERROR 1062 (23000) at line 24: Duplicate entry '18' for key 1

So, I added "-f" to the mysql command, to force the import (and ignore any errors). eg:

mysql -f -u mythtv -p mythconverg < recordings.sql

This error was still reported, but the rest of the import appeared to work. I suspect that one of my recordings (at entry 18) did not get imported, but that's ok.

Anyhow, thanks for this website. It's a great resource.

thanks and thanks

thanks for the guide, and then thanks for the -f option. i had a duplicate error and this allowed me to get past it.

migrating mysql data and recordings

A question about this process. I originally had Mythbuntu v8.04.1 installed (on a 500gb drive). Now I have v8.10 installed (on a 1tb drive). I believe I should be able to mount the 500gb drive and copy the recordings from the old drive to the new drive. I am not sure about the db though. Will I have any problem opening the mythconverg db on the old drive and the new drive? Will my current install get confused and hit the wrong copy of mythconverg? My GUESS is that it should be ok but I'd REALLY like to NOT mess up my system now that it's running ok. I don't even actually know WHERE mythconverg is located on the drive... I dug around for it early on, but then it seemed it wasn't that important to know so moved on. I'm pretty new to Linux/Myth... so if I'm missing something obvious, feel free to point it out. Thanks.

One other thing

I went from one machine to another (different hostname). I had to update the hostname field of the recorded table in order to see my previously-recorded files. I ran mysql -umythtv -psecretPassword mythconverg; and executed: mysql> update recorded set hostname='newhostname' where hostname='oldhostname'; After that, I could see my old files.

How does mythtv know where the old recordings are?

Thanks for your helpful posting. I had a question: in my old mythtv, the recordings are in a directory /video while in the new mythdora 10.21 upgraded machine, recordings are saved in /storage/recordings. If I move my old files to the upgraded mythtv, does the new database look for the files in /video or in /storage/recordings? I.e., does the database record the location of the files? If so, how do I tell the updated mythtv to look for the old files?

Mythtv settings

Hey, Can I use this method for migrating mythtv-setup database (which is the settings table) too? i used mysqldump -u mythtv -p -t mythconverg settings > settings.sql to put the settings onto a file.... and then used mysql -u mythtv -p mythconverg < settings.sql when i run select * from settings query i can see the settings in the database. but when i run > mythtv-setup .... it still shows the old settings.... is this the right method to do it? Any help will be highly appreciated. Thank You Prerak Mehta

No, the MythTV database does

No, the MythTV database does not store the directory location for each recorded file. It just stores the filename, and then each time you play the video it checks all the recording locations you have defined. So you just need to move/copy your old files to (one of) the new recording locations, and then update the database like the article shows.

If your old database computer is dead

My old mythtv backend computer had a major hardware failure and would not boot. So I didn't have access to the old database to do a normal dump, just the database files on the old harddrive. This is what I ended up doing to import the tables. Note that you must have the same major MySQL version on both machines (like MySQL 5.x).

First I stopped mythbackend and mysql (these are commands for Debian squeeze, your system may be slightly different):

# /etc/init.d/mythtv-backend stop
# /etc/init.d/mysql stop

Then I temporarily renamed the new mythtv database, copied my old one in it's place, and fixed the file permissions to be the same as the new database files:

# cd /var/lib/mysql/
# mv mythconverg mythconverg-new
# cp -a /mnt/old-drive/var/lib/mysql/mythconverg .
# chown -R mythtv:mythtv mythconverg

Next I restarted mysql and did the database dump (now using the old database):

# /etc/init.d/mysql start
# mysqldump -u mythtv -p -t mythconverg record recorded \
oldrecorded recordedprogram recordedrating \
recordedmarkup recordedseek > ~/recordings.sql

Then I switched back over to the new database:

# /etc/init.d/mysql stop
# mv mythconverg mythconverg-old
# mv mythconverg-new mythconverg

And imported the setting into the new database:

# /etc/init.d/mysql start
# mysql -u mythtv -p mythconverg < ~/recordings.sql

Finally, I brought mythtv back up:

# /etc/init.d/mythtv-backend start
$ mythfrontend

And watched my old recordings. Yay!

Merging against an existing copy of the data

If you've already done this once, and now want to merge updates from the original into the copy again (perhaps to maintain an off-site backup), this procedure doesn't necessarily work anymore even with "-f" to force past primary key issues. The problem is that current MySQL versions lump all of the INSERT statements used to populate a table into one big one by default. If some of those entries are already in the table, as far as I can tell the whole statement doesn't execute--and it doesn't even show you an error during the restore when that happens!

The behavior now enabled by default is called "extended-insert". In order to bypass it, when doing the original mysqldump, add this:
--skip-extended-insert

And now you'll get a dump with each individual recording etc. as its own line. Bigger, and slower, but more useful for this case. Import a dump in that form to the new system with "-f" to force, and the key violations will just skip over the things you already had on the system. You won't have these giant insert statements that abort in their entirety instead.

I've found this little snippet:

echo "select programid,description from recorded" | mysql -u mythtv -p mythconverg

To be handy in resolving what recorded programs are in the databases of the two systems when you try to keep them in sync like this.

I had to migrate between a

I had to migrate between a version several years old into a new box(across different flavors of linux). The trick is, that mythtv-setup already has the ability to upgrade the database schema. So I simply copied the files from /var/lib/mysql/mythconverg into the pc and set the permissions to match. After I started mysql I noticed errors in the database so I ran mysqlrepair on that file. Then I ran mythtv-setup. mythtv-setup then prompted me to upgrade my database. A few moments later I am up and running again.

easy transfer

Fresh installation of ubuntu 10.04 Lucida on a new harddrive. Mythtv installed through aptitude. After using hours at channels scanning with Hauppauge Nova-T 500, I was happy to succeed out of the box with old recordings. They were on a separate xfs disk, which I mounted under /video/mythtv/recordings. I too copied the old mythconverg folder to the 23 versions newer mythtv installation. No mysql errors were visible, no re-running of mythtv-setup - and all recodings were available!

Old, out-of-date instructions

Per comments on the MythTV Users mailing list, this procedure is very old, and won't work any longer (and it has not worked for me).

I think it sucks that the MythTV devs seem so hostile to normal uses of the software*, but there you have it. Things like this are why MythTV is forever stuck in the geek ghetto, instead of in use in many homes like Boxee.

D

*by "hostile", I mean:
- making the user have to upgrade the Linux distro on their frontend for the simple mistake of irreversibly updating their MythTV backend.
- making it nearly impossible to retain recordings when replacing a backend machine.
- Providing misleading labeled buttons that will not work: i.e. "download channels from listing source" with OTA TV.
- Baffling the user with thousands of arcane options, rather than choosing a good set and eliminating much of the configuration.
- Requiring a user to run Mythtv-Setup on the backend machine (which may not have a monitor or even display capability) rather than allowing the user to configure the server from any front end or from the web.

Yes, I realize there are workarounds for all of these things. But why make it so hard for people in the first place?

In reality, MythTV is for guys and girls that like playing with the computer and solving problems, not for people who just want to watch TV.

I'm not a noob: I've built and struggled with 3 from-the-ground-up mythTV systems, starting from version 0.17 several years ago.

RE: Old, out-of-date instructions

Responding to the previous comment, these tips are NOT out of date and are valid, clearly the previous poster has had some issues with mythtv in the past. Regarding the points the previous posted raised; The protocol version of the backend you run needs to match the version of the frontend that is running, there is no need to upgrade the os, mythtv can be installed via a repository or compiled... The recordings are formed of 2 parts, the meta data and the physical files on disk, these need to be kept together which is whats being discussed here This seems clear to me, I'm sure a query on the mailing list or google will help clear this up if it's not understandable, in fact this is one of the areas were user input can have a direct affect on the software Some of the beauty of mythtv is the customizability, however generally the defaults work fine so there is no need to delve into the inner workings to get mythtv up and running mythtv-setup can be run from another machine by using the x forwarding functionality, ie "ssh -X backendIP" Regarding the final point, the wife won't use anything else now, even the kids can use myth. Once mythtv has been setup (which is getting so easy now with distributions like mythbuntu) you don't need to touch it.

Do a real backup and restore

Please see http://www.mythtv.org/wiki/Database_Backup_and_Restore and http://www.mythtv.org/wiki/Backend_migration for proper instructions. The instructions provided here for backing up the database can result in either a corrupt database schema or corrupt data, and are neither proper nor complete instructions for doing a partial restore on modern MythTV systems. And, the procedure for a partial restore is significantly more complex than a full restore and provides absolutely no benefit. Put simply, there is no such thing as "Migrating MythTV Recordings to a New Server." You copy the recording files to the same path on the new host, restore a full database backup from the old system to the new system, and change the host name and IP address in the database, if necessary. MythTV will take care of upgrading the database. And MythTV takes care of cleaning the old garbage out of the database every day that it runs.

thanks

I found the smbget command useful for moving files between two recent versions of KnoppMyth (R5F1 and R5F27, I think.)Door Lintels Neither installation had ftp. Type 'smb' and hit 'TAB' to see a short list of the smb commands available on your machine.

Wow, nice post,there are

Wow, nice post,there are many person searching about that now they will find enough resources by your post.Thank you for sharing to us.Please one more post about that..

Merging against an existing copy of the data

I have a master / frontend and slavebackend the slave is on a vpn and i am getting issue with it taking down the master backend so i am looking to make the slave it's own master backend and to rec shows and then move over the mpg files to the real master backend /frontend and update the data base so it knows about the rec shows. note the current master backend and slave config / setup. /var/lib/mythtv/cabletv the slave backend /var/lib/mythtv/cabletv i rsync the video to the master backend so it will not try to stream the video to the master backend.

What I don't fully grasp is

What I don't fully grasp is how you are not even more preferred than that you are now. You are just so intelligent. You know so significantly about this topic, made me consider about it from a lot of distinct angles. Its like people today arent interested unless it has one thing to complete with Lady Gaga! Your stuffs excellent. Keep it up!

Thanks for sharing all the

Thanks for sharing all the tips, I will most likely need this information so finding it now is perfect timing. I am not a software expert but I hope it will work without any complications. I have my operating system recently installed and every dll file extension is right on track, all I have to worry now about is the database.

remote control

I have a semi-related question. How long does moving from server to server take time wise? I envision it taking weeks and wreaking havoc on my laptop battery. I would like to upgrade my recording and have it customizable, but don't want to bog down my system in the process. If I'm going to use something like MythTV, it's going to have to be able to hold my substantial library of televsion shows and film.

how to move recorded tables from one mythtv server to another.

http://pangscripts.hg.sourceforge.net/hgweb/pangscripts/pangscripts/file/2a4af6fc1b27/mythtv/makesql.sh
Tue May 17 09:56:37 2011 -0500 (16 minutes ago) changeset 2 2a4af6fc1b27 parent 1 e94dd1c7c875 permissions -rw-r--r--

GLPoxnWchDftFTaa

Glad I've finlaly found something I agree with!

nYMwAoTkhsjFVKuS

That's 2 cleevr by half and 2x2 clever 4 me. Thanks!

dcGSrzcgFLqwfgyOrF

Kewl you should come up with that. Execllent!

vFyvlJZkBXGmzNliN

Whoveer wrote this, you know how to make a good article.

bGSzpzlmOoIKHOWyhED

You're the one with the brains here. I'm wahtcing for your posts.

iNhJsCwsBIKFT

Thanks for sharing. Always good to find a real eepxrt.

mTVikMpTAHwGX

Whoever wrote this, you know how to make a good atirlce.

CxZvfvIPxoq

You raelly found a way to make this whole process easier.

YWZlYKrRnIci

There is a critical sohrtgae of informative articles like this.

How to migrate the MythTV video metadata

For anyone looking to do the same thing in this guide, except with only the metadata for videos... here are the tables to backup in step 1: videocast videocategory videocountry videogenre videometadata videometadatacast videometadatacountry videometadatagenre Make sure that the folder structure for your migrated videos is the same! This data is stored in the videometadata table. Note that in theory, the path or mount point to your 'videos' folder does not matter... only everything underneath it. For example: My videos are stored in: '/media/terabyte/Videos' In step 2, I would copy everything underneath this to my new system, keeping the underlying structure the same. To see what paths are stored in your videometadata table, try this: mysql --database=mythconverg --user=mythtv --password=__YOUR_DBPASS__ --execute='SELECT title, filename FROM videometadata;'

.... Here's the same thing, but formatted better....

Sorry for the duplicate post.... but having that all on one line is terrible to read!!

----------------------------------------------------------------------

For anyone looking to do the same thing in this guide, except with only the metadata for videos... here are the tables to backup in step 1:

videocast
videocategory
videocountry
videogenre
videometadata
videometadatacast
videometadatacountry
videometadatagenre

Make sure that the folder structure for your migrated videos is the same!

This data is stored in the videometadata table. Note that in theory, the path or mount point to your 'videos' folder does not matter... only everything underneath it.

For example:

My videos are stored in:

/media/terabyte/Videos

In step 2, I would copy everything underneath this to my new system, keeping the underlying structure the same.

To see what paths are stored in your videometadata table, try this:

mysql --database=mythconverg --user=mythtv --password=__YOUR_DBPASS__ --execute='SELECT title, filename FROM videometadata;'

qASfYXANJAuI

ZiWaTL As I have expected, the writer blurted out..!

oUHMsFnIXdwfGGLyFk

X9YIJY Right from this article begin to read this blog. Plus a subscriber:D

ApBchupewoby

t57rK7 Thank you, a very interesting note!!...

Thanks for the nice blog.

Thanks for the nice blog.

KQEVWmDJ

BpGkdc

QtMrca

vLTbvM

skjjrPqShpMWaklDn

YKoL81 Thanks for the article! I hope the author does not mind if I use it for my course work!....

UtQZFuGJVXrhgCR

Qg2X0s Thanks:) Cool topic, write more often! You manage with it perfctly:DD

mTwUILoeXssCLZUpT

kezrcn comment1

TXmztEgHYFxCIVGX

yFoljz comment6

HiXzDUREvoNLGfeJfjM

xvLaSP Sorry for the off-topic, could you tell where I can get such a nice pattern for my blog ?!....

QqXMGqftAt

bmpvb9 Scribbler, give me a student's record-book!))))

ejxhqAMazhArx

A unique note..!!