[vdr] How to detect if a timer was deleted?

Matthias Schniedermeyer ms at citd.de
Sat Dec 23 11:43:19 CET 2006


Christian Wieninger wrote:
> Hi,
> 
> for a new feature of epgsearch, I'd like to do a continuous check (in a
> separate thread) if any timer was deleted via OSD or SVDRP since the
> last check.
> 
> The only thing I found so far is to build a timer array and compare it
> at each check with the current timer list. But if timers where modified
> meanwhile, the check can get quite complex.
> 
> Any other idea?
> 
> @Klaus: Is there a chance for a patch that extends cStatus with e.g.
> MsgDelTimer to get part of VDR, if I supply one ;-)
> 
> Background: epgsearch currently creates a timer again if it was found by
> any search timer, even if the user previously deleted it. If I could
> detect which timer was deleted, I could put it in a done list to prevent
> the new creation.
> I know, I could create the done list already when creating the timer for
> the first time, but this causes other problems. Besides that: only
> timers that have been deleted are of interest, so why save all others too?

Does epgsearch save any status from epg-data and/or timers?

This point (don't recreate deleted timers, unless wanted) was an design
criterion for Master-Timer from the beginning, so what i did in
Master-Timer is(*):
a) Mark the epg-data events that are already processed.
b) Save the timers-list

So in normal operation the marks from a) already prevent any unnecessary
processing and when the configuration was changed only intersection of
new timers are programmed(, or deleted or modified).

As i don't know for what user-type epgsearch is, i can't say if you
should go to the length of creating a proper state to operate on, or if
more or less stateless is "good enough".



*: oversimplified!




Bis denn

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




More information about the vdr mailing list