Hi,
I have been running VDR as a daemon started via init script for some years now. I am currently using version 1.6.0-2. The problem is, that every now and then VDR doesn't start when I boot the server. The culprit seems to be lcdproc plugins, which for some reason cannot always connect to the LCDd daemon. In VDR's log it shows up like this:
OK:
Sep 18 16:31:49 vdrkone2 vdr: [4890] starting plugin: lcdproc Sep 18 16:31:49 vdrkone2 vdr: connection to LCDd at localhost:13666 established. Sep 18 16:31:49 vdrkone2 vdr: LCD output thread started (pid=4890), display size: 2x16
NOT OK:
Sep 18 19:05:45 vdrkone2 vdr: [4876] starting plugin: lcdproc Sep 18 19:05:45 vdrkone2 vdr: [4876] stopping plugin: femon Sep 18 19:05:45 vdrkone2 vdr: [4876] stopping plugin: burn
Now, the question is, does this really cause VDR to shut down? And if so, should VDR behave in some other way in such a case? Or is it just lcdproc plugin that causes such a behaviour? Is it possible for VDR to retry starting plugin which failed to start?
-Petri
Petri Helin ha scritto:
Hi,
I have been running VDR as a daemon started via init script for some years now. I am currently using version 1.6.0-2. The problem is, that every now and then VDR doesn't start when I boot the server. The culprit seems to be lcdproc plugins, which for some reason cannot always connect to the LCDd daemon. In VDR's log it shows up like this:
OK:
Sep 18 16:31:49 vdrkone2 vdr: [4890] starting plugin: lcdproc Sep 18 16:31:49 vdrkone2 vdr: connection to LCDd at localhost:13666 established. Sep 18 16:31:49 vdrkone2 vdr: LCD output thread started (pid=4890), display size: 2x16
NOT OK:
Sep 18 19:05:45 vdrkone2 vdr: [4876] starting plugin: lcdproc Sep 18 19:05:45 vdrkone2 vdr: [4876] stopping plugin: femon Sep 18 19:05:45 vdrkone2 vdr: [4876] stopping plugin: burn
Now, the question is, does this really cause VDR to shut down? And if so, should VDR behave in some other way in such a case? Or is it just lcdproc plugin that causes such a behaviour? Is it possible for VDR to retry starting plugin which failed to start?
-Petri
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Hi, what i now there is a patch inside Extension Patch that allow VDR to start even if a plugin fails. I don't remember which it's, just check inside the package.
Diego Pierotto
Diego Pierotto wrote:
Petri Helin ha scritto:
Hi,
I have been running VDR as a daemon started via init script for some years now. I am currently using version 1.6.0-2. The problem is, that every now and then VDR doesn't start when I boot the server. The culprit seems to be lcdproc plugins, which for some reason cannot always connect to the LCDd daemon. In VDR's log it shows up like this:
OK:
Sep 18 16:31:49 vdrkone2 vdr: [4890] starting plugin: lcdproc Sep 18 16:31:49 vdrkone2 vdr: connection to LCDd at localhost:13666 established. Sep 18 16:31:49 vdrkone2 vdr: LCD output thread started (pid=4890), display size: 2x16
NOT OK:
Sep 18 19:05:45 vdrkone2 vdr: [4876] starting plugin: lcdproc Sep 18 19:05:45 vdrkone2 vdr: [4876] stopping plugin: femon Sep 18 19:05:45 vdrkone2 vdr: [4876] stopping plugin: burn
Now, the question is, does this really cause VDR to shut down? And if so, should VDR behave in some other way in such a case? Or is it just lcdproc plugin that causes such a behaviour? Is it possible for VDR to retry starting plugin which failed to start?
-Petri
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Hi, what i now there is a patch inside Extension Patch that allow VDR to start even if a plugin fails. I don't remember which it's, just check inside the package.
Diego Pierotto
I may have been a bit vague and unclear in what I wrote earlier. I did check the source code and noticed that if a plugin fails to start it really causes VDR to not start also. My aim really was to start some discussion on whether that should be changed. I myself think that VDR should start although some plugin fails to start. I'd hate to find out that some timed recording failed because the lcd display of the PC case malfunctioned.
-Petri
Petri Helin wrote:
really causes VDR to not start also. My aim really was to start some discussion on whether that should be changed. I myself think that VDR should start although some plugin fails to start. I'd hate to find out that some timed recording failed because the lcd display of the PC case malfunctioned.
Why not design plugins that start even if some non-fatal error happens? To me it sounds natural that if some non-recoverable error happens, the whole program stops.
yours, Jouni
Jouni Karvo wrote:
Petri Helin wrote:
really causes VDR to not start also. My aim really was to start some discussion on whether that should be changed. I myself think that VDR should start although some plugin fails to start. I'd hate to find out that some timed recording failed because the lcd display of the PC case malfunctioned.
Why not design plugins that start even if some non-fatal error happens? To me it sounds natural that if some non-recoverable error happens, the whole program stops.
I regularly use the a constant set of following set of plugins: burn, extrecmenu, epgsearch, femon, lcdproc, live, osdteletext, skinsoppalusikka, streamdev and xineliboutput. I cannot come up with any reason for any plugin besides xineliboutput being critical for my normal use. And VDR can run by itself quite well even without xineliboutput. So there really is no reason for VDR not to start if any of those plugins above fail to start. In fact I am already wondering why plugins are not hot-pluggable...
-Petri
I like that VDR won't load if a plugin failed. That means there was a problem, and I should go fix it. Also, it's the plugins job to continue on non-fatal errors, not VDR. How would VDR even know whats a non-fatal error for a certain plugin? From VDR's perspective either the plugin is working or it's not.
VDR User wrote:
I like that VDR won't load if a plugin failed. That means there was a problem, and I should go fix it. Also, it's the plugins job to continue on non-fatal errors, not VDR. How would VDR even know whats a non-fatal error for a certain plugin? From VDR's perspective either the plugin is working or it's not.
But why should even a fatal error (from plugin's perspective) cause VDR to not start? It should only cause the plugin not to be loaded. Of course plugins could also implement more intelligent initialization and try to deal with possible errors, but isn't it easier to just handle it in one place - at the VDR?
If I think of the core VDR, I see its main function as recording TV-programmes. From that perspective it's not that big of a problem if it doesn't start properly due to a plugin not bevahing properly if I am sitting next to the PC and can fix or circumvent the problem. But since it will mostly record when I am not sitting next to it, I would prefer that it would still record the programme, no matter if all the plugins failed.
-Petri
On Fri, Sep 19, 2008 at 8:20 AM, Petri Helin phelin@googlemail.com wrote:
But why should even a fatal error (from plugin's perspective) cause VDR to not start? It should only cause the plugin not to be loaded. Of course plugins could also implement more intelligent initialization and try to deal with possible errors, but isn't it easier to just handle it in one place - at the VDR?
You could also argue that the plugins the user has selected to load are intended to be used and not optional 'if you load, fine. if not, no biggie'. I can see valid points for both sides but in the end it's my opinion that the plugins are responsibile to deal with their own problems, not VDR.
If I think of the core VDR, I see its main function as recording TV-programmes. From that perspective it's not that big of a problem if it doesn't start properly due to a plugin not bevahing properly if I am sitting next to the PC and can fix or circumvent the problem. But since it will mostly record when I am not sitting next to it, I would prefer that it would still record the programme, no matter if all the plugins failed.
I think it's a huge assumption (and incorrect one) to say the main function of VDR is to record tv shows. I know many people who use it for watching live tv, email notices, weather report, playing other media something like an htpc, etc. Maybe Klaus would consider making this optional the same way he did when users spoke out against VDR automatically exiting because of "video stream broken". At least then you could select to load VDR anyway and I could select to exit VDR so I am notified & can fix the problem. ;)
Cheers -Derek
VDR User wrote:
I think it's a huge assumption (and incorrect one) to say the main function of VDR is to record tv shows. I know many people who use it for watching live tv, email notices, weather report, playing other media something like an htpc, etc.
Ok, let me rephrase it: for my purposes, the main task of VDR is to record TV programmes. I do use it for lots of other purposes also, but for me that is its main task.
Some kind of an analogy could be drawn between Firefox and VDR: Although I use a lot of extensions with Firefox, I wouldn't want one that doesn't really behave to stop me using Firefox altogether. And before you ask, I don't know how Firefox reacts to a badly behaving extension ;)
-Petri
On 09/19/08 17:20, Petri Helin wrote:
VDR User wrote:
I like that VDR won't load if a plugin failed. That means there was a problem, and I should go fix it. Also, it's the plugins job to continue on non-fatal errors, not VDR. How would VDR even know whats a non-fatal error for a certain plugin? From VDR's perspective either the plugin is working or it's not.
But why should even a fatal error (from plugin's perspective) cause VDR to not start? It should only cause the plugin not to be loaded. Of course plugins could also implement more intelligent initialization and try to deal with possible errors, but isn't it easier to just handle it in one place - at the VDR?
If I think of the core VDR, I see its main function as recording TV-programmes. From that perspective it's not that big of a problem if it doesn't start properly due to a plugin not bevahing properly if I am sitting next to the PC and can fix or circumvent the problem. But since it will mostly record when I am not sitting next to it, I would prefer that it would still record the programme, no matter if all the plugins failed.
And what if such a plugin implements a device?
The definition of the Initialize() and Start() functions is:
A return value of false indicates that something has gone wrong and the plugin will not be able to perform its task. In that case, the plugin should write a proper error message to the log file. The first plugin that returns false from its Initialize() or Start() function will cause VDR to exit.
So, if a plugin thinks VDR can well run without it, it should just return true. If it's a plugin that's absolutely necessary for operation, it shall return false upon failure. VDR can't know that by itself.
Klaus
So, if a plugin thinks VDR can well run without it, it should just return true. If it's a plugin that's absolutely necessary for operation, it shall return false upon failure. VDR can't know that by itself.
Maybe all plugins could have a setting "on failure terminate vdr" ? Then the user could choose what plugin is vital and what is just extra, so if the user sets it to no, then vdr would just continue.
Josce
_________________________________________________________________ Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.a...
Petri Helin wrote:
In fact I am already wondering why plugins are not hot-pluggable...
They are, to some degree, by using the proxy plugin. The proxy plugin can delay loading a plugin, and for some plugins it can unload a plugin while VDR is running. It can also do the requested continue-on-error for plugins.
Cheers,
Udo
Udo Richter wrote:
Petri Helin wrote:
In fact I am already wondering why plugins are not hot-pluggable...
They are, to some degree, by using the proxy plugin. The proxy plugin can delay loading a plugin, and for some plugins it can unload a plugin while VDR is running. It can also do the requested continue-on-error for plugins.
Well that was nice news. Haven't heard about the proxy plugin before for some reason, but I will give it a shot and see what it is capable of. Thanks.
-Petri
-
Diego Pierotto -
Josce -
Jouni Karvo -
Klaus Schmidinger -
Petri Helin -
Udo Richter -
VDR User