[vdr] Bug in audio track replaing
Klaus.Schmidinger at cadsoft.de
Sat Oct 7 16:34:13 CEST 2006
Boguslaw Juza wrote:
> On Sat, 7 Oct 2006, Klaus Schmidinger wrote:
>> Klaus Schmidinger wrote:
>> Actually here's a more elaborate patch.
>> It also explicitly checks for the audio stream.
>> Wouldn't make a difference right now, but if we have more
>> streams later, it might be necessary.
> There is no correct still, but something changes:
> At channel:
> after recording and replaying name of first track was replaced from
> "PR1" to "pol", but there was no shift - PR2 still was PR2, etc...
The "pol" comes from the language code in the event's stream component
descriptor, which takes precedence over the pid's language code.
> At channel:
> XtraMusicPop:11278:v:S13.0E:27500:0:611=A 1,612=A 2,613=A 3,614=A
> 4,615=A 5,616=A 6,617=A 7,618=A 8,619=A 9,620=A10:0:100:13042:318:400:0
> is smillar, but "A " is eaten - so, while replaying, there are avaliable
> tracks: "pol", "2", "3", ..., "A10"
The problem here are the blanks on the "language codes", which
cause tComponent::FromString() to split "A 1" into a language code
of "A" and a description of "1".
First of all, it's a pretty dumb idea of the providers to abuse
the "three letter language codes" for anything else than actual
*language codes*. So the problems are actually caused by the
broadcaster's failure to adhere to the DVB standard.
As a workaround we could change any blanks in the language codes
to underlines. I just have to see where this can be done best...
More information about the vdr