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