Tvheadend

Not sure about the actual process on debian, but when I played here with different versions I got the impression that config was compatible. I suggest you backup all files under the tvheadend dir and then just install the new version and run.

Tvheadend does include it's own way to upgrade the databases inside of the settings folder etc. However the way tvheadend settings are stored is not simple so it may encounter unforseen problems whilst doing that.

Here is what i do:

• Take a screenshot of my DVR entries, and DVR "AutoRec" entries tabs.
• And of any other user settings pages you think you may forget.
• Backup the config folder (as suggested by Anders ^^).
• Create a basic 'pre-scan' skeleton config. This cannot include any channelsm muxes or services. As the GUIDs of those things changes between installations and is no consistent.

• Delete config folder.

• Replace with pre-scan skeleton folder. * That can include your * user accounts files * adapters list (before 1st scan) * networks added BEFORE 1st scan (i.e. just the network setting itself for the adapters ^^ to know which network they belong to. NOT any scanned GUID services insice the netowrks/ subfolder) * dvr profiles * bouquests (if DVB-S) * other general / global settings

Uninstall Tvheadend 3.4
Install Tvheadend 4.0.x
(via tvheadend apt sources, just like you said)

• Run tvheadend again for 1st time.
• If your skeleton config folder is correct, it should restore your user accounts and adapters, etc.
• Proceed to let tvheaedend perform it's 1st scan. Preferably it will auto-populate the channels map via bouquest or DVB-T.

• Then re-enter manually your DVR programme entries in the DVR tab (which shows are scheduled to record).

It sounds complex but avoids any problems with a messed up config. Because you always start with a clean config. Have already automated this proceedure as much as possible with docker as the public docker image "dreamcat4/tvheadend.config".

The only thing is it can't do is:

a) Keep your DVR entries. Because the GUID for the channel (of a new scan) always changes.

b) Keep custom / manual channel mappings (which are not resotred by the automatic bouquets system). Because the GUID of the underlying service that the channel points to always changes between scans.

To solve that would need some hassles of a custom script to match regex expressions against the channel names and service names, then to reconstruct via tvheadend API (add DVR entry X,Y,Z from import, add Channel --> Service GUID ABCD-xxxx- from import list of manual channel mappings).

Well, that was clear as mud...

1) "Backup the config folder (as suggested by Anders ^^)." WHICH folder, specifically?

2) "Create a basic 'pre-scan' skeleton config. This cannot include any channelsm muxes or services. As the GUIDs of those things changes between installations and is no consistent." I have not the foggiest clue what is meant by this, or how it would be done.

3) "Delete config folder." Isn't that kind of necessary?

4) "Replace with pre-scan skeleton folder. * That can include your * user accounts files * adapters list (before 1st scan) * networks added BEFORE 1st scan (i.e. just the network setting itself for the adapters ^^ to know which network they belong to. NOT any scanned GUID services insice the netowrks/ subfolder) * dvr profiles * bouquests (if DVB-S) * other general / global settings." What folder are you referring to, exactly?

I just don't follow this process at all, not even a little bit. I suspect in your mind this is all quite clear but the terminology you are using makes no sense at all to someone who has no insight into your thought process. You are using words that are apparently meaningful to you, but without further explanation are meaningless to anyone else.

I don't know if any of this would be useful to me anyway, since I'd be upgrading from a 3.9 version to probably a 4.1 version running under a different OS (Ubuntu Server vs. Debian). Still, I wish I could understand what you're actually doing, but my mind is not "filling in the blanks" in your explanation.

To the OP (mainly)... I upgraded from 3.4 to 3.9.x, but I doubt it's very different going to 4.x.

In theory, yes, simply replacing the PPA line is the starting point. You don't want to use the echo... | tee as that will simply add the new one without removing the old one - you'll need a text editor to do that. Just remember that your sources file is protected, so you need to use sudo to edit it.

Once done, though, sudo apt-get update && sudo apt-get upgrade will fetch the new version for you.

Now, this is where I'm going to get vague...

When I upgraded, there was a separate migration script, but I believe this has now been rolled into the code. What breaks, though, is that recent versions have a very different way of handling how tuners, services, networks and channels map onto each other - and only so much of that can be migrated. So, after the upgrade you will find that you need to re-enable some things by hand and re-connect the various elements so tvh then knows that channel A maps to service B on networks C and D which appear on tuners D,E and F. This might help: http://docs.tvheadend.org/before_you_begin/

I also seem to recall having to re-create my auto-recording rules, which is where Dreamcat's suggestion of a screenshot is a good one.

To a great extent, how much breakage you'll get ... well, you'll only know when you get there. I'd suggest having an IRC client on hand and logging into #hts while you do it if you're nervous, and then folks can try to help you realtime.

