[vdr] NEWT checks for similiar timers, MODT does not
Klaus.Schmidinger at tvdr.de
Sat Dec 15 12:10:16 CET 2012
On 14.12.2012 16:27, Malte Forkel wrote:
> Am 14.12.2012 10:23, schrieb Klaus Schmidinger:
>> On 13.12.2012 23:19, Malte Forkel wrote:
>>> I noticed the following when using SVDRP: With the command NEWT, you
>>> can't create a timer if there already exists a timer for the same
>>> channel, day, start time and stop time. But you can create some dummy
>>> timer and then use the MODT command to make it identical to the existing
>>> timer. Here is a sample session:
>>> Looking at svdrp.c and timers.c, cSVDRP::CmdNEWT will use
>>> cTimers::GetTimer to look for an existing timer, cSVDRP::CmdMODT does
>>> not seem to perform a check.
>>> I'm not sure about the rationale. What would I break if I dropped the
>>> test in cSVDRP::CmdNEWT? Are there better workarounds than creating a
>>> dummy timer?
>> NEWT performs a simple test to prevent the user from inadvertently
>> creating duplicate timers. With MODT things are somewhat more complex,
>> because the timer is already in the list, so it would have to check
>> whether there is an *other* timer with the same settings. Sure, this
>> could also be done, but then again just let's keep things simple...
> Oh, I would like to argue for dropping the test in NEWT! I think that
> might make things even more simple (at least for me :-)) and more
> consistent. After all, there is nothing that keeps me from creating
> duplicate timers with any of the other interfaces I use. And if an
> application wanted to make sure it does not create duplicate timers,
> comparing the new definition to the output of LSTT would be rather easy
> to implement. Plus, VDR itself does not seem to have any problems with
> duplicate timers.
> On the other hand, if there is a test in NEWT, I think it should check
> other attributes as well, e.g. active vs inactive and recording path.
> My use case is this: I'm writing a script that changes the names ofsome
> timers created by EPGSearch. Because EPGSearch will revert any changes
> to these timers, the script disables the original timer and then creates
> a new one with a different name. The latter part requires some trickery
> at the moment, because NEWT rejects the new timer even though it is
> different from the original onein the two attributes mentioned.
Well, if nobody objects I have no problem with removing that check
More information about the vdr