Christian Wieninger wrote:
perhaps this is too trivial, but why not create a daily or whatever timer as you suggested before with a special name like '@epgscan' and react on that?
This would be a dirty ugly hack. There must be some pseudo-recording running so VDR does not restart the recording over and over again. And then we'll end up with a recording hack that looks like a timer but does not block devices and does not write to disk and has no recording folder and and and...
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. 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.
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 for realy using a KISS principle.
The only benefit of scripting is that more people tend to write and change scripts that writing plugin or extend VDR code. The second is 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. Of couse Klaus should be one deciding the way to implement it but he should be more open here to stimulate more people to contribute to VDR. It's like Linux and Linus, the first is a scaling system the second not. Same for VDR and Klaus ;-) 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.
kind regards Peter
I'm kind of surprised people even bother to shutdown vdr at all. Didn't really how big of an issue this was until reading this thread. That's all I have to offer the discussion at this point. My apologies. :)
peter.dittmann@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.
Cheers,
Udo
Udo Richter wrote:
peter.dittmann@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.
I do.
However, (don't know exactly if this has already been suggested as such) maybe a simple feature in the new shutdown code could be to allow the user to specify *one* time at which VDR shall be guaranteed to be "up", along with a time period for which it shall stay up. That way external tools could be scheduled using "cron", and they could rely on VDR being up at that time.
But that's about as far as I'd go.
Klaus
Klaus Schmidinger wrote:
However, (don't know exactly if this has already been suggested as such) maybe a simple feature in the new shutdown code could be to allow the user to specify *one* time at which VDR shall be guaranteed to be "up", along with a time period for which it shall stay up. That way external tools could be scheduled using "cron", and they could rely on VDR being up at that time.
The downside of this would be that again several external tasks would fight for one resource: the time set in VDR. And it wouldn't be much different from the current possible solution to compare the VDR wakeup time with other wakeup times in the shutdown script.
For the 0.2 patch, I've added the interface for plugins to modify the wakeup time. That way it shouldn't be too difficult to implement a task scheduler plugin that can be extended to everyone's need, and to implement basic scheduling in existing plugins. (epgsearch for example could implement a wakeup-at-night feature quite easily.)
Cheers,
Udo
Udo Richter wrote:
Klaus Schmidinger wrote:
However, (don't know exactly if this has already been suggested as such) maybe a simple feature in the new shutdown code could be to allow the user to specify *one* time at which VDR shall be guaranteed to be "up", along with a time period for which it shall stay up. That way external tools could be scheduled using "cron", and they could rely on VDR being up at that time.
The downside of this would be that again several external tasks would fight for one resource: the time set in VDR.
I don't see why "several external tasks would fight for" that time. This is something the user would set up the way he wants it. If he wants one or more external tools to have access to VDR at, say, 04:00 in the morning, then he could configure VDR so that it is up at that time. Of course he would also have to make sure that the external tools would use that time slot accordingly.
What would be a scenario where external tools would "fight" for this time?
Klaus
Klaus Schmidinger wrote:
Udo Richter wrote:
The downside of this would be that again several external tasks would fight for one resource: the time set in VDR.
I don't see why "several external tasks would fight for" that time. This is something the user would set up the way he wants it. If he wants one or more external tools to have access to VDR at, say, 04:00 in the morning, then he could configure VDR so that it is up at that time.
I'm not sure whether all external tools will agree on one time, or whether several tools all want to set 'their' time. Anyway, with the plugin interface, this could be done as a very simple sample plugin.
Cheers,
Udo
-
Klaus Schmidinger -
peter.dittmann＠freenet.de -
Udo Richter -
VDR User