Bug in audio track replaing

  Klaus Schmidinger wrote:
> Boguslaw Juza wrote:
>>     Hi!
>>
>> I have found small bug: When I have record channel witch multiple 
>> audio track - f.e. tracks witch language codes: A1, A2, A3, A4, and then
>> I replay it, when I'm choosing audio track, I have to choose:
>> POL, A1, A2, A3. POL plays A1 track, A1 plays A2 track etc...
>> PL (polish) is my preffered language in EPG menu, but there was no 
>> PL-track in this channel.
> 
> I was able to (sort of) reproduce this with the EURONEWS channel
> on Astra:
> 
> EURONEWS;CSAT:11817:vC34:S19.2E:27500:163:92=fra,93=eng,94=ita,95=esl,91=rus,98=por,99=deu:0:0:8004:1:1070:0 
> 
> 
> This channel also has several audio tracks, but in its event data
> it only lists the first two tracks. The tracks in the event data have
> a type of 0x01, while VDR in its cRecordingInfo::cRecordingInfo()
> function looks for tracks with type 0x03. Since VDR is only interested
> in whether this is a Dolby track or not, I've modified 
> cComponents::GetComponent()
> accordingly.
> 
> Please try the attached patch to see if it helps.
> 
> Note that this will only help for newly created recordings.
> Existing recordings may already have the tracks garbled in their
> info.vdr files.

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.

Klaus
  

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...


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"

                                       Boguslaw Juza
  

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
  

Klaus Schmidinger wrote:
> 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".

Please try the attached replacement for I18nNormalizeLanguageCode()
(this is not a patch, but the complete function).

Let me know if this works for you, so I can include it in the
next maintenance patch.

Klaus
const char *I18nNormalizeLanguageCode(const char *Code)
{
  for (int i = 0; i < 3; i++) {
      if (Code[i]) {
         // ETSI EN 300 468 defines language codes as consisting of three letters
         // according to ISO 639-2. This means that they are supposed to always consist
         // of exactly three letters in the range a-z - no digits, UTF-8 or other
         // funny characters. However, some broadcasters apparently don't have a
         // copy of the DVB standard (or they do, but are perhaps unable to read it),
         // so they put all sorts of non-standard stuff into the language codes,
         // like nonsense as "2ch" or "A 1" (yes, they even go as far as using
         // blanks!). Such things should go into the description of the EPG event's
         // ComponentDescriptor.
         // So, as a workaround for this broadcaster stupidity, let's ignore
         // language codes with unprintable characters...
         if (!isprint(Code[i])) {
            //dsyslog("invalid language code: '%s'", Code);
            return "???";
            }
         // ...and replace blanks with underlines (ok, this breaks the 'const'
         // of the Code parameter - but hey, it's them who started this):
         if (Code[i] == ' ')
            *((char *)&Code[i]) = '_';
         }
      else
         break;
      }
  int n = I18nLanguageIndex(Code);
  return n >= 0 ? I18nLanguageCode(n) : Code;
}
  

On Sun, 8 Oct 2006, Klaus Schmidinger wrote:

> Klaus Schmidinger wrote:

> Please try the attached replacement for I18nNormalizeLanguageCode()
> (this is not a patch, but the complete function).
> Let me know if this works for you, so I can include it in the
> next maintenance patch.

It works. And while replaing, name od first track ("A_1") is replaced by
"pol", still.

                                           Boguslaw Juza
  

Boguslaw Juza wrote:
> On Sun, 8 Oct 2006, Klaus Schmidinger wrote:
> 
>> Klaus Schmidinger wrote:
> 
>> Please try the attached replacement for I18nNormalizeLanguageCode()
>> (this is not a patch, but the complete function).
>> Let me know if this works for you, so I can include it in the
>> next maintenance patch.
> 
> It works. And while replaing, name od first track ("A_1") is replaced by
> "pol", still.

Well, technically "A 1" is not a three letter language code
according to the DVB standard. Putting "track names" into
the "language code" data is simply brain dead.

Klaus