moving recordings to new PC

[jimls]

Have mythtv 0.27 with a bunch of recordings. Have a new PC with ver 33 configured and working with different IP (and not running at the same time as old machine that is still running). My plan is to pick a time when I have no recordings scheduled and:
shut down front and back ends on both machines
run mythconverg_backup.pl to back up database
copy recordings from old machine to new
run mythrestore_backup.pl to restore database (a bit fuzzy on the deleting the existing db and other details)

I have read the wiki on backup and restore and am a little unclear on things. I would like to put the machine at the old IP but that isn't required.

When I restore I don't want to overwrite the setup other than putting the recordings in place - don't need to replace the tuner details and other setup. I'm not clear if myrestore_backup.pl will overwrite other settings such that I have to reconfigure the back end again.

Probably making this harder than it needs to be...

[white_haired_uncle]

Probably making this harder than it needs to be...

Yes, you probably are.

If you were to backup/restore the database first, then install v33 on the new machine it'd probably go a lot easier. Especially if you keep the hostname/IP. You'll still need to delete and re-add your tuners, most likely add storage groups, and probably update your channel guide if you use SD, but you'd have to do that anyway.

[jimls]

I was going by this which seems to match my plan:
https://www.mythtv.org/wiki/Backend_mig ... ng_machine

You say to backup/restore the data base first. I used Mythbuntu Control Panel which sets up the database program as part of the install and it appears the normal mythtv package also does that so how do I restore the database first with no database program installed? Is there some detailed guide on what you are suggesting?

[white_haired_uncle]

That link looks like it should work. I've never used MCP, so I don't know where it would fit in, but I'm sure someone will.

If you follow that link, then to the part about restoring the database there's a couple sections on doing a partial restore. That's where it sounded like you were wanting to go (just restorre recordings, not tuners/etc). That's what I was recommending you avoid.

[kmdewaal]

I recommend deleting all capture cards and then creating and configuring them again. This is a fairly trivial operation and it prevents issues that could arise from using very old configuration data. We try to keep everything always compatible but there are limits to everything.
Creating and configuring capture cards is described as part of this Wiki page https://www.mythtv.org/wiki/Channel_Scanning

[PhilB]

Hi,
not a job we do very often!
I did a v0.27 to v32 to new hardware last year and a v32 to 34 a month or so ago. This was how I did 0.27 to v32. I used xubuntu.

Get your new system running satisfactorily. Use a new hostname (mine were old='myth', new = 'myth2'). That way I could run both together on the same network.
Get utilities working (editors etc).

I installed mythtv with MCP. Check it records, plays back, gets program data etc and that you are happy with it. No rush over this part.

Put any utilities you may have had with the old system (eg system event scripts) in place. It helped that I had written a little utility to backup these to external media (NAS) and restore them complete with with right ownerships and permissions.

Delete all your test recordings.

Stop the backend and prevent it from restarting on reboot:

Code: Select all

sudo systemctl stop mythtv-backend.service
sudo systemctl disable mythtv-backend.service

