[RFC] Eliminating the 'summary' field of timers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Klaus Schmidinger wrote:
> Dirk 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
>> the timers.
>>
>> How can this be achieved in your new concept?
>> (Any positive answer is ok for me - it is no problem to change
>> my script.)
> 
> 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

-- 
Real Programmers consider "what you see is what you get" to be just as
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated,
cryptic, powerful, unforgiving, dangerous.



[Index of Archives]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Big List of Linux Books]     [Fedora Users]     [Fedora Women]     [ALSA Devel]     [Linux USB]

  Powered by Linux