[vdr] [RFC] Eliminating the 'summary' field of timers (update)
Klaus.Schmidinger at cadsoft.de
Wed Feb 22 10:36:53 CET 2006
Matthias Schniedermeyer wrote:
> Klaus Schmidinger wrote:
>>Klaus Schmidinger wrote:
>>>Here's an updated version of the draft for eliminating the
>>>'summary' field of timers:
>>>- The new flag tfModified = 0x8000 will be _set_ whenever the
>>> user modifies a timer via the "Edit timer" menu after the
>>> timer has been created.
>>After more consideration I don't like this any more.
>>This flag would typically be set on a normal (i.e. plain
>>vanilla) VDR (where users manage their timers through the
>>"Edit timer" menu), making the flag numbers unnecessary
>>large. Since I originally wanted to keep all auxiliary
>>information confined to the 'aux' field (and the fact that
>>a timer has been modified can only be of interest to external
>>apps that use the 'aux' field), and just clearing the 'aux'
>>field in such a case was objected to by Matthias, I tend
>>to define that if the first character of the 'aux' field
>>is a '?' (question mark), that character will be set to
>>'!' (exclamation mark) if the timer was modified.
>>As a mnemonic: "?..." asks whether the timer was modified,
>>and "!..." means "Yes! The timer was modified".
>>Of course we can use a different pair of characters if
>>somebody comes up with a suggestion.
> I'm for dropping this topic altogether as there is NO way that anyone,
> except the original program, can mark or tell if a timer is modified or not
> with a resonable enough reliability.
> Every schema we draw up won't work for more than a subset of the cases, so
> every programm still has to draw up a solution for the rest of the cases.
> Which makes it a pointless affort as you practically always end up having
> to remember what you programmed and comparing that to what is programmed
> now, to be sure there was a modification or not.
> I say that is nothing Klaus should be concerend about as there is not much
> VDR can do, as said all schema can't catch all modifications.
> VDR can catch:
> - Modification via OSD
> VDR can not catch:
> - Modification via SVDR (telnet or modt.pl)
> - Modification via VDRAdmin, XXV ... (technically this is also SVDR)
> - MOdification of timers.conf when VDR is not running
> - Anything i forgot. :-)
Well, if we can drop that altogether, I'm all for that!
More information about the vdr