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.
Boguslaw Juza
Hi!
I have got big request for Author - It would be nice to make "spaces" in channels list. I want to set "info channels" from 1 to 8, "movie channels" form 10 to 15, sport from 20 etc... So I need to make empty spaces witch ch. numbers 9, 16-19... etc. Switching channels Up/Down should skip spaces.
And second thing - hidden or pin-lock channels. There are some channels, which i dont want to show to others people (somebody plays with remote). It would be nice to set its as pin-locked or something...
Boguslaw Juza
Boguslaw Juza wrote:
I have got big request for Author - It would be nice to make "spaces" in channels list. I want to set "info channels" from 1 to 8, "movie channels" form 10 to 15, sport from 20 etc... So I need to make empty spaces witch ch. numbers 9, 16-19... etc. Switching channels Up/Down should skip spaces.
From man 5 vdr:
The file channels.conf contains the channel configuration. Each line defines either a group delimiter or a channel.
A group delimiter is a line starting with a ':' as the very first char- acter, followed by arbitrary text. Example:
:First group
Group delimiters may also be used to specify the number of the next channel. To do this, the character '@' and a number must immediately follow the ':', as in
:@201 First group
The given number must be larger than the number of any previous channel (otherwise it is silently ignored).
A group delimiter can also be used to just set the next channel's num- ber, without an explicit delimiter text, as in
:@201
Such a delimiter will not appear in the Channels menu.
Cheers,
Udo
Hi!
There are some channels witch EPG ShortText is the same as Description (and a few sentences long). So I'm suggesting little change in skinclassic.c (and probably in skinsttng.c too):
in cSkinClassicDisplayMenu::SetEvent
- y += font->Height(); - if (!isempty(Event->Description())) { - textScroller.Set(osd, xl, y, x1 - xl - 2 * ScrollWidth, y3 - y,... - SetScrollbar(); - }
+ if((isempty(Event->ShortText()))||(isempty(Event->Description()))|| + (strncmp(Event->ShortText(),Event->Description(),8))) { + y += font->Height(); + if (!isempty(Event->Description())) { + textScroller.Set(osd, xl, y, x1 - xl - 2 * ScrollWidth, y3 - y,... + SetScrollbar(); + } + }
and the like in cSkinClassicDisplayMenu::SetRecording
Boguslaw Juza
Boguslaw Juza wrote:
Hi!There are some channels witch EPG ShortText is the same as Description (and a few sentences long). So I'm suggesting little change in skinclassic.c (and probably in skinsttng.c too): ...
Doesn't the "EPG bugfix #7" already take care of this:
// Some channels put the same information into ShortText and Description. // In that case we delete one of them: if (shortText && description && strcmp(shortText, description) == 0) { if (strlen(shortText) > MAX_USEFUL_EPISODE_LENGTH) { free(shortText); shortText = NULL; } else { free(description); description = NULL; } EpgBugFixStat(7, ChannelID()); }
Maybe you have disabled the "EPG bugfix level" setup option?
Klaus
On Wed, 4 Oct 2006, Klaus Schmidinger wrote:
Doesn't the "EPG bugfix #7" already take care of this: // Some channels put the same information into ShortText and Description. // In that case we delete one of them: ... Maybe you have disabled the "EPG bugfix level" setup option?
I have "EPG bugfix level" set to 3. The point is - ShortText and Description are near the same - one of them is a few characters longer. Perheaps it would be better to compare only a few first characters? I have sugested 8 - if both text starts from the same word(s), they its very probably, its near the same.
Or... strncmp(ShortText,Description, strlen(ShortText)>strlen(Description)?strlen(Description):strlen(ShortText))
Boguslaw Juza
Boguslaw Juza wrote:
On Wed, 4 Oct 2006, Klaus Schmidinger wrote:
Doesn't the "EPG bugfix #7" already take care of this: // Some channels put the same information into ShortText and Description. // In that case we delete one of them: ... Maybe you have disabled the "EPG bugfix level" setup option?
I have "EPG bugfix level" set to 3. The point is - ShortText and Description are near the same - one of them is a few characters longer. Perheaps it would be better to compare only a few first characters? I have sugested 8 - if both text starts from the same word(s), they its very probably, its near the same.
Or... strncmp(ShortText,Description,
strlen(ShortText)>strlen(Description)?strlen(Description):strlen(ShortText))
I'm afraid that would cause a lot of irritation.
The two texts are either exactly the same (in which case one of them will be deleted) or they are different, in which case both will be kept.
Maybe it would help to contact the broadcaster and ask them to provide better EPG data?
Klaus
On Wed, 4 Oct 2006, Klaus Schmidinger wrote:
The two texts are either exactly the same (in which case one of them will be deleted) or they are different, in which case both will be kept.
Well - text - two/three sentences. Diffrence - one of them are cutted a word earlier. There are not the same for computers, but people have different opinion. :)
Maybe it would help to contact the broadcaster and ask them to provide better EPG data?
Do you realy belive that it helps? They will say "Use one of receivers recommended by us" :).
Boguslaw Juza
Boguslaw Juza wrote:
On Wed, 4 Oct 2006, Klaus Schmidinger wrote:
The two texts are either exactly the same (in which case one of them will be deleted) or they are different, in which case both will be kept.
Well - text - two/three sentences. Diffrence - one of them are cutted a word earlier. There are not the same for computers, but people have different opinion. :)
VDR can only reasonably check for "equal" or "different". Anything else would probably require tons of configuration parameters, because every user would want it differently.
Maybe it would help to contact the broadcaster and ask them to provide better EPG data?
Do you realy belive that it helps?
You'll never know if you don't try ;-)
They will say "Use one of receivers recommended by us" :).
I don't see how the problem of texts being "almost the same" has anything to do with the receiver - unless it displays only one of the two texts, in which case it should be dumped, anyway.
Klaus
I have investigated it more carefully:
Broadcaster sends only shortText.
VDR reads the Epg event. At EpgBugFix #6 VDR moves shortText to description if description is empty
EPG in this state are saved in epg.data.
After restart VDR reads epg.data. Then scans this event again. Event already have description, so it doesn't make BugFix #6 and now we have shortText and description the same.
Not exacly the same. Becouse "old" descrypion is after BugFix corrections. So there is no BugFix #7 corection. But at the funcion end we have the same texts.
I have commented EpgBugFix #6 and VDR now works correctly.
Boguslaw Juza
Boguslaw Juza wrote:
I have investigated it more carefully:
Broadcaster sends only shortText.
VDR reads the Epg event. At EpgBugFix #6 VDR moves shortText to description if description is empty
EPG in this state are saved in epg.data.
After restart VDR reads epg.data. Then scans this event again. Event already have description, so it doesn't make BugFix #6 and now we have shortText and description the same.
Not exacly the same. Becouse "old" descrypion is after BugFix corrections. So there is no BugFix #7 corection. But at the funcion end we have the same texts.
Ah, that's an interesting finding.
So I guess it will make sense to make sure an event that is newly received from the data stream has *all* its data refreshed from the stream. If there is no short text, for instance, an already existing short text needs to be deleted etc.
Thanks for this report, I'll see how it can be fixed.
Klaus
On Wed, 4 Oct 2006, Klaus Schmidinger wrote:
So I guess it will make sense to make sure an event that is newly received from the data stream has *all* its data refreshed from the stream. If there is no short text, for instance, an already existing short text needs to be deleted etc.
If you moving ShortText to Description, maybe you could generate small ShortText based on description? For example:
ShortTextLen=strlen(Description); if(ShortTextLen>31)ShortTextLen=31; for(a=ShortTextLen;a>0;a--)if(Description[a]==' ')break; if(a>0)ShortTextLen=a;
ShortText=(char *)malloc(ShortTextLen+4); memcpy(ShortText,Description,ShortTextLen); strcpy(ShortText+ShortTextLen,"...");
Boguslaw Juza
On Thu, 5 Oct 2006, Boguslaw Juza wrote:
If you moving ShortText to Description, maybe you could generate small ShortText based on description? For example: ...
Ugh... Few posts ago I sugested to removing these duplicates... :)
From the other way - I want generated shortText in situations, where
description is not displayed - for example in channel info (cSkinClassicDisplayChannel::SetEvents)
Boguslaw Juza
Klaus Schmidinger wrote:
Boguslaw Juza wrote:
I have investigated it more carefully:
Broadcaster sends only shortText.
VDR reads the Epg event. At EpgBugFix #6 VDR moves shortText to description if description is empty
EPG in this state are saved in epg.data.
After restart VDR reads epg.data. Then scans this event again. Event already have description, so it doesn't make BugFix #6 and now we have shortText and description the same.
Not exacly the same. Becouse "old" descrypion is after BugFix corrections. So there is no BugFix #7 corection. But at the funcion end we have the same texts.
Ah, that's an interesting finding.
So I guess it will make sense to make sure an event that is newly received from the data stream has *all* its data refreshed from the stream. If there is no short text, for instance, an already existing short text needs to be deleted etc.
Thanks for this report, I'll see how it can be fixed.
Can you please try the attached patch? It should fix this problem.
Klaus
Boguslaw Juza wrote:
Hi!I have got big request for Author - It would be nice to make "spaces" in channels list. I want to set "info channels" from 1 to 8, "movie channels" form 10 to 15, sport from 20 etc... So I need to make empty spaces witch ch. numbers 9, 16-19... etc. Switching channels Up/Down should skip spaces.
man 5 vdr:
SYNTAX CHANNELS The file channels.conf contains the channel configuration. Each line defines either a group delimiter or a channel.
A group delimiter is a line starting with a ':' as the very first character, followed by arbitrary text. Example:
:First group
Group delimiters may also be used to specify the number of the next channel. To do this, the character '@' and a number must immediately follow the ':', as in
:@201 First group
The given number must be larger than the number of any previous channel (otherwise it is silently ignored).
A group delimiter can also be used to just set the next channel's number, without an explicit delimiter text, as in
:@201
Such a delimiter will not appear in the Channels menu.
Klaus
Klaus Schmidinger wrote:
Boguslaw Juza wrote:
Hi!I have got big request for Author - It would be nice to make "spaces" in channels list. I want to set "info channels" from 1 to 8, "movie channels" form 10 to 15, sport from 20 etc... So I need to make empty spaces witch ch. numbers 9, 16-19... etc. Switching channels Up/Down should skip spaces.
man 5 vdr:
SYNTAX ...
Ooops... Udo was faster.
Klaus
Hi Boguslaw,
please start a new thread for each topic.
The way you posted, several of your messages ended up in the same thread.
Klaus
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.
Klaus
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
-
Boguslaw Juza -
Klaus Schmidinger -
Udo Richter