Matthias Schniedermeyer wrote: > Klaus Schmidinger wrote: > >> Matthias Schniedermeyer wrote: >> >>> 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 >> >> >> >> You need to actually change the timer in the "Edit timer" menu >> to have these flags reset. >> >> How about we define >> >> tfModified = 0x8000 > > > IOW Bit 31? > > But why don't you use the "next free bit" and change the description to Because it's nothing VDR itself would need, so I thought I'd put it to the far end of the flag word ;-) > "Timer modified via OSD after creation" as any other modification isn't > caught by VDR and can be even reseted externally. Ok. >> 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 >> to tfModified? > > > Speaking for myself (Master-Timer) i can say i can live with a flag. > As i can freely ignore it. :-) > > As long as you don't wreak havoc with the AUX-field i'm happy. :-) > > > In the end that wholeexercise is a bit pointless because you can still > modify a timer via SVDR(*) without setting the flag as you always modify > the whole timer entry and not singular componets of a timer. > > > > *: > IOW if you use VDRAdmin, XXV etc to modify timers you have already lost. > So i'd say there's a not so small percentage of cases where this whole > schema simply won't work. If a user mixes different types of timer creation/handling, all kinds of things can happen. The applications would have to agree on certain rules to avoid that, but that's something the authors of those apps would have to discuss. Klaus
