[vdr] Re: migration to 1.2.2

[Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de>]

Rainer Zocholl wrote:
> 
> Klaus.Schmidinger@cadsoft.de(Klaus Schmidinger)  10.08.03 11:56
> 
> Once upon a time Klaus Schmidinger shaped the electrons to say...
> 
> >Rainer Zocholl wrote:
> >>
> >> Klaus.Schmidinger@cadsoft.de(Klaus Schmidinger)  09.08.03 22:44
> >>
> >> Once upon a time Klaus Schmidinger shaped the electrons to say...
> >>
> >>>I believe I wrote a lot about all this in the file UPDATE-1.2.0:
> >>
> >> at lot of stuff to read!
> 
> >Well, if nobody is going to read this, maybe I can save the time
> >and effort and in the future just not write any more documentation ;-)
> 
> Yes, it's always the same problem ;-)
> Thanks a lot for doing documentation
> despite of knowing that it is read only "after"!
> (Do believe people how claims to have the entire documention
> read first. ;-) That's today completely unrealistic.)
> 
> The best way to get users reading is currently the "FAQ".
> They see: OK, maybe i need only to read 3 lines to solve
> my problem. (And, with a good FAQ, they read at least
> all questions!).

Well, frankly I really don't care whether somebody does or does not
read the docs. I write them so that users have a chance to find out
what has changed, how to set up things correctly and so on. It's
their choice whether to read or not... However, I do get annoyed
when people keep asking things that they could have easily found in
the docs.

> >>>  In order for the "unique channel ID" to work, all channel
> >>>definitions now must  be unique with respect to the combination of
> >>>their Source, Frequency and SID   parameters.
> >>
> >> There is no "name" mentioned...
> 
> >Of course there isn't! Names are not unique.
> 
> I read "Source, Frequency and SID" ;-)

So?

> >> And:
> >> What's the problem if not?
> 
> >Timers identify channels by their unique channel id.
> 
> Ok, good idea!
> 
> >If these ids are not unique, a timer wouldn't know
> >which channel to use
> 
> Why?
> The channel ID is "Uniq", specifies exactly one channel.
> If that channel is listed ten times in channels.conf:
> It's still the one and same channel, or?

So then why is it listed ten times??
Just throw out the superfluous 9 entries and be happy!

> There is no timer.conf anymore which stores indicies.
> 
> >- it can't know whether this was done on purpose or just by accident.
> 
> It can issue a warning to avoid complaints like
> "VDR is recording ARD, when it should record ZDF"
> But that actuallly would give no problem!
> If user realises that an other channel (as he wanted) was recorded
> then the channel parameter were really different, so the
> UID was different too no warning was issued.

Let me give you an example, mabe this makes it clear:
Assume you have a channels.conf in which you have two channels that
have exactly the same parameters, except for the channel name (maybe
because they share a channel, one transmittin over the day, the other
at night). Let's call them A and B. Now assume you define a timer on
channel A. If channels.conf were allowed to have non-unique entries,
the timer would still use the correct channel for recording, since
A nd B have the same parameters.

Now assume that one fine day the broadcaster of channel A decides to
switch to a different transponder. You make the according change in
channels.conf, but for some reason forget to also change timers.conf
accordingly. Since at the next start of VDR the timer entry will still
find a channel with the given parameters (channel B), it will happily
record from channel B, which originally it was intended to record from 
channel A. Now wouldn't that be something to complain about?

Believe me, it's better to keep all channel entries unique.

> >> The i have one source with two names.
> >> But it's stil the same channel an satelite
> >>
> >> What does it matter if i have
> >> a
> >> Neun Live:12480:v:S19.2E:27500:767:768:35:0:897:0:0:0
> >> and a
> >> tm3:12480:v:S19.2E:27500:767:768:35:0:897:0:0:0
> >> in my channels conf?
> 
> >Simple: it doesn't work!
> 
> So why VDR is starting with a broken channel.conf?

Ok, ok, I'll make it so that it dies in that case.

> But pardon me, i still don't understand why
> channel.conf may not list(!) the same channel twice.

See above.

> The only problem i see may be, if one name occurs twice
> with different UID.

You can give all channels the same name, if you wish.
The channel name has absolutely no meaning to VDR.

> Maybe i miss one "bit" in the philosophy of channels.conf?

See above.

> >Channel data has to be unique.
> 
> >You can use the RID field to make them unique.
> 
> Why should i want to? :-)

To have two channels with the "same" parameters?!

> Neun Live:12480:v:S19.2E:27500:767:768:35:0:897:0:0:0
> and
> tm3:12480:v:S19.2E:27500:767:768:35:0:897:0:0:0
> 
> *is* the same channel.  It changed only it's name.
> The entry is redundant, but what would be broken?

The channel name has absolutely no meaning to VDR.

> >> You know that the second and thir line belongs together.
> >> First I thought that this were 2 different errors:
> >>> vdr[3348]: loading /video/channels.conf
> >>> vdr[3348]: ERROR: channel data not unique!
> >>> vdr[3348]: ERROR: error in /video/channels.conf, line 133
> >>
> >> maybe something like:
> >>> vdr[3348]: loading /video/channels.conf
> >>> vdr[3348]: ERROR(32): in /video/channels.conf, line 133 (32:channel
> >>> data notunique!)
> >>
> >> is more "human".
> 
> >Just because it is in one line instead of two?
> 
> Yes.
> Inagine that there might run other processes inserting
> thier lines between.
> 
> >> And:
> >> If VDR would have not loaded at all (because it actualy can't work
> >> in this state) it would be more likely that the first view is going
> >> into the logfile.
> >> (I looked first im /var/log/messages: there was no error
> >> listed!)
> 
> >If there was no error listed, then everything must have been fine!
> 
> Yes. That was my thought too. ;-)
> 
> >Are you sure it didn't say
> 
> >vdr[3348]: loading /video/channels.conf
> >vdr[3348]: ERROR: channel data not unique!
> >vdr[3348]: ERROR: error in /video/channels.conf, line 133
> 
> >in there?
> 
> That was found in in /var/log/syslog, not in var/log/messages.
> Don't know why. Diffent loglevels?

Well, if you strip your log messages apart into separate files,
that's your problem. VDR assumes that all it's log messages go
into the same log file.

> >Ok, we can let VDR die if it fails to read that file.
> 
> I think that's a good idea because it can't work at all
> without that file.
> There are more reasons for problems with teh file, not
> only the stupid user ;-)

You know, come to think of it, you're the first one (as far as I
know) who has such massive problems with this... ;-)

Klaus


-- 
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe vdr" as subject.