[vdr] Re: Corruption of channels.conf

[Rainer Zocholl <UseNet-Posting-Nospam-74308-@zocki.toppoint.de>]

h@realh.co.uk(Tony Houghton)  08.02.05 22:13


>In <200502082306.10202.taferner@kde.org>, Stefan Taferner wrote:

>> On Tuesday 08 February 2005 19:01, Tony Houghton wrote:
>>> How can I stop vdr from corrupting channels.conf? I'm using 1.3.19
>>> and every time I run it now it alters channels.conf, eg:
>>>
>>> -BBC ONE:489833:I999B8C34D34M16  T2G32Y0:T:27500:600:601,602:0:0:4163:0:0:0 
>>> +BBC ONE:489833:      C34D34M16B8T2G32Y0:T:27500:600:601,602:0:0:4163:0:0:0
>>>
>>> and next time it starts up it crashes the DVB-T card.
>>>
>>> I've set EPGScanTimeout and UpdateChannels to 0 and even made
>>> /var/lib/vdr/channels.conf read-only and owned by root, but it
>>> still changes it. Would a ridiculously high value for
>>> EPGScanTimeout help?
>>
>> Curing the symptoms only....:
>>
>> You could either try and chmod a-w channels.conf

>I did, and even made it owned by root, but it still changed it. 

If your VDR is running as "root" (as most older installs do)
then that's no problem.
So this might be a good idea to change it now?


Maybe burn(*) all  *.conf onto a CD and then
change the location where VDR reads it's confs from to the CD ;-)
Maybe it will become a little, em, "difficult" to change timers
in future, but OK, there is no free lunch.


Maybe it would be sufficient to link the CD file 
to the original location.
But as VDR does not care about a write protection of that file (why?)
VDR will overwrite the link with his kind of channels.conf. 

>I think it can do that because it renames the original file to
>channels.conf.old and creates a new one. 

That's the usual way that it should be done:
You'll do a "cp -p channels.conf channels.conf.old"
you write to channels.conf.new
and finally "rename channels.conf.new channels.conf".

This ensures that the new file AND the old file will
fit into the filesysetm so teh new file wil not be truncated.

If one is brave, young and unexpierienced he will first
"rename channels.conf channels.conf.old" 
and then directly write a new channels.conf, because 
that's soo fast, and there will never be anyone else accessing that file.
That will work in 999 of 1000 attempts, and the one that 
fails will not be reproducible.. ;-) 


The question is:
What happens channels.conf.old or channels.conf.new already exists 
and is not writable?
Will VDR turn OSD and LIRC processing off to indicate to the user that
he has to remove the write protection? or will VDR simply delete the 
old file, because it hat write permission to the directory? 


>It stopped doing it after I made it a symlink to the 
>real channels.conf in /root, 
>but now I've just realised why it was able to overwrite the old file, 
>I think this new "cure" shouldn't have worked either.


>> Or make a channels.conf.real and cp channels.conf.real
>> channels.conf.real upon vdr start (probably in the runvdr script).

>That's quite a good idea.





(*)
That means: 
Make an ISO-file with "mkisofs" and mount that as read only loop device.
Even root would not be able to change the data... ;-)