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?
BR and Merry Christmas!
Christian
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
Hi,
Matthias Schniedermeyer wrote:
Does epgsearch save any status from epg-data and/or timers?
yes, but the 'done' approach is currently different: epgsearch marks and saves a broadcast as done only if it has been successfully and completely recorded. So any recording break because of timer conflicts or a crash will be noticed and epgsearch will automatically search for a repeat of the broadcast (provided that proper settings for the search timer exist).
The drawback of this approach is that deleting a timer will lead to the described situation, because it it not yet 'done' in terms of epgsearch. Currently one has to disable the timer to prevent the recording and I would like to solve this in the next release. This could be easily done if VDR could notify plugins about timer deletions.
Christian
Christian Wieninger wrote:
Hi,
Matthias Schniedermeyer wrote:
Does epgsearch save any status from epg-data and/or timers?
yes, but the 'done' approach is currently different: epgsearch marks and saves a broadcast as done only if it has been successfully and
That wasn't what i meant.
Second try with a but more elaborate description (still simplified) After Master-Timer is done with operation it saves the processed "epg.data"(/LSTE) as "program.dat", including markers that a particular broadcast doesn't need to be processed again, unless it was modified (doesn't happen very often on the channels i record). The next time Master-Timer runs it compares the current epg.data with the saved program.dat and only uses the intersection of changed or new broadcasts(and checks for deletions too) to match with the "torecord"-config-file and the resulting matches are put into the "timers.dat". The timers in timers.dat are marked as "already programmed", "new" or "changed". (Actually that's only internal as the different parts of Master-Timer are consecutively "eval"ed from a wrapper script, and only the end-result of everything "already programmed" hits the HDD. (If there was no VDR instance MIA, which is only relevant for installations with 2 or more VDRs (like mine with 3 VDRs), otherwise Master-Timer would exit when the connection to VDR failed))
So Master-Timer always knows what was, what is and what should be. And in default configuration and in normal operation that means that a deleted timers isn't even see as MIA because Master-Timer doesn't process the epg-broadcast a second time and when it want's to propagate a change to a timer, because of changes in the epg-data and/or "torecord"-config-file, it checks if the timer still exists and only applies the change when i still exists. Unless the config-option for checking for MIA timers is set, then all missing timers are reprogrammed.
completely recorded. So any recording break because of timer conflicts or a crash will be noticed and epgsearch will automatically search for a repeat of the broadcast (provided that proper settings for the search timer exist).
The drawback of this approach is that deleting a timer will lead to the described situation, because it it not yet 'done' in terms of epgsearch. Currently one has to disable the timer to prevent the recording and I would like to solve this in the next release. This could be easily done if VDR could notify plugins about timer deletions.
I "solved" this particular problem the other way arround, program everything and when someting gets "done"(*) delete the timers not needed anymore. (As Master-Timer isn't tied into VDR, which means that unless it's a cronjob there is no way of knowing when it will run the next time, that's the only way to be on the safe side.) As i record many things this way i also know when i can delete the "first run"-timer of something to fallback to a rerun when at the time of the first run there is something "in the way".
*: For me that means that i successfully cut the recording. I use my own cutting-solution, in the script that executes the final cutting the summary of the recording is put into the "done"-file of Master-Timer. The next time Master-Timer runs all timers matching a "done"-entry are deleted. (ATM i have 13040 things in my "done"-file. :-) )
Bis denn
Christian Wieninger wrote:
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.
Currently I think there's no way around it. You have to keep some kind of shadow timer list of all timers created by epgsearch. To make re-identification easier its probably a good idea to add some unique ID to the aux field of epgsearch timers that links the VDR timer list with the epgsearch timer list. It may also be enough to just keep all aux fields of timers created by one search timer together with the search timer itself.
By tracking the timer more closely it may also be possible to better track created timers in case the scheduled time moves way off of the original scheduled time. My Harald Schmidt timer sometimes suffers from such re-scheduling, and gets recorded twice.
Cheers,
Udo
-
Christian Wieninger -
Matthias Schniedermeyer -
Udo Richter