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