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: > CYFRA+ > RADIO:10892:h:S13.0E:27500:0:116=PR1,117=PR2,118=PR3,115=BIS,123=ZET,122= > RAD,124=PIN,121=TOK,120=JAZ,126=ANT:0:100:4841:318:11900:0 > > 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... Klaus
