Why you’re not hearing full surround sound on some satellite channels – or maybe just think you aren’t

This is a followup to a previous article, I hear there’s a problem with playing satellite audio…, but I will try to go into a bit more detail here.

When you watch TV from a terrestrial TV station using a regular TV antenna, and you are using an audio receiver that supports 5.1 audio, you will often hear full surround sound, particularly from the major network stations. But when you run a backend system such as TVHeadEnd, and use Kodi to watch live or recorded programs from free-to-air satellite channels, you may see both Kodi and your receiver indicate that you are only receiving stereo (2.0) audio. This might be expected on a station or network that carries primarily old shows from the days of black and white TV, but if you happen to come across a network feed channel, you might be surprised to see that you’re still only getting stereo audio. This can be especially confusing if your ears are telling you that you’re hearing 5.1 audio, but Kodi and your receiver’s display indicate otherwise (no, you’re not going crazy).

Without getting too much into technical details, the issue is that most TV stations that transmit full surround sound encode the audio using a consumer friendly format, typically Dolby Digital. In North America, the ATSC standards specify Dolby Digital as the audio codec. Some satellite channels also transmit their audio in Dolby Digital format. If they do, and if the audio is 5.1 surround sound, chances are that both Kodi and your audio receiver will recognize that it’s receiving 5.1 surround sound.

But network feeds are not intended for consumers; they are intended for television stations. And therefore, each network can (and often does) use its own format for sending audio signals. A typical DVB-S or DVB-S2 satellite transport stream will contain several packetized elementary streams that can contain video, data, and most important for this discussion, audio.

A common situation is to see several audio streams that contain pairs of channels. The important thing to note is that the network can define these channels any way it wants to. As long as their stations can retrieve the audio and get it on the air in a format that consumer television receivers understand, that’s all that matters to the company that’s uplinking the signals.

In many cases the uplinkers will put a pair of mp2 audio channels on the first audio stream. If those channels are encoded using Dolby Digital or Dolby Digital Plus format, then both Kodi and the receiver will generally indicate the true number of channels. However, there are other audio formats that are not intended for direct reception by end users, such as Dolby E, which is described as:

An audio encoding technology, Dolby E enables broadcasting and postproduction facilities to carry up to eight channels of sound over their existing stereo (two-channel) infrastructures.

Dolby E is not intended for reception by home viewers:

Unlike some other Dolby technologies, the Dolby E signal never reaches your home viewer. Rather, it’s decoded back to baseband audio just prior to the final transmission and then reencoded into the final audio format—Dolby Digital, for example, or Dolby Digital Plus™.

Now if a satellite feed uses Dolby E, or some other format not intended for reception by home viewers, in theory that audio (or at least the extra channels beyond basic stereo) can’t be heard by the home viewer. And Kodi, and perhaps your receiver, will tell you that you are receiving MP2, 2.0 audio. Kodi doesn’t know what the format really is, so it doesn’t display any indicator for it.

And, whoever programmed the display for your receiver probably thought that as a consumer, you’d never encounter a Dolby E signal, so there’s no display indication for it. BUT, and this is just speculation on my part, it’s quite possible that your receiver contains a decoder chip that can decode more formats that those that are listed in the receiver’s user manual. So if it has a Dolby decoder chip and sees a Dolby E signal, it just might decode it, without changing the receiver’s display to indicate that it is doing so. Thus, if you are lucky, you might hear the surround sound, even though there’s no indication on your receiver’s display about what format it’s actually receiving. You might have to play with the audio settings on your receiver to make this happen (see the end of the previous article, I hear there’s a problem with playing satellite audio…).

I understand there’s another multichannel format called SMPTE 302M (s302m) that might appear on the first audio stream. I don’t believe that any consumer grade equipment can decode that, and Kodi seems to be smart enough to realize that there’s nothing usable where, so it skips to the first non-s302m stream. I may be wrong about that, but available information on that format is rather sparse unless you want to pay $50 to get SMPTE’s technical documentation, which I don’t.

The bottom line is that if the uplinker is encoding their multichannel audio using a format that intended for reception by broadcasters and not by consumers, Kodi probably doesn’t know how to deal with it. But if you have enabled passthrough audio in Kodi, your receiver might be able to decode it. Otherwise, you’ll probably only hear stereo audio (if you’re lucky), unless you’re trying to watch the network that sends all the channels as discrete audio.

