[vdr] [RFC] Eliminating the 'summary' field of timers
Klaus.Schmidinger at cadsoft.de
Tue Feb 21 17:28:51 CET 2006
Matthias Schniedermeyer wrote:
> Klaus Schmidinger wrote:
>>>Klaus Schmidinger wrote:
>>>>- The upper 16 bit of the timer's 'flag' field are no longer
>>>> given any special treatment, and also shouldn't be used.
>>>> Only the flags defined in vdr.5 shall be used.
>>>I am using a script I wrote to add and manage my timers automatically.
>>>The script is using these upper 16 bits to identify which
>>>timers have been added by the script and which have been
>>>added or changed manually. This is done by setting an id
>>>(magic number) in these upper 16 bits. Later, only timers
>>>which have this id are touched (modified) by the script.
>>>The thing I like is the fact that (from vdr.5) "When a user
>>>modifies an active timer, the upper 16 bits of this
>>>unsigned 32 bit parameter will be explicitly set to 0."
>>>Because of this, my script doesn't overwrite manual changes of
>>>How can this be achieved in your new concept?
>>>(Any positive answer is ok for me - it is no problem to change
>>I guess the logical thing to do then would be to
>>clear the "aux" field in that case.
> I'm definitly against that.
> That would COMPLETLY destroy Master-Timer funktionality!
> Not only that it couldn't find it's timers anymore, to propagate
> EPG-Changes for e.g.
> The timers would look like complete "User defined timers" which
> Master-Timer completely ignores (Not only "User changed" like before!)
> For e.g. for the "done" functionality it searches the info.vdr for it's
> signature which would have been totally destroyed.
> And addionally Master-Timer can't rely on VDR putting the right(tm)
> EPG-Data into the info.vdr (Without strong binding between timers and EPG
> it's only 99% "safe" or IOW unusable), so i still have to put all the data
> Master-Timer needs into the "AUX"-Field.
> So i'm definitly against VDR doing anything more than storing the AUX field.
> As i said in the other mail, with a little more added logic a script can
> find out itself if a timers was modified.
> You only loose the ability to just to mark the timer as "modified" via
> "show and store" the timer in OSD(*?) as that wouldn't change the timer.
> But if you change the Prio or lifetime by 1 the timer would clearly not be
> in "original" state.
> I myself change the start & end times frequently (via SVDR so this all
> doesn't apply to me in the first place) and i didn't want to loose the
> binding just because i had to change the margins to solve conflicts between
> different timers.
> Was is sufficient to just show and store the timer to clear the flag?
> If not, then you are in the same situation as before: you have to "really"
> change something before VDR clears the flag
You need to actually change the timer in the "Edit timer" menu
to have these flags reset.
How about we define
tfModified = 0x8000
which will be _set_ whenever the user modifies a timer. That way an external
program can detect that the user has made a modification, and the "aux" field
can be left untouched.
Currently the upper 16 bit are only reset if the user presses Ok
in the "Edit timer" menu (after a change). If he presses Blue in the
"Timers" menu (to (temporarily) disable a timer) these flags are
_not_ reset. Should this behavior remain the same when (if) switching
More information about the vdr