In terms of backup (to K Shea's point), you want to protect everything that's in /home/hts/.hts/tvheadend, as that's what will get over-written: sudo cp -rp /home/hts/.hts/tvheadend /home/hts/.hts/tvheadend.backup will keep all permissions and ownership intact). If it breaks too badly, you need to be able to stop tvheadend (sudo service tvheadend stop), restore that folder (rm /home/hts/.hts/tvheadend and then reverse the cp command to copy it back, or mv it if that's what you want), change your PPA back, reinstall 3.4 (sudo apt-get install <package>=<version> - you'll find the package name and version from apt-cache policy tvheadend).

@K Shea - a move from 3.9 to 4.1 should go without a hitch as the configs are basically compatible. tvh will also take a backup for you when you do it, but I'd still look at the above just in case.

Does any of that help make sense of the blanks? Happy to expand where it doesn't.

Cheers...

Prof Yaffle wrote:

@K Shea - a move from 3.9 to 4.1 should go without a hitch as the configs are basically compatible. tvh will also take a backup for you when you do it, but I'd still look at the above just in case.

Does any of that help make sense of the blanks? Happy to expand where it doesn't.

The main issue I would have is that I am currently running Debian Wheezy, and for that OS there is no upgrade available beyond 3.9 in the repositories. I'm just a little tired of not being able to run a recent version because everything seems to be developed for Ubuntu, so at some future date my plan is to completely start over with Ubuntu server. So it would not be a case of just installing a new version of TVHeadEnd over the top of a previous one, but rather trying to move the existing configuration to what would essentially be an entirely new system.

And my other desire is to be able to completely back up the configuration to another server, so that I could bring it back if my system ever goes belly up. Either way it's the same thing; I would like to be able to save the configuration, store it temporarily on another site, then bring it back after reinstalling the operating system and TVHeadEnd (possibly a more recent version). The problem with just trying to backup the /home/hts/.hts/tvheadend directory is that while it can be copied to another system, more than likely when I try to restore it there will be issues with permissions, ownership, or possibly Linux symlinks if those are used anywhere in the configuration. The system I'd want to backup the configuration to wouldn't even be running Linux, and I know enough to know that if any of those things (permissions, ownership, or symlinks) get messed up, things won't work correctly, but I don't know enough about Linux to know how to overcome that.

The way you proposed to back it up (sudo cp -rp /home/hts/.hts/tvheadend /home/hts/.hts/tvheadend.backup) might work IF the hard drive were not going to be reformatted prior to reinstalling the operating system, but... hopefully you see the problem. But thank you for at least explaining some of that, it makes a little more sense now.

I see your point. I have moved between systems by just wholesale shifting the config directory using rsync -a ("archive" - it keeps all permissions, timestamps and owners, similar to the cp command above), but it's not ideal because it generates system unique IDs for everything. It's theoretically possible that the target system could already have these, or could generate a replica some other time as it didn't generate these originally (I suppose, not entirely certain). You also need to check that the users and groups exist on the target system - safest to install tvh, then stop it, copy over the config, and restart, so you know that hts:video at least exists.

All I can suggest for the moment is to look at (and maybe add to) https://tvheadend.org/issues/2454.

That said, rsync -a would allow you to take a backup, as I've done that many times and used it to restore to a completely different hardware/OS config as above. It hasn't broken yet...

Prof Yaffle wrote:

sudo cp -rp /home/hts/.hts/tvheadend /home/hts/.hts/tvheadend.backup will keep all permissions and ownership intact

After thinking a bit more about this, it occurs to me that is might be a good way to save periodic snapshots of the current configuration, so that if you really mess things up (and it's not because of a software upgrade or something else outside of TVHeadEnd) you could roll back to a previous known good configuration. I wonder if there would be a way to set up a cron job (as the root user) so that once or twice a week it would automatically make a copy of the configuration, and maybe keep two or three older backups as well. In other words, have tvheadend.backup, tvheadend.backup.1, tvheadend.backup.2, and tvheadend.backup.3, with tvheadend.backup being the most recent and each higher numbered copy being an older version. So, you could go back several days or even a few weeks to get a previous good configuration if necessary. Do you think there would be any real benefit in doing that?

Prof Yaffle wrote:

I see your point. I have moved between systems by just wholesale shifting the config directory using rsync -a ("archive" - it keeps all permissions, timestamps and owners, similar to the cp command above), but it's not ideal because it generates system unique IDs for everything. It's theoretically possible that the target system could already have these, or could generate a replica some other time as it didn't generate these originally (I suppose, not entirely certain). You also need to check that the users and groups exist on the target system - safest to install tvh, then stop it, copy over the config, and restart, so you know that hts:video at least exists.

Thanks. I've never really understood rsync, I'm assuming in this case you'd run something like rsync -a /home/hts/.hts/tvheadend but there has to be more to it than that. Could you maybe share the full command you've used, of course replacing any sensitive information like ip addresses, usernames or passwords with generic substitutes? In any case this doesn't sound like a truly ideal solution, but it's probably a lot better than not doing a backup at all.

I added a comment on that issue page, and I hope others that would like to see that will take a few moments and do likewise.

I think it's essentially sudo rsync -a /home/hts/.hts/tvheadend /home/hts/.hts/tvheadend.backup if you're doing it on a local system. Have a play, but that should just replicate the directory with ownership et al intact.

You either need sudo (to run as root) or to run the rsync as the owner of the files - it prevents you from copying files you shouldn't have access to (e.g. if you copy them and don't retain the ownership/permissions then you could open a file you shouldn't).

If you add this to root's crontab then yes, it can run and simply back things up. You could either write a simple script that deletes, say, backup3 and then just mv's the others up (so mv backup2 backup3 ... mv backup backup2) before taking the backup, or perhaps logrotate would help here.

If you're rsyncing to another system then that's a whole different question, because you're into setting up rsyncd with the right access and that's very system-specific. Easier to mount the remote system through NFS and then pretend it's still a local copy.

As to the benefit of keeping generations of configs... not sure here. One or two, maybe, depending on how often you change things. By its nature, much of the data goes out of date pretty quickly.