And if you use a standalone satellite receiver rather than a backend system, you’re kind of at the mercy of the manufacturer.  If the manufacturer spent the money to license the Dolby technology and has included an actual Dolby decoder chip, then you stand a far better chance of getting the surround sound than if the manufacturer was trying to build the receiver as cheaply as possible, and used no licensed decoder.  But if the satellite receiver can pass the received audio stream to an AV receiver via HDMI or S/PDIF, then it’s possible the receiver might still be able to decode it, assuming it can decode Dolby audio.


New TBS6704 ATSC/Clear QAM Quad Tuner PCIe Card may let you add OTA and/or unscrambled cable TV channels to your satellite backend

TBS6704 ATSC/ Clear QAM Quad Tuner PCIe Card

TBS6704 ATSC/ Clear QAM Quad Tuner PCIe Card

Those of you that run PVR backend software, such as TVHeadEnd or MediaPortal, may already be using one or more satellite tuner cards from TBS or some other manufacturer to bring your satellite signals into your backend. For quite some time TBS has also offered tuner cards capable of receiving over-the-air (OTA) signals in DVB-T format, which unfortunately is not used in the North American countries of Canada, the Dominican Republic, Mexico, and the U.S.A. (including its island territories). Instead, those countries (along with a couple of others, including South Korea) use ATSC for OTA signals, and in some cases QAM for cable channels.

The new TBS6704 ATSC/ Clear QAM Quad Tuner PCIe Card fills the void. This is the product description:

TBS6704 is an ATSC quad tuner PCIe card for receiving ATSC, 8VSB and Clear QAM cable TV on PC. This quad tuner card allows you to watch and record up to 4 over-the-air (OTA) digital terrestrial/ Clear QAM HD TV channels at the same time, which is ideal for enterprise IPTV streaming solution.

The main features are:

Receive digital ATSC, 8VSB and Clear QAM cable TV on PC
Quad tuner card for watching/ recording 4 channels at the same time
High sensitivity ATSC quad tuner for the best digital TV reception
MPEG-2 & H.264 HDTV support
Time shift & schedule recording support
Windows & Linux driver support

This product was just announced as I write this, so I don’t know of anyone who actually has one yet, and therefore can’t tell you how well it works. My experience is that the TVHeadEnd software does NOT natively support other ATSC solutions, such as the popular HDHomeRun devices from Silicon Dust. Apparently if you are really proficient in Linux, there is some way to recompile TVHeadEnd with HDHomeRun support, but for the rest of us who aren’t Linux gurus, that support might just as well not exist. However, TVheadEnd has always had no problem finding and using TBS satellite cards (provided you have installed the TBS drivers), so my suspicion is that it will also find and use the TBS6704 card with no problem.

Since this blog is specifically about Free-To-Air satellite, and not over-the-air reception, I won’t have much to say about OTA, but I just wanted to mention this card for those who have built a satellite backend system in one of the ATSC countries, and would like to add OTA reception. The fact that this card has four tuners (compared to two or three on equivalent HDhomeRun devices) may make it an attractive option for some users. The card can be purchased at BuyDVB.net; as I write this the price is $179.99 U.S. for a single unit, with quantity discounts available.

Getting bad satellite recordings in TVHeadEnd? Here’s a possible fix

I was perusing the TBS forum recently and discovered that there’s a problem that can occur, notably with certain TBS cards but possibly with others as well, that can result in semi-corrupted recordings. The .ts file that contains the recording actually contains the entire program, and can usually be repaired by chopping off a few megabytes at the start of the file, but as it sits on the TVHeadEnd server it’s not easily playable for one or both of two reasons:

  • It reports the wrong length (time) for the recoding – for example a one hour program may appear to be of a much greater length (several hours long), and/or
  • The video and audio are out of sync by a second or two, where this is not usually the case.

In Kodi, you can generally play such a recording from the start, but skipping around within the program may be problematic or impossible.

The possible fix for this is to set a “Skip Initial Bytes” setting for each tuner, as described in this post on the TBS forum.  The conversation there appears to be about a specific TBS card (the TBS6905) but I have heard of this problem happening with other cards as well.  As best I can understand the problem, the card starts sending a virtual firehose stream of data before the buffers are ready to receive it, and some data gets lost at the start, corrupting the file.  By skipping some initial bytes, you get only the “good” data once everything has had time to initialize.  That’s probably a gross oversimplification, but that’s what I got out of that thread.

