Re: [vdr] auto shutdown (-s) question
On Saturday 07 February 2009, Udo Richter wrote: > On 07.02.2009 11:26, Ville Skyttä wrote: > >> VDR does not know whether the shutdown script initiated the shutdown or > >> decided to ignore it, > > > > I suppose it would be quite easy to implement that and maybe some other > > scenarios as well using shutdown script exit statuses. For example exit > > status 0 = shutdown successfully initiated (already in current VDR), 10 = > > shutdown ignored, 11 = something else, 12 = something else, anything else > > = an unexpected error occurred. > > Unfortunately it's not that easy. Currently, VDR backgrounds the call to > the shutdown script, and detaches the shutdown script from the VDR > process. Only because of that, the script can 'survive' the kill of VDR, Why is that even necessary? Shutdown scripts could selectively background+detach things that need to survive killing of VDR and the script themselves, if any. > and only because of that the script can display messages via SVDRP. Hmm, why wouldn't a non-background, non-detached script called by VDR be able to do that? > Some shutdown scripts do set > error levels, but there's no common definition about the meaning of > error levels. Right, my post was about mentioning a possibility to add such common definitions if found feasible. > Defining error levels for the shutdown script would > thereby be potentially incompatible to existing scripts. Sure. Authors of such scripts get to keep both pieces if their scripts break due to use of undocumented features ;). I suppose changing the shutdown script not to run background+detached would probably be a source of more incompatibilities though, and ones that script authors would not be responsible for. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Use FF Card only as output device
On 07.02.2009 23:01, Patrick Maier wrote: > Hi, > > my DVB-S FF card broke down those days. I think it's the tuner of the card, > because it can't lock to a frequency: > - Output of femon - > using '/dev/dvb/adapter0/frontend0' > FE: Philips TDA8083 DVB-S (SAT) > status 01 | signal 6363 | snr 1919 | ber 080484c0 | unc bfc2d9f8 | > - End of output - > > Additional I've a DVB-S budget card in the system. > So is it possible to use the Tuner of the buget card and use the broken FF > card only as display device and tell the system not to use the broken tuner? You could insert the lines if (IsPrimrayDevice()) return false; at the beginning of cDvbDevice::ProvidesSource(). Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.4
On 05.02.2009 08:15, Matthias Fechner wrote: > Hi Klaus, > > Klaus Schmidinger schrieb: >> DO NOT USE THIS VERSION FOR PRODUCTIVE RECORDINGS!! >> THE RECORDING OR OTHER FILE FORMATS MAY STILL CHANGE >> AND ANY RECORDINGS MADE WITH THIS VERSION MIGHT NOT >> WORK WITH FUTURE VERSIONS! > > do you think that this will really change in the future? I don't know. As you may have seen there were problems with the PAT/PMT, so maybe there are still other problems that haven't surfaced yet. > If I record now with vdr 1.7.4 normal dvb-s recordings, will I be able > to watch them with future versions of VDR? If I knew the answer to that, I guess I wouldn't have had to write the above statement ;-) Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] auto shutdown (-s) question
On 08.02.2009 10:19, Ville Skyttä wrote: > On Saturday 07 February 2009, Udo Richter wrote: >> Unfortunately it's not that easy. Currently, VDR backgrounds the call to >> the shutdown script, and detaches the shutdown script from the VDR >> process. Only because of that, the script can 'survive' the kill of VDR, > > Why is that even necessary? Shutdown scripts could selectively > background+detach things that need to survive killing of VDR and the script > themselves, if any. Detaching as a script isn't that easy, the reason for these ugly echo "..." | at now workarounds. >> and only because of that the script can display messages via SVDRP. > > Hmm, why wouldn't a non-background, non-detached script called by VDR be able > to do that? The main VDR thread would have to wait for the return, and SVDRP won't be handled until then. SVDRP connections from the script would timeout. You can see that if you use SVDRP commands from commands.conf without explicitly backgrounding. On the error level return, thats also not very practicable for VDR. For VDR the question isn't whether we do shutdown or not. Either there will be a kill signal coming, or there won't. The question for VDR is: If we don't shut down, when should VDR check again, or how does VDR know that the background job is done? An error level return is quite limited here. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] auto shutdown (-s) question
On Sunday 08 February 2009, Udo Richter wrote: > On 08.02.2009 10:19, Ville Skyttä wrote: > > On Saturday 07 February 2009, Udo Richter wrote: > >> Unfortunately it's not that easy. Currently, VDR backgrounds the call to > >> the shutdown script, and detaches the shutdown script from the VDR > >> process. Only because of that, the script can 'survive' the kill of VDR, > > > > Why is that even necessary? Shutdown scripts could selectively > > background+detach things that need to survive killing of VDR and the > > script themselves, if any. > > Detaching as a script isn't that easy, the reason for these ugly echo > "..." | at now workarounds. There are other alternatives to choose from if one for some reason can't stomach the "at" approach. > >> and only because of that the script can display messages via SVDRP. > > > > Hmm, why wouldn't a non-background, non-detached script called by VDR be > > able to do that? > > The main VDR thread would have to wait for the return, and SVDRP won't > be handled until then. SVDRP connections from the script would timeout. > You can see that if you use SVDRP commands from commands.conf without > explicitly backgrounding. That sounds like a bug to me, irrespective of this discussion. > The question for VDR is: If we > don't shut down, when should VDR check again, or how does VDR know that > the background job is done? Why would VDR check or care in the first place? > An error level return is quite limited here. Sure, but quite a bit better than what's currently sanely doable. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] vdr-webvideo 0.1.0
New version of the Webvideo plugin is available at http://users.tkk.fi/~aajanki/vdr/webvideo/vdr-webvideo-0.1.0.tgz The Webvideo plugin is a tool for browsing and downloading videos from popular video sharing websites, such as YouTube and Google video, using VDR menu interface or a command line client. With the help of xineliboutput plugin the videos can be played directly without downloading them first. Changes since the last version: - The downloader backend is now a separate server process. The user interface is no longer blocked while the plugin is waiting for a web server to respond. - Support for streaming - A new command line client that has the same capabilities as the plugin but can be used without VDR. - Alternative URLs for videos. For example, Youtube module first tries to download high quality version, and falls back to standard version if high quality version is not available. - Cleaning up of the XML menu scheme. New menu items: textfields, item lists, query buttons. - Status page that lists uncompleted downloads - Updated YouTube, Google, and SVTPlay modules to work with the recent changes on these sites -- Antti Ajanki ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.4
Hi Klaus, Klaus Schmidinger schrieb: > If I knew the answer to that, I guess I wouldn't have had to write > the above statement ;-) ;) Yeah you are right. I think I will wait for version 1.7.5 and then I will start to test it. Best regards Matthias -- "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." -- Rich Cook ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-webvideo 0.1.0
On Sunday 08 February 2009 21:45:55 Antti Ajanki wrote: > New version of the Webvideo plugin is available at > http://users.tkk.fi/~aajanki/vdr/webvideo/vdr-webvideo-0.1.0.tgz Maybe I'm just doing it wrong but compiling the usual way I'm getting Plugin webvideo: ERROR: plugin webvideo doesn't honor APIVERSION - not compiled! It does compile after linking webvideo-0.1.0/vdr-plugin to webvideo and changing the Makefile so that the relative paths for VDRDIR and LIBDIR match reality. Since the instructions don't mention anything about this I'm left wondering if you packaged the wrong version or something? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] why I must first compile xine-lib， not ffmpeg?
when I first compile xine-lib is OK，second compile ffmpeg is OK. IF I first compile ffmpeg is OK，second compile xine-lib is failure. the syslog: make[2]: *** [xineplug_decode_faad_la-xine_faad_decoder.lo] Error 1 make[2]: Leaving directory `/root/xine-lib-1-2-926ee2edf0d8/src/audio_dec' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/root/xine-lib-1-2-926ee2edf0d8/src' make: *** [all-recursive] Error 1 why ,who can tell me? _ 上Windows Live 中国首页，下载最新版 MSN！ http://im.live.cn/___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Use FF Card only as output device
Hi Klaus, >> my DVB-S FF card broke down those days. I think it's the tuner of the >> card, >> So is it possible to use the Tuner of the buget card and use the broken >> FF >> card only as display device and tell the system not to use the broken >> tuner? > > You could insert the lines > [...] > at the beginning of cDvbDevice::ProvidesSource(). Cool. Works great (except for some distortions for the first two seconds when switching the channels, but this is ok for me :-) [I still use VDR 1.5.18] Thanks a lot Patrick ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] why I must first compile xine-lib£¬not f fmpeg?
Op Ma, 9 februari, 2009 08:07, schreef LinHai: > > when I first compile xine-lib is OK£¬second compile ffmpeg is OK. > > IF I first compile ffmpeg is OK£¬second compile xine-lib is failure. > > the syslog: > > make[2]: *** [xineplug_decode_faad_la-xine_faad_decoder.lo] Error 1 > make[2]: Leaving directory `/root/xine-lib-1-2-926ee2edf0d8/src/audio_dec' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/root/xine-lib-1-2-926ee2edf0d8/src' > make: *** [all-recursive] Error 1 > > why ,who can tell me? Based upon assumption, I think you're using the SVN/Trunk editions of xinelib 1.2 and FFMpeg. In that case, it's simple. In your first 'example' xinelib links/compiles to an older and allready installed version of ffmpeg, you then install a newer version of ffmpeg (prepare for problems with xinelib!). With your 2nd 'example' you've updated ffmpeg first and then xinelib will try to compile/link against the updated ffmpeg libraries, which will then fail. Sollution for this is simple. Stick to the stable xinelib 1.1.x editions and *do not* use the --external-ffmpeg configure flag. I've got the feeling that the ffmpeg trunk has been updated again and that it broke the of xinelib 1.2. Figures, since it's all bleeding edge we're talking here and it has happened before ;) Regards, Niels Wagenaar ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
