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
""(/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 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
(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.

vdr mailing list

Reply via email to