The place to change the setting is here:

Configuration | DVB Inputs | TV adapters, in the “Advanced Settings” section

You might think the number of bytes skipped is quite high, but since even a 30 minute recording can contain several gigabytes of data, that number is actually insignificant.  The original poster in the thread states that “The 18800000 setting is a bit arbitrary; I chose it because it is more than 1 Meg and is the ‘Input Buffer (Bytes)’ value x 1000. If the issue persists I may try an even higher value.”  Feel free to experiment with lower or higher values; I personally think I’d start with something lower such as 188000 (10 times the Input Buffer) and then if that doesn’t resolve the issue, go up to 1880000. And if that still doesn’t always fix the problem, then go to the 18800000 value.  But, it’s entirely up to you.  And remember that if you have more than one tuner, you have to add this setting for each affected tuner.

The thread also notes, “If the new value doesn’t appear after you change it and click save, refresh the page in your browser, then navigate back to the TV adapters tab.”

If TVHeadEnd is creating these types of bad recordings on your backend server, I’d suggest this fix is at least worth a try, since you can easily reverse it if it turns out to not have any effect.

What if you already have a bad recording and want to fix it?

While the above advice may help you prevent future bad recordings, it will not help you fix an already recorded program that has bad timing information. Usually ffmpeg can fix the timing issues, so I have used this script to fix existing recordings:

# If calling from Tvheadend, invoke using path/to/scriptname "%b"
# Then $1=%b in this script
# Extension of converted file must be same as original file (.ts)!
cd /home/hts/recordings
/usr/bin/ionice -c 3 /usr/bin/nice -n 20 /usr/local/bin/ffmpeg -loglevel quiet -i "$1" -c copy -f mpegts "converted-$1" &> /dev/null
mv -f "converted-$1" "$1"

The line that starts with /usr is a long line, so you may need to copy the above script and paste it into a text editor to see it correctly. Note that you must run this as the hts user (or whatever user the Tvheadend service runs as) to avoid permissions issues (you can do sudo su hts to temporarily become the hts user). And you must check all the paths shown in this script to make sure they are valid for your system, and change them accordingly if they are not.

The first (non-comment) line changed the working directory to the directory where Tvheadend stores its recordings. The second line uses ffmpeg to convert the file – it simply copies all the audio, video, and data information but it does fix the timing information in most cases. The “/usr/bin/ionice -c 3 /usr/bin/nice -n 20” at the beginning of the line is to set this process to the lowest priority, so that if you are actively recording any channels at the time, it won’t steal CPU power or disk I/O from that activity. The final line moves the converted file over the original. You must move it over the original, not copy it, because Tvheadend will lose track of the recording if you try to copy it over. This script does not save a backup of the original file, so if you want one, copy the original file to a safe location prior to running this script.

To use the script, find the filename of the bad recording (you could do ls /home/hts/recordings) and then, as the hts user, just run the script with the filename as an argument. Note that it is also possible to call the script as a Post-processor command in a Digital Video Recorder Profile in Tvheadend, so that the script will run automatically when a program finishes recording (in case you have a channel that frequently gives you bad recordings, and you can’t use the method shown at the top of the page). See the comments at the top of the script for information.

If you are running on a system that doesn’t have the bash shell, this script will probably run just was well under whatever shell you have, although minor tweaking may be required. At the very least, you will need to change the #!/bin/bash line at the top. And, this assumes you have ffmpeg installed on your system – run which ffmpeg from the command line, and if ffmpeg is present then it will show the correct path to ffmpeg. If you don’t have ffmpeg installed and it isn’t available in your Linux distribution’s repository, then I suggest using a static build of ffmpeg, since it is much easier to install than trying to compile it from scratch. Just copy the ffmpeg program (and any of the others you may want) from the downloaded archive to the /usr/local/bin directory, and make sure the ownership and permissions are set correctly (should be owned by root, and executable by everyone). I use Midnight Commander (mc) to do these types of operations, but to each their own.

Obviously, the fix shown at the top of this article is a lot easier to implement than using ffmpeg to fix a bad recording once it’s already recorded (plus, using that method, you can start watching the show while it is still being recorded without issues) but some tuners may not have the “Skip Initial Bytes” setting, or changing it may not work for some tuners. In my experience it almost always works for TBS tuners (unless you are having a problem with low signal strength or quality), so try the “Skip Initial Bytes” setting first if it is available to you!