[RFC] Eliminating the 'summary' field of timers

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

 



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.)

First: I was the one suggesting the ID-thing a few years ago for
Master-Timer and i used the ID-field for Master-Timer until the current
version from a month ago. But the problem is that the content of this field
doesn't go into the info.vdr (or summary.vdr before) so i always (had to)
additionally marked the timer in the summary-field to be able to look up
the data Master-Timer stored for a timer, from the info.vdr, when the timer
is long gone.

I realized some month ago that you have a fundamental problem with changing
EPG-data when you mark a timer as "off limits", so i dropped that whole
ID-thing altogether in favour of the ability to propagate changes in
EPG-Data and timer definition to the timer (e.g. changes in time or
title/subtitle/description).

As Master-Timer only changes a timer when there was a change in EPG-Data
(or torecord) in normal circumstances Master-Timer doesn't touch already
programmed timers.


You could store the content of a timer as a whole to see if it is modified.
If you can't find your timer with a list of complete lines then it was
modified or deleted.

This is basically what Master-Timer does when it wants to propagate a
change in EPG-Data or timer definition, it looks up the timer via it's ID
(in the Summary-field) and does a "if ($VDR_Timer ne $my_timer)" and
"MODT"s the timer if it doesn't match.




-- 
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