Message ID | 4527B13D.7080202@cadsoft.de |
---|---|
State | New |
Headers |
Received: from raven.cadsoft.de ([217.7.101.211]) by www.linuxtv.org with esmtp (Exim 4.50) id 1GWCbw-0001jV-RM for vdr@linuxtv.org; Sat, 07 Oct 2006 15:53:04 +0200 Received: from [192.168.100.10] (hawk.cadsoft.de [192.168.100.10]) by raven.cadsoft.de (8.13.3/8.13.3) with ESMTP id k97Dr33B017071 for <vdr@linuxtv.org>; Sat, 7 Oct 2006 15:53:03 +0200 Message-ID: <4527B13D.7080202@cadsoft.de> Date: Sat, 07 Oct 2006 15:53:01 +0200 From: Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de> Organization: CadSoft Computer GmbH User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: vdr@linuxtv.org Subject: Re: [vdr] Bug in audio track replaing References: <Pine.GSO.4.63.0610031653310.17252@galaxy.agh.edu.pl> <4527AE85.4090809@cadsoft.de> In-Reply-To: <4527AE85.4090809@cadsoft.de> Content-Type: multipart/mixed; boundary="------------080100020807000005030009" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (raven.cadsoft.de [192.168.1.1]); Sat, 07 Oct 2006 15:53:04 +0200 (CEST) X-BeenThere: vdr@linuxtv.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: VDR Mailing List <vdr@linuxtv.org> List-Id: VDR Mailing List <vdr.linuxtv.org> List-Unsubscribe: <http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr>, <mailto:vdr-request@linuxtv.org?subject=unsubscribe> List-Archive: <http://www.linuxtv.org/pipermail/vdr> List-Post: <mailto:vdr@linuxtv.org> List-Help: <mailto:vdr-request@linuxtv.org?subject=help> List-Subscribe: <http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr>, <mailto:vdr-request@linuxtv.org?subject=subscribe> X-List-Received-Date: Sat, 07 Oct 2006 13:53:05 -0000 Status: O X-Status: X-Keywords: X-UID: 10837 |
Commit Message
Klaus Schmidinger
Oct. 7, 2006, 1:53 p.m. UTC
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
Comments
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
--- epg.c 2006/08/05 10:04:17 1.79 +++ epg.c 2006/10/07 13:47:28 @@ -87,7 +87,8 @@ tComponent *cComponents::GetComponent(int Index, uchar Stream, uchar Type) { for (int i = 0; i < numComponents; i++) { - if (components[i].stream == Stream && components[i].type == Type) { + // In case of an audio stream the 'type' check actually just distinguishes between "normal" and "Dolby Digital": + if (components[i].stream == Stream && (Stream != 2 || (components[i].type < 5) == (Type < 5))) { if (!Index--) return &components[i]; }