Issue with multiple audio pids with same language
I have a number of channels in the UK on DVB-T which when viewed through the tvheadend XBMC PVR addon initially have no audio. When I go into audio settings I see there is another audio stream, with the correct audio.
When I look at the dvb transport file for the channel (example attached) I see that there are multiple audio pids with the language "eng". The order of the pids in the file suggests that tvheadend reports the higher pid id first. if I re-order these then the next time the channel is opened in xbmc I get the right audio stream first, but then tvheadend rescans the transport and re-writes the file, causing the channel to pull up the wrong audio by default next time. Turning off automated channel scanning and mux scanning on the adapter doesn't stop tvheadend rewriting the file.
I think the problem is in the UK there are many channels which have "audio described" content, and the second audio pid contains the audio descibed stream.
Could tvheadend please do one of the following:
1) If two audio pids are presented for the same language, default to providing the lowest pid id as the first stream, of course there may be other priorities, such as reporting AC3 streams first, but if the language and channels are the same, report the lowest pid first.
2) Allow the default audio pid to be identified in the configuration, and provide this always as the default stream.
Updated by Hein Rigolo over 9 years ago
are you sure that there is no other identifying information in the DVB-SI tables that can be used to pick the "correct" audio stream that needs to be identified as the primary audio track?
It could be that on the UK DVB-T implementation they have chosen to use the lower number as the default, but in an other DVB network the higher number. You should never base any logic in DVB streams on the actual PID number as far as I can tell.
Updated by peely - over 9 years ago
I did check the file (attached earlier) and there is nothing that identifies one from the other, apart from the pid itself. If I cheekily change the order in the file it works for the next channels selection then as the mux is re-read the file is reset.
Hopefully your patch will solve the problem, thanks.