Tvheadend

What audio codec(s) are the missing streams using? VLC will tell you, if it's not obvious elsewhere.

And are they unique to those channels, i.e. are all other (working) channels using something different? I wonder if it's an MP2-vs-AC3 issue, perhaps even how your audio output is then configured on the Pi2. I presume it's just HDMI to a television with no passthrough device enabled in Kodi?

Thanks for suggesting VLC.

These are what I gather from the 2 channels using VLC:

1. Codec information from WORKING audio stream:
Type: Audio
Original ID: 230
Codec: MPEG AAC Audio (mp4a)
Language: English
Channels: 3F2R/LFE
Sample rate: 48000 Hz
AAC extension: SBR

2. Codec information from NON-WORKING audio stream:
Type: Audio
Original ID: 631
Codec: MPEG AAC Audio (mp4a)
Language: English
Channels: Stereo
Sample rate: 44100 Hz
AAC extension: SBR+PS

Could it be the AAC extension (SBR+PS) causing the problem?

Could well be - although most posts I can find on the Kodi forum seem to be pretty old if they have similar problems. It appears that AAC (SBR+PS) = HE-AAC, for what it's worth...

https://en.wikipedia.org/wiki/High-Efficiency_Advanced_Audio_Coding

Thoughts to nail this down further:

1. Does VLC play that audio stream? > tvheadend is working and it's a Kodi/Pi/Openelec issue

2. Can you record that channel? Does Kodi play it back then? > it's a tvh addon issue

3. Can you play the recording on anything else? ==> tvh is recording it okay, so it's back to Kodi in some guise

... and so on. If you can record something and upload it then I can try it on OpenElec (non-Pi) and Kodi on some other platforms to see how it plays there. That may help nail it down.

It doesn't sound like a tvheadend issue, though, but let's see if we can isolate it. The fact they play in the WebUI under Windows suggests that the stream is okay and that it's a Kodi issue - perhaps specific to the Pi for some reason? We have some Debian Pi users on here as well, so that's another place to test - in fact, I think I have Kodi on a Pi2 somewhere as well...

1. No. VLC could not play the audio stream. On another hand, Media Player Classic could.

2. I have recorded a clip about a minute long. Kodi (on RPi2) can playback with audio.

3. I have upload the clip to my dropbox:

https://www.dropbox.com/s/v1js5e8fokj5qcw/Ch%20U.ts?dl=0

Thank you for your help.

Okay, it looks like it's likely to be an ffmpeg problem.

Streaming it from Dropbox in my browser - Chrome 46.0.2490.80 (64-bit) on Ubuntu - and I can play both streams

VLC 2.1.6 on the same Ubuntu box won't play either stream. Remuxing to mkv at least gives me:

No suitable decoder module:
VLC does not support the audio or video format "mp4a". Unfortunately there is no way for you to fix this.

parole 0.6.1 on the same box won't play the file at all - either the native .ts or remuxed .mkv

Kodi 15.2 git 02e7013 on the same box will play either stream

Kodi 16.0-BETA1 git 2015-11-08 a645bf8 plays both streams as well

I can test on some other systems inc. OpenElec 6 for you later on, but the file seems fine - so it's not a tvheadend issue; I suspect that the fault lies somewhere else...

Thank you very much

VLC 2.2.1 on Win7 - no, neither stream...

OpenElec 6.0 - Nvidia legacy - Kodi 15.2 git 02e7013 (Isengard final) - x86/ION - both streams play

Kodi 15.2 git 02e7013 on Win10 - both streams play

VLC 2.2.1 on Win10 - neither stream play

Kodi 15.2 git 2015-10-27-17fa8da on Android - both streams play

Kodi 14.2 git 7cc53a9 on Pi2 (raspbian) - both streams play

All Kodi sources are mapped over NFS, by the way.

I think that's fairly comprehensive... it's not the file; it's something about the version of ffmpeg on your Pi (or in that Kodi build), or it's specifically an issue with how you're playing it (NFS/SMB, UPnP, via the tvh addon...). That'd be my next thing to test. But it's not tvheadend itself IMO.

Thank you for the extensive testings!!

Hmm..
Tvheadend server has no problem recording the streams.
And Kodi on RPi2, could playback the recorded clip with audio.

I am wondering if it is Tvheadend PVR client having difficulty in
identifying the audio streams due to the AAC extension: SBR+PS?

Okay, I think I have an answer for you from IRC #hts... and you're right.

It would seem that tvheadend translates AAC audio into another container format as part of HTSP streaming. If you want the details, read this:

https://en.wikipedia.org/wiki/Advanced_Audio_Coding#Container_formats

tvh is using ADTS at the moment, which doesn't support all of the AAC extensions; a move to use LATM is on the plan for release 4.4, but it won't make it into 4.2 (which is the next release, due shortly).

Net result of that: AAC streams with spectral band replication (SBS) or parametric stereo (PS) have difficulty over tvheadend's handling of HTSP. That means they won't work properly when watching live TV through the Kodi tvheadend addon (pvr.hts) or anything else that relies on HTSP. Playback of recordings is slightly different, so these should play back fine via the addon or if you play them either locally or over a network share. That's all consistent with what we've found here: the file is fine, it's specifically HTSP streaming that struggles.

Thank you for the information.
Will do some reading for better understanding.

Great to know that tvh has plans to better support AAC extensions.
Double thumbs up!!

Greatly appreciate your help.
Thank you again.