Hi Klaus & list,
Today I had an unexpected parse error in my channels.conf, in this line:
Test Feed;Test Feed:10920:hC56M2O0S0:S19.2E:22000:0:0:0:0:0:1:1063:0
The line was added by automatic transponder scan yesterday. The 'bug' of this channel is that the SID (4'th last) is 0, triggering tChannelID::Valid() to be false.
By now, the channel is announced correctly like this:
Test Feed;Test Feed:10920:hC56M2O0S0:S19.2E:22000:601:0:0:D02,1815:20351:1:1063:0
The core problem however is that the channel was added without completely checking validity first. Adding a check for Valid() to cChannels::NewChannel() probably solves this issue. (not tested)
Until this is fixed, its probably a good idea to disable channel updates for VDR systems that run mostly un-monitored. (Holiday season is near!)
Cheers,
Udo
Hi
Hanno Zulla schrieb:
You are wrong. I am not talking about *updating channels*. I know about that and as a workaround, I switched it off. BUT: This is NOT what I am looking for.
I want to disable the check, for invalid channels in channels.conf
I just don't care, if a channel is not "tuneable". I won't switch to that channel anyway...
Am Mittwoch 18 Juni 2008 schrieb Frank Scherthan:
in config.h, in the function "bool Load()" at about line 123 (vdr 1.4.7) uncomment 2 lines: else { esyslog("ERROR: error in %s, line %d", fileName, line); delete l; //RC: we do not want to exit vdr just because of a simple error //result = false; //break; } } } this will cause vdr to go on starting even if an error accours in a config file and increase waf. ;)
cheers, Tim
Tim schrieb:
It happens again today. So I made a quick fix.
Are you sure that your fix will increase the WAF ? I don't know if VDR works correctly with a "broken" channels list.
I prefer not to add broken channels. The patch does not help for channels that modify pids to a broken state, but prevents to add broken channels.
--- channels.c.org 2008-04-12 15:49:12.000000000 +0200 +++ channels.c 2008-06-18 12:20:17.000000000 +0200 @@ -1151,6 +1151,11 @@ NewChannel->CopyTransponderData(Transponder); NewChannel->SetId(Nid, Tid, Sid, Rid); NewChannel->SetName(Name, ShortName, Provider); + if(! NewChannel->GetChannelID().Valid()) { + esyslog("ERROR: new channel data results in invalid ID!"); + free(NewChannel); + return(NULL); + } Add(NewChannel); ReNumber(); return NewChannel;
Am Mittwoch 18 Juni 2008 schrieb Peter Evertz:
It is not broken, as the questionable entry is deleted again (delete l;) when parsing it. So happens for all configuration files. You can do a 'cat /dev/random > /etc/vdr/channels.conf' and the vdr still comes up. This way it is prevented that the vdr hangs inside a boot-loop.
cu, tim
On 06/18/08 15:12, Tim wrote:
Since this kind of complaints keeps occuring ever again, I guess it's best to simply report errors when reading config files (as suggested by Tim)
--- config.h 2008/04/19 09:19:22 2.2 +++ config.h 2008/09/06 14:06:56 @@ -122,7 +122,6 @@ esyslog("ERROR: error in %s, line %d", fileName, line); delete l; result = false; - break; } } }
and ignore the result values in vdr.c:
--- vdr.c 2008/09/06 11:24:21 2.2 +++ vdr.c 2008/09/06 14:08:44 @@ -559,17 +559,15 @@ cThemes::SetThemesDirectory(AddDirectory(ConfigDirectory, "themes"));
Setup.Load(AddDirectory(ConfigDirectory, "setup.conf")); - if (!(Sources.Load(AddDirectory(ConfigDirectory, "sources.conf"), true, true) && - Diseqcs.Load(AddDirectory(ConfigDirectory, "diseqc.conf"), true, Setup.DiSEqC) && - Channels.Load(AddDirectory(ConfigDirectory, "channels.conf"), false, true) && - Timers.Load(AddDirectory(ConfigDirectory, "timers.conf")) && - Commands.Load(AddDirectory(ConfigDirectory, "commands.conf"), true) && - RecordingCommands.Load(AddDirectory(ConfigDirectory, "reccmds.conf"), true) && - SVDRPhosts.Load(AddDirectory(ConfigDirectory, "svdrphosts.conf"), true) && - Keys.Load(AddDirectory(ConfigDirectory, "remote.conf")) && - KeyMacros.Load(AddDirectory(ConfigDirectory, "keymacros.conf"), true) - )) - EXIT(2); + Sources.Load(AddDirectory(ConfigDirectory, "sources.conf"), true, true); + Diseqcs.Load(AddDirectory(ConfigDirectory, "diseqc.conf"), true, Setup.DiSEqC); + Channels.Load(AddDirectory(ConfigDirectory, "channels.conf"), false, true); + Timers.Load(AddDirectory(ConfigDirectory, "timers.conf")); + Commands.Load(AddDirectory(ConfigDirectory, "commands.conf"), true); + RecordingCommands.Load(AddDirectory(ConfigDirectory, "reccmds.conf"), true); + SVDRPhosts.Load(AddDirectory(ConfigDirectory, "svdrphosts.conf"), true); + Keys.Load(AddDirectory(ConfigDirectory, "remote.conf")); + KeyMacros.Load(AddDirectory(ConfigDirectory, "keymacros.conf"), true);
if (!*cFont::GetFontFileName(Setup.FontOsd)) { const char *msg = "no fonts available - OSD will not show any text!";
Of course Tim's change would have had the same result, but it also would have made it completely impossible for the caller of cConfig::Load() to determine if the call was successful.
Well, whether this actually increases the WAF remains to be seen. Starting VDR with inconsistent config files may have all kinds of effects...
Klaus
On Saturday 06 September 2008, Klaus Schmidinger wrote:
Since this kind of complaints keeps occuring ever again, I guess it's best to simply report errors when reading config files (as suggested by Tim)
[...]
Somewhat related - I'm wondering why comments are not allowed in channels.conf, remote.conf, setup.conf and timers.conf?
Or actually more generally why an option for disallowing comments in some *.conf files exists in the first place :)
On 09/06/08 18:38, Ville Skyttä wrote:
Some files are "human written" and will not be overwritten by VDR. In those files comments make sense.
Other files are automatically written by VDR, so comments don't make much sense there.
But I have no problem with allowing comments in all files and just dropping them when automatically writing back those files. Is this something you'd like to have?
Klaus
On Saturday 06 September 2008, Klaus Schmidinger wrote:
Yes, I think that's fine. It'd allow distro packagers to ship those files with some meaningful comments in them out of the box instead of just empty files. Especially channels.conf which (as far as I'm up to date with VDR's current behavior) still needs to be initially generated with external tools.
Hi,
anyone know how to kontakt the xineliboutput developer ? The latest cvs is, at least for me, completely broken for watching HDTV. I get only audio. Video Stays black. Using some cvs revisons back works fine. I use VDR 1.7.0 + Reinahrds patch.
cu
gimli
you can contact to Petri Hintukainen , on http://phivdr.dyndns.org/vdr/vdr-xineliboutput/ you can find his email. Yes, on http://sourceforge.net/mailarchive/forum.php?forum_name=xineliboutput-cvslog there's many xineliboutpt-cvs updates in these days.
Goga
On Wed, Jun 18, 2008 at 8:12 PM, Goga777 goga777@bk.ru wrote:
today I updated cvs xineliboutput and I could run vdr 170 + xineliboutput on dvb-s2 hdtv channels without any problems
Was that using CoreAVC, or just FFMPEG's H264 support?
today I updated cvs xineliboutput and I could run vdr 170 + xineliboutput on dvb-s2 hdtv channels without any problems
Was that using CoreAVC, or just FFMPEG's H264 support?
i have mean xineliboutput with ffmpeg , I couldn't run vdr-xine + coreavc for linux 170 + dshowserver
Goga
Hi guys,
Could someone tell me what kind of DVB-S2 card i should use for CANALSAT (Astra 19.2) HDTV ?
Tnx
Regards
Pierre
Hi guys, Could someone tell me what kind of DVB-S2 card i should use for CANALSAT
(Astra 19.2) HDTV ?
Tnx
Hello, Be carefull ! New CANAL cards will shortly not working on other demodulator than the official one. CANAL is doing that because they don't want that the susbscribers record any HD program.
Bye.
Ok thnx for info.
-----Message d'origine----- De : vdr-bounces@linuxtv.org [mailto:vdr-bounces@linuxtv.org] De la part de kafifi Envoyé : jeudi 26 juin 2008 21:58 À : 'VDR Mailing List' Objet : [vdr] HDTV France canalsat : which card ?
(Astra 19.2) HDTV ?
Tnx
Hello, Be carefull ! New CANAL cards will shortly not working on other demodulator than the official one. CANAL is doing that because they don't want that the susbscribers record any HD program.
Bye.
_______________________________________________ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ---------------------------------------------------------------------------- ----------- Orange vous informe que cet e-mail a ete controle par l'anti-virus mail. Aucun virus connu a ce jour par nos services n'a ete detecte.
-
Frank Scherthan -
gimli -
Goga777 -
Hanno Zulla -
kafifi -
Klaus Schmidinger -
Morfsta -
Peter Evertz -
Pierre-Yves Paranthoen (PERSO) -
Tim -
Udo Richter -
Ville Skyttä