Copy recordings across. (actually, I did a quick trial run with just a week's recordings, then repeated with all. Again, no rush over this!).
Copy your recent database backup across.

Restore database. Sample script:

Code: Select all

#!/bin/bash
FILENAME='mythconverg-1317-20221204224118.sql.gz'
sudo /usr/share/mythtv/mythconverg_restore.pl --drop_database --create_database –directory
/var/lib/mythtv/db_backups --filename $FILENAME

If backend hostname is different then also:

Code: Select all

sudo /usr/share/mythtv/mythconverg_restore.pl --change_hostname --old_hostname="myth" --new_hostname="myth2"

Note: the database password remains as created by MCP and found in config.xml files - it does not change and adopt that in the backup.

Run backend setup and allow it to upgrade schema from 0.27 to v33. May need a reboot or two.

Configure audio, capture cards, recording locations etc. retune it.

Restart backend and allow it to restart on reboot

Code: Select all

sudo systemctl start mythtv-backend.service
sudo systemctl enable mythtv-backend.service

run find_orphans
job done!

For the v32 to v34 upgrade I swapped out the small SSD with xubuntu, database etc for a new one (only £22) and mounted the big recordings disk so didn't need to change hostname or copy recordings - just database backups and odd utilities..

Hope it all goes smoothly. Please feed back for the benefit of other subscribers.
Phil

[jimls]

Thanks Phil! I will give that a try and post how it goes but it may be a bit before I get a chance to do it.

[jimls]

Things mostly work. I was using LIRC on the old system with a media center USB IR receiver. A few of the keys work on the new system so I think it is just the key mappings for the non-working keys that need adjustment. Will have to figure out how to adjust those. Or maybe just select a standard setup on the IR remote. The other issue is the screen display is squished into the upper left corner. That's likely because I started the system before I connected the monitor so it didn't set it up right. Need to figure out how to set that to proper size for TV so the system can start without the TV being on. Or maybe the TV doesn't go completely off and still responds with screen size on the HDMI port - need to figure out some things...

[jimls]

Phil,
Can you give me more detail on how you transferred a weeks worth of recordings to test. Just copy based on file dates? Did you transfer the whole database? Thinking that would be good for me to try before I move the whole batch. I probably should delete a bunch of old recordings to reduce the files to transfer. It's huge at this point.

[PhilB]

Hi jimis,

Well your setup might be different but I didn't need to do anything special.

On your old system,

Code: Select all

cd /var/lib/mythtv/recordings
ls -l *_2023071*.ts

will list all recordings from 10 July to today 17th

Code: Select all

ls -l *_202307*.ts

will list all of july 2023.

My destination drive was in a usb caddy so I plugged it in to the 'old' system, mounted it, cd to the new folder then copied:

Code: Select all

cp /var/lib/mythtv/recordings/*_2023071*.ts .

You might have to sudo that.

When you re-connect the new drive to the new system you'll have to set ownership and permissions:

Code: Select all

sudo chown mythtv:mythtv *.ts
sudo chmod 644 *.ts

Yes, I imported the whole database without any edits - the older recordings just show as unavailable. If a purist you could find orphans but for a test it just wasn't worth it.

Note that the filetype may be different - on my old system they were .mpg's but with the new one they are .ts. Check which they are with your system.

Hope this helps.
Phil

[jimls]

Having some trouble with the database restore. I did a backup on the old box and moved it to the new box. Also moved some recent recordings. But the restore command seems to be having trouble with the backup directory.

I made a script file as suggested to substitute the proper file name and directory but got errors about the directory directive.

Code: Select all

The argument you supplied for the database information file is invalid.
If you were trying to specify a backup filename, please use the --directory
and --filename arguments.

So I tried with double dash. Still no luck.
So I made a backuprc file. Now I get a "DBBackupDirectory not specified..."error.

Does it matter what user I run the restore script from? Normal user or mythtv or root?

[bill6502]

If your configuration directory is in /etc/mythtv (and linked to by the mythtv and your own user, then
you can store the directory like the following. If you have the configuration directories in both users,
then you must create that file in both places. When doing upgrades, mythtv will call the backup script
so you might as well make sure that backups go in the same place.

Code: Select all

cat /etc/mythtv/backuprc
DBBackupDirectory=/var/lib/mythtv/db_backups

Otherwise, if you include the command line in your post, maybe someone can spot the issue.

[PhilB]

I run that script under my normal login user. The same
one which runs frontend. Not user mythtv.
Would you like to show us the failing script?
What about permissions on the backup file?
Check with ls -l
Phil

[jimls]

Have a SSD for OS and HDD for recordings. I found I didn't have the backup directory set in the backend so set that up as
/var/lib/mythtv/db_backups
Location for recordings is /var/lib/mythtv/hddsda1/recordings
This contains the recordings I have copied over, the database backups and the restore script.
The recordings have owner and group mythtv

The db backup script and backup file both have owner jim (that's me) and group mythtv

Code: Select all

jim@jim-myth:/var/lib/mythtv/hddsda1/recordings$ ls -al myth*
-rw-rw-r-- 1 jim    mythtv 20797121 Jul 30 17:34 mythconverg-1317-20230730172934.sql.gz
jim@jim-myth:/var/lib/mythtv/hddsda1/recordings$ ls -al re*
-rwxrw-r-- 1 jim mythtv 164 Jul 30 18:45 restorescript.sh
jim@jim-myth:/var/lib/mythtv/hddsda1/recordings$ cat restorescript.sh
#!/bin/bash
FILENAME='mythconverg-1317-20230730172934.sql.gz'
sudo /usr/share/mythtv/mythconverg_restore.pl --drop_database --create_database --filename $FILENAME

when I run the script I get this:

Code: Select all

jim@jim-myth:/var/lib/mythtv/hddsda1/recordings$ ./restorescript.sh
[sudo] password for jim:

ERROR: DBBackupDirectory not specified, stopped at /usr/share/mythtv/mythconverg_restore.pl line 773.
jim@jim-myth:/var/lib/mythtv/hddsda1/recordings$ 

[white_haired_uncle]

try adding --directory /etc/lib/mythtv/db_backups

(assuming that's where you put mythconverg-1317-20230730172934.sql.gz)