AW: AW: [vdr] [RFC] Eliminating the 'summary' field of timers
Klaus.Schmidinger at cadsoft.de
Thu Feb 23 09:25:28 CET 2006
Matthias Schniedermeyer wrote:
> ... wrote:
>> vdr-bounces at linuxtv.org wrote:
>>>> Me too, i program all my timers via skript from a website and i use
>>>> the summaries to create the menues (and text) for the DVD-Menues. I
>>>> also add episodenumbers to keep everything in order. So this change
>>>> might have a big impact because i let the timers be programmed and
>>>> change via vdradmin the summaries and titles, so i8'm finished after
>>>> cutting. I don't want to change this. So if this change is what i
>>>> think, than my automatic programming of timers will not work
>>>> correctly and my vdrconvert scripts will create ugly dvds... :(
>>> Well, nobody keeps you from storing anything you like in the 'aux'
>>> field of a timer. You'll find that string again in the resulting
>>> info.vdr file - it will just have a different tag character. The only
>>> change for you will be that VDR doesn't treat this data as a
>>> "description" any more. Regarding your DVD processing script I would
>>> assume that the only change you'd have to make is replacing a 'D'
>>> with an '@' somewhere.
>> Okay, that with the tag is no problem, but editing the summary before the
>> recording e.g. with vdradmin and then don't find this "description" in
>> after the recording , seems strange to me (i see the advantage to have
>> epg-description of the recording, but what happens if you record two
>> in one recording or overlap a quarter hour to be sure to have the end
>> recorded - than you only have the last EPG-description?), why not use
>> one of
>> the remaining color-buttons if you open the info of recording (afaik
>> only red and green in use) ?
> VDRAdmin can (still) change it as VDRAdmin changes via SVDR and only the
> (nowhere seen) NAME of the field is changed.
> The field will still be the last field of a timer-line, so NEWT/MODT will
> work the same as before.
> Regarding your last worry.
> I said to Klaus (before this discussion in a private mail) that he maybe
> should drop the "one timer, one EPG-Event"-paradigma for the info.vdr and
> place all EPG-Events that are (say) at least 90% overlapped with the timer.
> OK. That way it would be easy to catch news or any other "few minutes"
> things, when you use large enough margins, but i guess that would still be
> better than catching the wrong EPG-Event and be scewed. :-)
VDR goes to great lengths to determine which EPG event to assign to
a recording. It takes the one the has the most overlap with the
timer, which appears to work just fine.
More information about the vdr