Tvheadend

From what I understand, the crash log is next to useless without the accompanying debug symbols - they're the things that ultimately translate the hex numbers back into line numbers, modules and commands in the underlying code so the bugs can be traced. Without them, it's a matter of complete guesswork as any instruction could have been in any bit of memory at any time. And, given how much the code has changed since this version, that makes it doubly impossible to work out what was happening...

I don't pretend to understand the subtleties of .deb files and how they port between systems (or not)... all I know is that there have been some issues with running the PPA files on Wheezy, and hence the 'not supported' tag. Hardly ideal, though, I agree.

The answer has to start with 'upgrade', but getting something to upgrade to is the immediate challenge. I can't see any way of building something on my Ubuntu system for you, and, if you're really that hesitant about compiling (genuinely, it's not hard)... well, the only other option I have is to see if I can install Wheezy into a virtual machine and build you a .deb from the current stable branch (4.0.7, I think). Let me look... doesn't feel difficult... if that works, then we can maybe get the deb inserted as an official Wheezy package somehow.

You're on 64-bit Intel from the above, yes? Maybe I'll just build both 32- and 64-bit images while I'm at it... might be useful to someone...

Yes, I'm running a 64 bit system. But honestly, I have mixed feelings about upgrading. My fear is that upgrading will REALLY break everything, especially if going from 3.9 to 4.1. One thing I have considered is disconnecting the hard drive and temporarily installing a different one and putting Ubuntu Server and the latest TVHeadEnd on that, then seeing if I can at least get it to recognize my tuner cards and do other basic stuff. If that works, I may just leave that drive in and use the other one as a data-only drive (although with my luck the system would choose to boot from the original drive), however that is something I do NOT look forward to because there are so many things that can go wrong. Only reason I'd consider that is because at the end of the day, if everything has completely gone to hell then I should be able to just reconnect the original hard drive and at least be back to the only partially broken setup I have now. It might be different if TVHeadEnd would upgrade and keep all its settings, but would it do that reliably in a jump from 3.9 up to 4.1? If not, I guess my feeling is that if I am going to upgrade anyway, I might as well dump Debian Wheezy and go to Ubuntu Server, because that seems to be what is supported now.

The thing I really wish was available is a way to export and import settings, or failing that, at least a way to dump all your current settings to a text file so that when you are trying to set up a new system you can refer to that file and see what you had on every screen (I actually posted this as a feature request but the developer closed it, just saying "I don't like this idea. Also, it's partial dup of #2454", which is another feature request that's just sitting there with no action):

https://tvheadend.org/issues/3337
https://tvheadend.org/issues/2454

So basically this makes TVHeadEnd one of the most difficult pieces of software I know of to upgrade, and it's also software that I don't want down for days or weeks while I try to figure out how to reconfigure it. If there were an easy and reliable way to back up and restore setting between versions (not just "copy over this directory and it might work"), I would be a lot more enthusiastic about tackling an upgrade. But all that said, if there were a way to upgrade TVHeadEnd to 4.1 on my current system without any risk of it completely breaking everything, I would certainly consider it. My fear is I would attempt to upgrade, everything would stop working, and I would have no path to go back to at least what I had (I've been bitten in this way with other Linux-based software, and I don't want to see it happen with TVHeadEnd). So, I hope you can see why I have such conflicted feelings about this.

I understand the frustration and concerns. All I can suggest is a really good backup, and understand what you're doing - I've gone up and down the 3.9/4.0 tree many times, and not had problems, but that's not to say it can't happen. In theory, 3.9 was simply the development numbering before 4.0 was launched, so there shouldn't be a problem... but...

Anyway, see here:

https://tvheadend.org/boards/5/topics/18724

There's a 64-bit Wheezy build that I've made of 4.0.7, which is the current stable. I've built it on a clean install of Wheezy 7.9, downloaded and patched today, so it should be as good as it gets. I don't know what I don't know, though, so maybe I'm missing something completely.

If you want to give it a try, broadly it'd be:

1. Stop tvheadend (sudo service tvheadend stop)
2. Backup your config (sudo cp -rp /home/hts/.hts/tvheadend /home/hts/.hts/tvheadend.backup)
3. Install the deb files (sudo dpkg -i *.deb)
4. Restart tvheadend if it doesn't do it automatically (sudo service tvheadend restart)

... that's all I can offer, though. All I can suggest beyond that (beyond the backups - did I mention those?) is the gratuitous use of screenshots for your autorec rules and anything you couldn't recreate off the top of your head.

I appreciate that you have done this but you emphasized a really good backup, and that's another of the frustrations I have with Linux. It appears that making a backup is easy; there are probably at least a dozen ways to do it. But making a backup that can be restored so you are back where you started is another matter entirely, especially if you don't know that much about Linux to start with. The ideal situation would be to backup the entire system (essentially a snapshot) to a bootable file that could be saved to a USB stick and reinstalled (just as if you were installing a new version of the OS), but I have no idea if or how that could be done, particularly on a system with no desktop.

With my luck, if I tried to backup my system in the hope that I could put everything back the way it was if I ran into trouble, I would back it up but then when I tried to recover from whatever misfortune befalls me using the backup I'd totally screw up the system. I understand there are some halfway decent GUI-based backup programs for Linux, but I'm running a server only with no desktop, so that limits my options. Anyway, I say all that just to say that right now I don't know of any good way to do a backup (yet another reason I wish it was possible to save TVHeadEnd's configuration).

I wonder, is there any easy way to clone a system from a larger hard drive to a smaller one (the actual data on the larger drive would easily fit on the smaller one, but I could not do anything like an exact sector-by-sector clone due to the size difference)? If there were, maybe I could copy the entire system to the other drive, then try your upgraded version. It's really a question of, do I want to invest my time in trying Ubuntu Server and getting away from Debian altogether, or do I just want to try upgrading TVHeadEnd on the system I already have. The former would get me away from having this same problem again in a few months, but would require a significant time investment, while the latter would be the quickest upgrade path IF it works. And I am probably going to want to think about that a bit before committing one way or another.

(I realize on your other page you talk about backing up the /home/hts/.hts/tvheadend directory but the problem there is that if for some reason the new version doesn't work, that alone would not get me back to 3.9, since TVHeadEnd itself would be overwritten by the newer version, and who knows what else).

I've done many backups of Tvheadends config and have had very little issues granted mine is a very basic config but you really shouldn't be worried as long as you have a backup you can restore if anything goes wrong.

So basically this makes TVHeadEnd one of the most difficult pieces of software I know of to upgrade, and it's also software that I don't want down for days or weeks while I try to figure out how to reconfigure it

I don't understand how copying/moving a folder (with correct permissions) could be classed as difficult?

I've just moved over my config from a PC to a Banana Pi doing this.

On main machine:

sudo -s
sudo service tvheadend stop
cd /home/hts/.hts
sudo tar cvfp ../tvheadend.tar tvheadend
cd /home/hts/
sudo scp tvheadend.tar root@ip:~/

On Banana Pi.

sudo service tvheadend stop
sudo -s
cd /home/hts/.hts
sudo mv tvheadend tvheadend~backup
tar xvfp ~/tvheadend.tar

The only thing I had to do on the BPi was to delete all the ghost failed recordings, enable the adapter and set the network job done! Took 10 minutes if that.

Mark Clarkstone wrote:

I don't understand how copying/moving a folder (with correct permissions) could be classed as difficult?

We're talking two different things here. You are talking about backing up the configuration and moving it to a new install (and thank you for showing how to do that, I have been wondering how you'd preserve permissions and ownership on a move between systems, and I'm guessing that's what your tar command does. My only question is whether this would work if the system you start with is a 3.9-branch system and you are moving it to a new 4.1-branch install).

What I was talking about, though, was a complete system backup so if anything goes wrong, I can put back the system I have now and be back in business. The only way I can think of to do that reliably is to physically swap out the hard drive, and if I am going to all that trouble I may just as well install Ubuntu Server and the latest version of TVHeadEnd and be done with it. That way I'm not just kicking the can down the road for another six months or a year. Because no matter how you slice it, Debian Wheezy isn't going to be supported forever, and neither is TVHeadEnd 4.0.

I was actually hoping to wait until Ubuntu 16.04 came out before being forced to upgrade (I think it's due in April) because I hate upgrading so much that I will not use anything other than an LTS version of Ubuntu, which is supposed to be supported for five years. The current LTS version of Ubuntu is 14.04 and that at least guarantees I would have another 3+ years before I'd be forced to upgrade again. If I use that and TVHeadEnd 4.1 (from the "unstable" branch) then hopefully I should not have to go through all this again for another three years (at least), and more importantly, I should be able to upgrade TVHeadEnd without reinstalling the entire OS. I feel like installing Debian was a big mistake, because TVHeadEnd's official support for it has not been very good. The only reason I went with it in the first place is because Ubuntu pushes system software updates too frequently for my comfort, especially kernel updates (which require manually rebuilding the TBS card drivers each time).

When I started this thread I was really hoping someone else might have seen the issue I am having (where TVHeadEnd crashes if you click on the "Digital Video Recorder" tab) and might be able to tell me how to fix that in the version of TVHeadEnd I am running. Unfortunately it seems that whenever you have an older version of TVHeadEnd and you have an issue, all anyone can suggest is to upgrade. I understand the validity of that response, since upgrading may very well fix the issue, but it's kind of like telling someone they have to buy a whole new car to fix a "check engine" light that stays on (well, except for the fact that there's no cost involved in upgrading software other time, and maybe a certain level of frustration if it doesn't work). At this point, if I am going to go through the trouble and uncertainty of upgrading, my preference would be to just zap Debian and at least not have that hassle in my life anymore.

P.S. On the restore you have "sudo mv tvheadend tvheadend~backup", why the "~" character instead of a hyphen "-"? Was that a typo, a personal preference, or is there some specific reason for using that? Also, why the "sudo -s" commands when you are using sudo in front of the individual commands that follow? Just trying to understand the quirks of Linux here. And also, you said, "The only thing I had to do on the BPi was to delete all the ghost failed recordings, enable the adapter and set the network job done!" I understand the first two, but what do you mean by "set the network job done!"?

K Shea wrote:

Mark Clarkstone wrote:

I don't understand how copying/moving a folder (with correct permissions) could be classed as difficult?

We're talking two different things here. You are talking about backing up the configuration and moving it to a new install (and thank you for showing how to do that, I have been wondering how you'd preserve permissions and ownership on a move between systems, and I'm guessing that's what your tar command does. My only question is whether this would work if the system you start with is a 3.9-branch system and you are moving it to a new 4.1-branch install).

You really should have few issues going from 3.9 > 4.x - Tvheadend should automatically upgrade the config regardless of the system the only thing that will happen is adapters won't be enabled and they will have no network, you'll lose all old recordings from the other system (unless you backup those and place them in the exact folder on the new system) and the DVR and timeshift paths may be wrong but those really don't take long to fix.

What I was talking about, though, was a complete system backup so if anything goes wrong, I can put back the system I have now and be back in business. The only way I can think of to do that reliably is to physically swap out the hard drive, and if I am going to all that trouble I may just as well install Ubuntu Server and the latest version of TVHeadEnd and be done with it. That way I'm not just kicking the can down the road for another six months or a year. Because no matter how you slice it, Debian Wheezy isn't going to be supported forever, and neither is TVHeadEnd 4.0.

I was actually hoping to wait until Ubuntu 16.04 came out before being forced to upgrade (I think it's due in April) because I hate upgrading so much that I will not use anything other than an LTS version of Ubuntu, which is supposed to be supported for five years. The current LTS version of Ubuntu is 14.04 and that at least guarantees I would have another 3+ years before I'd be forced to upgrade again. If I use that and TVHeadEnd 4.1 (from the "unstable" branch) then hopefully I should not have to go through all this again for another three years (at least), and more importantly, I should be able to upgrade TVHeadEnd without reinstalling the entire OS. I feel like installing Debian was a big mistake, because TVHeadEnd's official support for it has not been very good. The only reason I went with it in the first place is because Ubuntu pushes system software updates too frequently for my comfort, especially kernel updates (which require manually rebuilding the TBS card drivers each time).

Support for Wheezy is just the same as it is for Jessie only the repository system used (Docker Hub) doesn't support builds for it just like it doesn't support 32 bit builds, nothing can be done about that, well not until Adam Sutton comes back and fixes the doozer build system to update the old repos (apt.tvheadend.org).

Why not just build your own debian package? granted it takes a bit longer that just doing apt-get update/upgrade but at least you have builds and backup configs you can fall back on if something breaks.

Heres a guide on how to do it.
Quick & Easy guide to building Tvheadend git master on a RPi2 (This also works on any other deb system!).

sudo apt-get install git build-essential debhelper pkg-config fakeroot
git clone https://github.com/tvheadend/tvheadend.git build/tvheadend/master (You can add --branch "release/4.0" to this to use stable 4.0.x releases).
cd build/tvheadend/master
./Autobuild.sh

What each lines does.

• 1 Installs a few dependencies (you'll need to install some more later on).
• 2 Clones the Tvheadend master branch from github & places it in build/tvheadend/master.
• 3 Changes directory to the above path.
• 4 Runs the Autobuild script that will build a debian package so that you can install it in a nice and neat way.

AUTOBUILD_CONFIGURE_EXTRA=--enable-libffmpeg_static ./Autobuild.sh if you want transcoding

Other info.
The Autobuild.sh script will complain about other missing dependencies you need to install those (using sudo apt-get install) and then run the script again.
Once the build has completed you'll find the built debian package (E.g tvheadend_4.1-368~geeda7d7_armhf.deb) in build/tvheadend.

You can then install it (and the debug package) using.

cd build/tvheadend
sudo dpkg -i tvheadend*.deb

When I started this thread I was really hoping someone else might have seen the issue I am having (where TVHeadEnd crashes if you click on the "Digital Video Recorder" tab) and might be able to tell me how to fix that in the version of TVHeadEnd I am running. Unfortunately it seems that whenever you have an older version of TVHeadEnd and you have an issue, all anyone can suggest is to upgrade.

The build you're using 3.9 really wasn't meant for general use it has quite a few bugs that have been fixed this is why you'll keep being told to upgrade, I'm not even sure why you're still using it.

I understand the validity of that response, since upgrading may very well fix the issue, but it's kind of like telling someone they have to buy a whole new car to fix a "check engine" light that stays on (well, except for the fact that there's no cost involved in upgrading software other time, and maybe a certain level of frustration if it doesn't work). At this point, if I am going to go through the trouble and uncertainty of upgrading, my preference would be to just zap Debian and at least not have that hassle in my life anymore.

Again really if you wanted less of the hassle it would have been easier to have stuck to 3.4.28 and when 4.0.x got released upgraded to that.

If my experience I've found Debian to be a lot less bothersome than Ubuntu

P.S. On the restore you have "sudo mv tvheadend tvheadend~backup", why the "~" character instead of a hyphen "-"? Was that a typo, a personal preference, or is there some specific reason for using that?

No reason just me hitting ~ out of habit.

Also, why the "sudo -s" commands when you are using sudo in front of the individual commands that follow?

Because you can't always cd into dirs you don't own and again I'm typing sudo so often I do it without thinking :p but really once you're as root you an omit the sudo.

Just trying to understand the quirks of Linux here. And also, you said, "The only thing I had to do on the BPi was to delete all the ghost failed recordings, enable the adapter and set the network job done!" I understand the first two, but what do you mean by "set the network job done!"?

Sorry I meant set the network to the adapter & you're done :p

Hmmm, this sounds a little like the process I have to go through to build the TBS drivers.

Mark Clarkstone wrote:

Why not just build your own debian package? granted it takes a bit longer that just doing apt-get update/upgrade but at least you have builds and backup configs you can fall back on if something breaks.

So let's say I followed the instructions and everything stopped working - how would I get the current version of TVHeadEnd back (assuming I made a backup of the TVHeadEnd config as you suggested in your previous message)? Specifically what I mean is, how would I return to using 3.9? I get that I most likely wouldn't need to, but my big fear all along has been actually making things worse than they already are.

git clone https://github.com/tvheadend/tvheadend.git build/tvheadend/master (You can add --branch "release/4.0" to this to use stable 4.0.x releases).

Actually I kind of wanted to use the 4.1 "unstable" release - don't want to run a nightly because too much potential for breakage, but would like to start out with the newest version, and from what I understand the "unstable" version is mis-named because it's actually a lot more stable than the "stable" versions of many other projects. Honestly the version naming system in TVHeadEnd confuses me no end. For example if I look at https://github.com/tvheadend/tvheadend/releases it looks like the 4.1 branch is actually OLDER than the 4.0.7 branch, which makes no sense at all. In the repository (that doesn't work with Debian Wheezy) there are FOUR separate packages available, two in the "master" branch and two in the "stable" branch, Since I don't want a nightly I was going to use the "Master branch - 'unstable' release" which I had assumed would get me 4.1, but now I'm wondering if there is some difference between the 4.0.x releases and the 4.1 release, and which one I really want.

AUTOBUILD_CONFIGURE_EXTRA=--enable-libffmpeg_static ./Autobuild.sh if you want transcoding

So just to be crystal clear, you mean that instead of using just

./Autobuild.sh

I would use

AUTOBUILD_CONFIGURE_EXTRA=--enable-libffmpeg_static ./Autobuild.sh

to enable transcoding? Now, my question would be, is transcoding included in the pre-built versions from the repositories? And do I even need it? Normally, when I record a program from the satellite, it saves it as a .ts file, and Kodi plays that just fine. While I do have ffmpeg installed on the system in order to handle a couple of "special case" channels with funky audio (they send the 5.1 audio channels in discrete streams, if you are curious the instructions I found for doing that are at https://freetoairamerica.wordpress.com/2015/09/03/fixing-the-audio-on-live-tv-from-a-certain-network-which-shall-remain-nameless/), that is essentially done outside of TVHeadEnd as I understand it, and I actually don't think there would be any way to set TVHeadEnd to do that internally even if it did have transcoding support. The only thing I use to view live and recorded programs is Kodi, which handles the .ts streams just fine. But in any case I think I'd like to emulate the options used to create the repository builds as closely as possible, if I were going this route.

The build you're using 3.9 really wasn't meant for general use it has quite a few bugs that have been fixed this is why you'll keep being told to upgrade, I'm not even sure why you're still using it.

Because the 3.4 branch did not support satellite TV all that well and in particular I would not have been able to do the audio fix mentioned above in the 3.4 branch (according to the article I referenced, that requires version 3.9.2100 or later, though I have no idea why that requirement exists). And at the time I saw nothing anywhere to suggest that 3.9 wasn't intended for general use, in fact I think someone recommended I upgrade to it to resolve some issues I'd had previously, though my memory isn't good enough to remember what those issues were. And of course the reason I never upgraded beyond that was because no additional builds were ever offered for Debian Wheezy in the repository.

Again really if you wanted less of the hassle it would have been easier to have stuck to 3.4.28 and when 4.0.x got released upgraded to that.

But on Debian Wheezy I would not have had that option anyway.

If my experience I've found Debian to be a lot less bothersome than Ubuntu

That was why we went with it in the first place. Because you have to rebuild the TBS drivers after each kernel update, I figured Debian would have a lot fewer of such updates than Ubuntu, and over time that has proven to be the case. But if you look at all the questions and uncertainty I have raised just in this post, you might understand that I prefer the relative safety of installing from a repository. Normally that doesn't ask me to make any decisions about anything, it just goes ahead and installs. And believe me, even a question like "do I want transcoding support or not" is something I really don't want to deal with, because I don't know if I need it, and I don't know whether if I don't need it and I install it anyway, will that break something else or have some negative effect on my system? That's also why having so many choices in the repositories bothers me; I would be much happier if there were just a "normal" version for people like me, and a "nightly" version for all the people who want to be beta testers. Because when I have too many options like that, and particularly when the differences aren't clearly explained, I always wind up wondering if I made the right decision.

Sorry I meant set the network to the adapter & you're done :p

Ah, okay, I think I understand now. The network(s) don't get automatically connected to the adapter(s) after the upgrade so you have to set those manually.

Anyway thanks for explaining all that, if nothing else it was quite educational. Probably won't do anything until later this week, so I am still weighing the options.

EDIT: After some consideration, I think the main thing that tips the scales for me is that Debian Wheezy only has “security support” until February 2016, and if I were to update to Debian Jessie, that has “security support” until May 2018. Whereas Ubuntu Server 14.04 LTS will have full support until April, 2019. So in the end I think I would be better off to try changing out the hard drive, installing Ubuntu Server 14.04 LTS and TVHeadEnd 4.1 (unless there is some reason I should stay in the 4.0 branch), and copying over my configuration using tar as you suggested. Then if it has any problems I can restore the original drive, but if copying the configuration works it won't take much longer than trying to upgrade TVHeadEnd on the existing system. This not only feels like the safest approach to me, but also the one that will (hopefully) cause me the least amount of grief in the future.

K Shea wrote:

Hmmm, this sounds a little like the process I have to go through to build the TBS drivers.

Does it? You only have to do it once & every so often you update when you need to or when a major flaw has been fixed. It's a one time only thing when you feel like doing it with kernel upgrades you pretty much have to build the drivers or you get no cards.

Mark Clarkstone wrote:

Why not just build your own debian package? granted it takes a bit longer that just doing apt-get update/upgrade but at least you have builds and backup configs you can fall back on if something breaks.

So let's say I followed the instructions and everything stopped working - how would I get the current version of TVHeadEnd back (assuming I made a backup of the TVHeadEnd config as you suggested in your previous message)?

So what you're saying here is you don't know how to remove software from your system? If you've installed it via dpkg you're still able to remove it using 'sudo apt-get remove tvheadend' that usually does the trick, the only thing it won't do is remove your config you can easily do that using 'sudo rm -r /home/hts/.hts'.

Specifically what I mean is, how would I return to using 3.9? I get that I most likely wouldn't need to, but my big fear all along has been actually making things worse than they already are.

After removing your self built deb and deleted your config, you simply install tvheadend again using 'sudo apt-get install tvheadend' (IIRC it'll use the one from the repos) once it's installed stop tvheadend 'sudo service tvheadend stop' then place folder contained within your backup into /home/hts/.hts and start it again using 'sudo service tvheadend start'. Provided you've extracted and the permissions are correct you shouldn't have any issues.

git clone https://github.com/tvheadend/tvheadend.git build/tvheadend/master (You can add --branch "release/4.0" to this to use stable 4.0.x releases).

Actually I kind of wanted to use the 4.1 "unstable" release - don't want to run a nightly because too much potential for breakage, but would like to start out with the newest version, and from what I understand the "unstable" version is mis-named because it's actually a lot more stable than the "stable" versions of many other projects. Honestly the version naming system in TVHeadEnd confuses me no end. For example if I look at https://github.com/tvheadend/tvheadend/releases it looks like the 4.1 branch is actually OLDER than the 4.0.7 branch, which makes no sense at all. In the repository (that doesn't work with Debian Wheezy) there are FOUR separate packages available, two in the "master" branch and two in the "stable" branch, Since I don't want a nightly I was going to use the "Master branch - 'unstable' release" which I had assumed would get me 4.1, but now I'm wondering if there is some difference between the 4.0.x releases and the 4.1 release, and which one I really want.

The 4.1.x is the development version and should not really be used at all unless you want unexpected crashes and bugs. The releases 4.0.x are meant to be the most stable as they won't have any of the WIP code that goes into 4.1.x the only updates that do make it into 4.0.x are backported from 4.1 these are usually bug fixes and anything that causes major problems.

• Tvheadend - Master branch - nightly builds = Builds the master branch from github (https://github.com/tvheadend/tvheadend/tree/master) nightly.
• Tvheadend - Master branch - 'unstable' releases = Builds the master branch once a week.
• Tvheadend - Stable branch - nightly builds = Builds using the latest changes from the 'release/4.0' branch https://github.com/tvheadend/tvheadend/tree/release/4.0 nightly.
• Tvheadend - Stable branch - official releases = Builds stable once a week.

AUTOBUILD_CONFIGURE_EXTRA=--enable-libffmpeg_static ./Autobuild.sh if you want transcoding

So just to be crystal clear, you mean that instead of using just

./Autobuild.sh

I would use

AUTOBUILD_CONFIGURE_EXTRA=--enable-libffmpeg_static ./Autobuild.sh

to enable transcoding? Now, my question would be, is transcoding included in the pre-built versions from the repositories? And do I even need it?

Yes it is included in the pre-built version, and no you don't have to use it but some people do.

Normally, when I record a program from the satellite, it saves it as a .ts file, and Kodi plays that just fine. While I do have ffmpeg installed on the system in order to handle a couple of "special case" channels with funky audio (they send the 5.1 audio channels in discrete streams,
if you are curious the instructions I found for doing that are at https://freetoairamerica.wordpress.com/2015/09/03/fixing-the-audio-on-live-tv-from-a-certain-network-which-shall-remain-nameless/), that is essentially done outside of TVHeadEnd as I understand it, and I actually don't think there would be any way to set TVHeadEnd to do that internally even if it did have transcoding support. The only thing I use to view live and recorded programs is Kodi, which handles the .ts streams just fine. But in any case I think I'd like to emulate the options used to create the repository builds as closely as possible, if I were going this route.

The build you're using 3.9 really wasn't meant for general use it has quite a few bugs that have been fixed this is why you'll keep being told to upgrade, I'm not even sure why you're still using it.

Because the 3.4 branch did not support satellite TV all that well and in particular I would not have been able to do the audio fix mentioned above in the 3.4 branch (according to the article I referenced, that requires version 3.9.2100 or later, though I have no idea why that requirement exists).

I think that may have been around the time piping was added.

And at the time I saw nothing anywhere to suggest that 3.9 wasn't intended for general use, in fact I think someone recommended I upgrade to it to resolve some issues I'd had previously,

Unless it's listed as a new releases on tvheadend.org then it isn't for general use, but if you've been told upgrading to the unstable (at the time) would fix your issues then that's fair enough.

though my memory isn't good enough to remember what those issues were. *And of course the reason I never upgraded beyond that was because no additional builds were ever offered for Debian Wheezy in the repositor*y.

This was around about the time when a small version number change took place to the file names that caused the scripts which builds and places the packages in the repository (apt.tvheadend.org) broke and it hasn't been fixed since.

Again really if you wanted less of the hassle it would have been easier to have stuck to 3.4.28 and when 4.0.x got released upgraded to that.

But on Debian Wheezy I would not have had that option anyway.

True and this is an issue no one seems to be interested in fixing as Wheezy is pretty much EOL. And unless the old build scripts get fixed it won't be changing any time soon.

If my experience I've found Debian to be a lot less bothersome than Ubuntu

That was why we went with it in the first place. Because you have to rebuild the TBS drivers after each kernel update, I figured Debian would have a lot fewer of such updates than Ubuntu, and over time that has proven to be the case.
But if you look at all the questions and uncertainty I have raised just in this post, you might understand that I prefer the relative safety of installing from a repository.
Normally that doesn't ask me to make any decisions about anything, it just goes ahead and installs. And believe me, even a question like "do I want transcoding support or not" is something I really don't want to deal with, because I don't know if I need it, and I don't know whether if I don't need it and I install it anyway, will that break something else or have some negative effect on my system?

I believe some of the builds in the old repo do have transcoding built in anyway, you don't have to use and not using it won't have any affect on your system in any way.

That's also why having so many choices in the repositories bothers me; I would be much happier if there were just a "normal" version for people like me, and a "nightly" version for all the people who want to be beta testers. Because when I have too many options like that, and particularly when the differences aren't clearly explained, I always wind up wondering if I made the right decision.

Choice is good! If you're unsure you should just stick to the stable branch..

Sorry I meant set the network to the adapter & you're done :p

Ah, okay, I think I understand now. The network(s) don't get automatically connected to the adapter(s) after the upgrade so you have to set those manually.

Anyway thanks for explaining all that, if nothing else it was quite educational. Probably won't do anything until later this week, so I am still weighing the options.

EDIT: After some consideration, I think the main thing that tips the scales for me is that Debian Wheezy only has “security support” until February 2016, and if I were to update to Debian Jessie, that has “security support” until May 2018. Whereas Ubuntu Server 14.04 LTS will have full support until April, 2019. So in the end I think I would be better off to try changing out the hard drive, installing Ubuntu Server 14.04 LTS and TVHeadEnd 4.1 (unless there is some reason I should stay in the 4.0 branch).

Stick with the stable branch unless you want unexpected breakages! I'll repeat.. "DON'T USE UNSTABLE UNLESS YOU WANT BREAKAGES" and in Japanese "Anata ga hason o shiyō suru baai ni kagiri, UNSTABLE shiyō shinaide kudasai"

and copying over my configuration using tar as you suggested. Then if it has any problems I can restore the original drive, but if copying the configuration works it won't take much longer than trying to upgrade TVHeadEnd on the existing system. This not only feels like the safest approach to me, but also the one that will (hopefully) cause me the least amount of grief in the future.

I hope I've helped somewhat..

Mark Clarkstone wrote:

So what you're saying here is you don't know how to remove software from your system? If you've installed it via dpkg you're still able to remove it using 'sudo apt-get remove tvheadend' that usually does the trick, the only thing it won't do is remove your config you can easily do that using 'sudo rm -r /home/hts/.hts'.

I had assumed that you could only use apt-get remove if you had previously installed using apt-get install. Then again, I could probably count the number of times I've used dpkg to install software on a Linux system on one hand.

After removing your self built deb and deleted your config, you simply install tvheadend again using 'sudo apt-get install tvheadend' (IIRC it'll use the one from the repos) once it's installed stop tvheadend 'sudo service tvheadend stop' then place folder contained within your backup into /home/hts/.hts and start it again using 'sudo service tvheadend start'. Provided you've extracted and the permissions are correct you shouldn't have any issues.

Okay, I was overlooking the obvious here. Sorry about that, I had just thought that maybe there was specific method to roll back to an earlier release. Simple reinstallation didn't occur to me.

The 4.1.x is the development version and should not really be used at all unless you want unexpected crashes and bugs. The releases 4.0.x are meant to be the most stable as they won't have any of the WIP code that goes into 4.1.x the only updates that do make it into 4.0.x are backported from 4.1 these are usually bug fixes and anything that causes major problems.

Once again you have provided me with some very useful information. Would I be incorrect in thinking that (non-nightly) versions with odd numbers after the decimal point (such as 3.9 and 4.1) are development versions, and those with even numbers (3.4 and 4.0) are the stable versions? If that is true, that may explain why I am getting this strange bug in the 3.9 version.

to enable transcoding? Now, my question would be, is transcoding included in the pre-built versions from the repositories? And do I even need it?

Yes it is included in the pre-built version, and no you don't have to use it but some people do.

Okay. At this point in time I just don't need it, unless there is some way to actually provide the settings to ffmpeg (so I could stop using the pipe method to fix the audio on those channels). I have never really understood how TVHeadEnd does transcoding, but since I've never needed it I never really tried to understand it.

Because the 3.4 branch did not support satellite TV all that well and in particular I would not have been able to do the audio fix mentioned above in the 3.4 branch (according to the article I referenced, that requires version 3.9.2100 or later, though I have no idea why that requirement exists).

I think that may have been around the time piping was added.

Now that you mention it, that sounds about right.

Unless it's listed as a new releases on tvheadend.org then it isn't for general use, but if you've been told upgrading to the unstable (at the time) would fix your issues then that's fair enough.

I wish I could remember what it was about 3.4 that made it less desirable for use with satellite feeds. And I want to say that it was Jaroslav Kysela that suggested using 3.9 to resolve those issues, but don't hold me to that - that was over a year ago, and I just don't recall the specifics anymore.

But on Debian Wheezy I would not have had that option anyway.

True and this is an issue no one seems to be interested in fixing as Wheezy is pretty much EOL. And unless the old build scripts get fixed it won't be changing any time soon.

Well that's kind of where my thinking is - if I have to go through the bother of upgrading I might as well switch to Ubuntu Server which has a longer support period, rather than staying with something that will be unsupported (at least partially) in a few more months. Now that I know that there's a pretty good chance I won't need to re-enter the entire configuration manually, the idea of starting over with a different distro isn't quite as off-putting.

I believe some of the builds in the old repo do have transcoding built in anyway, you don't have to use and not using it won't have any affect on your system in any way.

Good to know. My only concern was if it would unnecessarily eat CPU cycles or something.

Stick with the stable branch unless you want unexpected breakages! I'll repeat.. "DON'T USE UNSTABLE UNLESS YOU WANT BREAKAGES" and in Japanese "Anata ga hason o shiyō suru baai ni kagiri, UNSTABLE shiyō shinaide kudasai"

Got it. Wish I'd known that a couple months ago; I built a backend on an older Mac Mini that is strictly for use with over-the-air (terrestrial) signals, and used 4.1 for that because I didn't realize the difference. It hasn't given me any trouble at all so far, so I'm not too worried about it, but had I known I would have stayed with 4.0. Really, there should be an explanation of this on the TVHeadEnd download page, since I think most people would assume that the "unstable" version contains fixes that haven't yet made it into the stable version, but has had more testing than the nightly releases. I guess I had always thought of the unstable releases as something akin to "release candidates" in Kodi, which although they may contain a few remaining bugs are mostly ready for use. But you're suggesting that the TVHeadEnd unstable versions are more akin to early alpha versions of Kodi.

I hope I've helped somewhat..

You've helped me a great deal and I much appreciate it. Some of the things we have talked about in this thread are things I've wondered about since I started using TVHeadEnd. I changed the subject line on this thread because although my original question wasn't about upgrading or reinstalling TVHeadEnd, that's sort of where this thread went, and the useful information given here really shouldn't be buried under a non-descriptive subject line.

K Shea wrote:

Mark Clarkstone wrote:

So what you're saying here is you don't know how to remove software from your system? If you've installed it via dpkg you're still able to remove it using 'sudo apt-get remove tvheadend' that usually does the trick, the only thing it won't do is remove your config you can easily do that using 'sudo rm -r /home/hts/.hts'.

I had assumed that you could only use apt-get remove if you had previously installed using apt-get install. Then again, I could probably count the number of times I've used dpkg to install software on a Linux system on one hand.

After removing your self built deb and deleted your config, you simply install tvheadend again using 'sudo apt-get install tvheadend' (IIRC it'll use the one from the repos) once it's installed stop tvheadend 'sudo service tvheadend stop' then place folder contained within your backup into /home/hts/.hts and start it again using 'sudo service tvheadend start'. Provided you've extracted and the permissions are correct you shouldn't have any issues.

Okay, I was overlooking the obvious here. Sorry about that, I had just thought that maybe there was specific method to roll back to an earlier release. Simple reinstallation didn't occur to me.

The 4.1.x is the development version and should not really be used at all unless you want unexpected crashes and bugs. The releases 4.0.x are meant to be the most stable as they won't have any of the WIP code that goes into 4.1.x the only updates that do make it into 4.0.x are backported from 4.1 these are usually bug fixes and anything that causes major problems.

Once again you have provided me with some very useful information. Would I be incorrect in thinking that (non-nightly) versions with odd numbers after the decimal point (such as 3.9 and 4.1) are development versions, and those with even numbers (3.4 and 4.0) are the stable versions? If that is true, that may explain why I am getting this strange bug in the 3.9 version.

I think that's right don't quote me on it though..

to enable transcoding? Now, my question would be, is transcoding included in the pre-built versions from the repositories? And do I even need it?

Yes it is included in the pre-built version, and no you don't have to use it but some people do.

Okay. At this point in time I just don't need it, unless there is some way to actually provide the settings to ffmpeg (so I could stop using the pipe method to fix the audio on those channels). I have never really understood how TVHeadEnd does transcoding, but since I've never needed it I never really tried to understand it.

There may be a way to fix this if you open a feature request with a mux sample of the split audio streams Jaroslav might be able to add a workaround somehow.

Because the 3.4 branch did not support satellite TV all that well and in particular I would not have been able to do the audio fix mentioned above in the 3.4 branch (according to the article I referenced, that requires version 3.9.2100 or later, though I have no idea why that requirement exists).

I think that may have been around the time piping was added.

Now that you mention it, that sounds about right.

Unless it's listed as a new releases on tvheadend.org then it isn't for general use, but if you've been told upgrading to the unstable (at the time) would fix your issues then that's fair enough.

I wish I could remember what it was about 3.4 that made it less desirable for use with satellite feeds. And I want to say that it was Jaroslav Kysela that suggested using 3.9 to resolve those issues, but don't hold me to that - that was over a year ago, and I just don't recall the specifics anymore.

Jaroslav is the main man around here atm so if he told you to upgrade then you upgrade is all I'm going to say :p

But on Debian Wheezy I would not have had that option anyway.

True and this is an issue no one seems to be interested in fixing as Wheezy is pretty much EOL. And unless the old build scripts get fixed it won't be changing any time soon.

Well that's kind of where my thinking is - if I have to go through the bother of upgrading I might as well switch to Ubuntu Server which has a longer support period, rather than staying with something that will be unsupported (at least partially) in a few more months. Now that I know that there's a pretty good chance I won't need to re-enter the entire configuration manually, the idea of starting over with a different distro isn't quite as off-putting.

I believe some of the builds in the old repo do have transcoding built in anyway, you don't have to use and not using it won't have any affect on your system in any way.

Good to know. My only concern was if it would unnecessarily eat CPU cycles or something.

It won't, it'll only do that if you do use it and it isn't enabled by default in any way.

Stick with the stable branch unless you want unexpected breakages! I'll repeat.. "DON'T USE UNSTABLE UNLESS YOU WANT BREAKAGES" and in Japanese "Anata ga hason o shiyō suru baai ni kagiri, UNSTABLE shiyō shinaide kudasai"

Got it. Wish I'd known that a couple months ago; I built a backend on an older Mac Mini that is strictly for use with over-the-air (terrestrial) signals, and used 4.1 for that because I didn't realize the difference. It hasn't given me any trouble at all so far, so I'm not too worried about it, but had I known I would have stayed with 4.0.

Using git master/unstable can be fine just be aware that anything could change & screw things up. Unstable is for testing or for those that want to live on the edge. I currently use git unstable and believe me things have broken badly but Jaroslav is almost always lightning fast with the fixes, it sometimes makes me wonder if his fingers are on fire..

Really, there should be an explanation of this on the TVHeadEnd download page, since I think most people would assume that the "unstable" version contains fixes that haven't yet made it into the stable version, but has had more testing than the nightly releases. I guess I had always thought of the unstable releases as something akin to "release candidates" in Kodi, which although they may contain a few remaining bugs are mostly ready for use. But you're suggesting that the TVHeadEnd unstable versions are more akin to early alpha versions of Kodi.

I personally haven't had much issues with unstable and even when I have they've always been minor and fixed PDQ but still someone has to test them!

I hope I've helped somewhat..

You've helped me a great deal and I much appreciate it. Some of the things we have talked about in this thread are things I've wondered about since I started using TVHeadEnd. I almost feel bad that the subject title on this thread isn't something more along the lines of "Tips for upgrading/reinstalling TVHeadEnd" because although that wasn't my original question, that's sort of where this thread went, and the useful information you've given here really shouldn't be buried!

Documentation is a bit all over the place at the moment but yes I agree.

Well just to let you know, I just installed Ubuntu Server 14.04 and TVHeadEnd 4.0.7 onto a different drive, and copied the configuration using the "tar" method and it all went beautifully - didn't even have to reselect the networks under the adapters or enable them; it found them all! Of course I made sure that the TBS drivers were installed and working prior to installing TVHeadEnd, so that may have made a difference. Strangely it also sees the HDHomeRuns even though I did NOT install any drivers for them (those are the ones I set up the other backend on the Mac Mini for). I didn't enable those on this system and don't plan to in the short term (a bit worried about oversaturating the network connection if I try to do it all one machine), but it surprises me that it now detects the HDHomeRuns out of the box, so to speak. Also, going to the the "Digital Video Recorder" tab doesn't crash the system now, so whatever the problem was, upgrading appears to have fixed it.

So once again a HUGE THANK YOU to Mark Clarkstone for all the help and information, you literally saved me hours of reconfiguration, and greatly increased my understanding in the process!

I built a backend on an older Mac Mini

Curious: what is the Mini running for it's OS? Deb, or something else?

Maury Markowitz wrote:

I built a backend on an older Mac Mini

Curious: what is the Mini running for it's OS? Deb, or something else?

Ubuntu Server, but you may have to use a Mac-specific version such as this:

http://cdimage.ubuntu.com/releases/14.04/release/ubuntu-14.04.3-server-amd64+mac.iso

The reason is that the regular version of the Ubuntu installer boots up to a screen asking you to pick a boot type 1 or 2, but there is NO way to pick either one because neither the keyboard nor the mouse is responsive. The Mac-specific version avoids that problem, and once it's installed it's just a normal Ubuntu Server installation no different from the regular version.

EDIT: One thing I forgot to mention is that normally the Mac Mini also will not boot if there is no display connected. So if you hook up a display for the install and then unplug it after it's installed, you may find it won't boot after that until you reconnect the display. I don't know for sure if that's true with Ubuntu Server but I know it's definitely an issue with the versions of Ubuntu that have a desktop (basically any non-server version). If you want to run a desktop version or if that is also true about the server version, there is a way to fake it out to make it think that there is a monitor connected that is shown here: http://soledadpenades.com/2009/02/10/mac-mini-as-a-headless-server/

EDIT 2: Also I just remembered that Ubuntu doesn't always control the Mac Mini's fan correctly - keep an eye on your internal temps. Or you could install macfanctld (sudo apt-get install -y macfanctld) - the settings are in /etc/macfanctl.conf, I use the following but it is a bit of a tradeoff between how much fan noise you can tolerate and how warm you think is too warm. I like mine to run cooler and it's located in a spot where the fan noise isn't noticeable to me.

fan_min: 2500

temp_avg_floor: 25
temp_avg_ceiling: 40

temp_TC0P_floor: 30
temp_TC0P_ceiling: 43

temp_TG0P_floor: 30
temp_TG0P_ceiling: 43

You can run the sensors command to check the fan speeds and temperatures at any time; if you have never run it before it may ask you to install a package (lm-sensors if I recall) before it will work, so go ahead and do that.