[vdr] [RFC] Shutdown rewrite for 1.5.x

Udo Richter udo_richter at gmx.de
Tue Jan 2 21:54:21 CET 2007

peter.dittmann at freenet.de wrote:
>> The alternative would be to implement a generic task scheduler and make 
>> timers one special type of schedule. This would get REALLY big.
> Yes, but it will be the much better design.
> It will open the option to do VDR related timed and maintainance tasks.

There must be some limit. IMHO VDR is a video recorder, not a task 
scheduler. And I think that Klaus probably agrees with that.

> Don't reply this should be external scripts, as there is no way
> external scripts know what state VDR currently has without a lot more
> complexity.

What additional internal state info do you need? Providing interfaces to 
cooperate with external schedulers should be no problem.

> These are EPG scans (internal, infosatepg, nextview), sleeptimers,
> switchonly timers, cleanup tasks of plugins and so on. Think about
> external EPGs, especilly the ones that need VDR to tune to a channel,
> like infosatepg or nextview. This is painfull hack doing his outside
> VDR as these tasks mutually collide with VDRs internal activities and
> need to be integrated

Do you suggest to put all these EPG collectors as integral schedule 
events into core VDR???

At most, such things may be done as plugin. And for plugins, the ability 
to wake up at a non-timer time was already suggested.

> for realy using a KISS principle.

In my eyes, KISS also applies to VDR itself. Meaning, why add a 
full-featured scheduler to VDR that VDR doesn't need?

> also cause by Klaus's reluctance to take over patches. Where there
> are patches there is need to change some VDR behaviour, so this
> behaviour should be changed.

In limits, yes. But Klaus being very conservative on integrating patches 
and features is one of the reasons why VDR is still a very stable and 
easy to use program. What sounds like a nice enhancement now may soon 
turn into a dead end, a burden kept for compatibility. There are lots of 
programs that are overloaded with features that no one really knows, 
with an user interface to get lost in it.

> The idea to create now a "external" Shutdown class by a second person
> seems like a good starter. It should be done for other
> functionalities too.

This is not the first bigger chunk of work contributed by others, and 
definitely not the first smaller feature that was contributed. Its also 
a matter of engagement: If you start off with "I'll do it as independent 
patch, Klaus wont add it anyway", then you'll get what you want.

The reason I am working on this is that AFAIK Klaus doesn't use the 
shutdown mechanisms, and the code really needed an overhaul by someone 
who's interested in it.



More information about the vdr mailing list