Re: [vdr] Epgsearch does not create timers
I traced the problem down to a missing svdrphosts.conf file. Timers are now set ok. Thanks for the clues. Christian Wieninger <[EMAIL PROTECTED]> wrote: Stuart Morris wrote: > I am having difficulty getting Epgsearch plugin to create any timers. > I am using epgsearch version 0.9.20. My epg is received from UK "Freeview" > DVB-t. VDR is running as root. There are no patches to vdr. The only > other plugin > running at the same time is -Pskincurses because the VDR system is headless. > I am using VDR version 1.4.4. > > Am I doing something wrong here or is this a bug? Please check if the SVDRP port in epgsearchs setup is the same as in VDRs. If not please adjust them and restart VDR. After ~25 seconds the timers will be created or later when you trigger the update manually. If this does not solve the problem, please inspect your syslogs when you trigger the search timer update. You could also activate epgsearchs log with '-P epgsearch -v 2' and check the file epgsearch.log in the plugins config directory. BR, Christian ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr - Inbox full of unwanted email? Get leading protection and 1GB storage with All New Yahoo! Mail.___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr-xine loses OSD and sound
Hello, I'm experiencing a strange problem with VDR and Xine plugin. When the system boots and Xine player connects to the vdr-xine socket for the first time, everything is working great. You can navigate OSD with keyboard (I'm using Xine remote) in any OSD display mode, sound works and all channels are available. However, things start to go wrong if I quit the Xine player and then launch it again and connect to vdr-xine. If any of the blend scaled OSD display modes is configured, no OSD is shown. X11 overlay display mode works. No sound can be heard at all (sound works ok from any other program using Alsa). Xine remote works though, as I can normally switch channels with keyboard. Also picture is ok, just no sound and no OSD in blend scaled OSD modes available. Restarting VDR doesn't fix this. Neither does unloading and then reloading the DVB card driver modules. You need to power down the system and reboot before everything will work fine again. Does anyone have any idea what could be wrong here? System: Ubuntu Edgy (kernel 2.6.17) Technotrend FF DVB-C 2.1 with firmware dvb-ttpci-01.fw-2622 Terratec Cinergy 1200 DVB-C nVidia Geforce 6200 with driver 8776 VDR 1.4.5, vdr-xine 0.7.10 (no other plugins besides vdr-xine) xine-lib and xine-ui from CVS compiled on 2006/12/12 xine is started using command: xine --post expand:centre_crop_out_mode=1 --post vdr_video --post vdr_audio --deinterlace --video-driver xvmc --audio-driver alsa --no- splash --fullscreen --hide-gui vdr://tmp/vdr-xine/stream#demux:mpeg_pes Alsa is configured to use optical audio port on the motherboard, which is connected to an external receiver. vdr-xine is configured to get primary device on Xine connect. -- Tuomas Jormola <[EMAIL PROTECTED]> ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Vdr or driver performance dropout
Kartsa kirjoitti: Marko Mäkelä kirjoitti: In any case, you could profile the old and new version of vdr and see if there is any obvious difference. I'll have to take that into consideration. I'll have to download the old version and all that :) I was unsuccesfull with setting up an environment where I could run vdr-1.3.22. It just exits with exit code 2 with no other explanation in. It tells me to turn off NPTL by setting LD_ASSUME_KERNEL=2.4.1 and then all I get is "error while loading shared libraries" to about any command I try. And then "cannot open shared object file: No such file or directory" and depending on the command the library file varies. So no comparison :( \\Kartsa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Problems with a binary library
Hello List The em84xx plugin is using the libEM84xx.so library. This beast is only available binary and seems to be incompatible with glibc > 2.3.5 What can I do to get this combination working in a glibc >=2.4 environment ? Is it possible to create a static .la library bundled with these dependend libraries: ldd /usr/lib/libEM84xx.so linux-gate.so.1 => (0xe000) libpthread.so.0 => /lib/libpthread.so.0 (0xb7e03000) libm.so.6 => /lib/libm.so.6 (0xb7dde000) libc.so.6 => /lib/libc.so.6 (0xb7cbf000) /lib/ld-linux.so.2 (0x8000) or are there any other possibilities ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
On Wed, Feb 07, 2007 at 12:06:20AM +0100, Udo Richter wrote: > >Could you please introduce a configuration option that would > >allow the Power key to initiate shutdown even while playing a recording > >(provided that nothing else prevents a shutdown, of course)? > > You can shut down while playback, you just have to confirm it. And if > you don't confirm it, VDR will shut down 5 minutes after the playback ends. Sure, if the playback ends. It won't end with my patched softdevice that stops the playback of recordings when Shutdown.IsUserInactive() returns true. I had a look at the code, specifically vdr.c and shutdown.c. I believe that the right thing would be to add a second parameter to ConfirmShutdown(), to allow cReplayControl::NowReplaying() to be ignored. Then, VDR wouldn't shut down unexpectedly while playing back a recording even if the inactivity timeout kicks in. But VDR wouldn't ask for confirmation when pressing the Power key. Thus, no new configuration option would be necessary. What do you think? Should I submit a patch? Marko ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
It's a safe assumption that when a user presses a power button, they intend that the device be immediately turned off or shut down. I can't think of any device that performs any differently. If a user wants to shut down vdr after he's done watching a playback, he would obviously still be sitting there when it ends therefore he can press the power button when its over. I see no reason to make this issue more complex than it should be. The power button has the final say, you don't press it if you don't want to force a shutdown. What logic is there that vdr should be any different? Just my $.02 fellas. Cheers! ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-xine loses OSD and sound
Hi, Tuomas Jormola wrote: > System: > Ubuntu Edgy (kernel 2.6.17) > Technotrend FF DVB-C 2.1 with firmware dvb-ttpci-01.fw-2622 > Terratec Cinergy 1200 DVB-C > nVidia Geforce 6200 with driver 8776 I can confirm the OSD issue even with driver 9746. I'll have a look at it probably next week. > VDR 1.4.5, vdr-xine 0.7.10 (no other plugins besides vdr-xine) > xine-lib and xine-ui from CVS compiled on 2006/12/12 > xine is started using command: > xine --post expand:centre_crop_out_mode=1 --post vdr_video --post > vdr_audio --deinterlace --video-driver xvmc --audio-driver alsa Would you mind using xxmc or xv until the OSD issue is fixed. > --no-splash --fullscreen --hide-gui > vdr://tmp/vdr-xine/stream#demux:mpeg_pes > Alsa is configured to use optical audio port on the motherboard, which > is connected to an external receiver. vdr-xine is configured to get > primary device on Xine connect. I'm sorry, I've no hint for you concerning the audio issue. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
Marko Mäkelä wrote: You can shut down while playback, you just have to confirm it. And if you don't confirm it, VDR will shut down 5 minutes after the playback ends. Sure, if the playback ends. It won't end with my patched softdevice that stops the playback of recordings when Shutdown.IsUserInactive() returns true. I do understand this right: If your softdevice detects IsUserInactive, then it sends a 'stop playback' to VDR? Weired... I guess the most natural behavior would be to pretend that you're playing back normally, eg. make softdevice eat the incoming data stream at normal speed without decoding it. Then, VDR wouldn't shut down unexpectedly while playing back a recording even if the inactivity timeout kicks in. But VDR wouldn't ask for confirmation when pressing the Power key. Thus, no new configuration option would be necessary. More easy, just drop the playback check completely. A running playback means that the !Interact check in vdr.c will prevent any housekeeping and thus automatic shutdown. But again, that way you cannot get VDR into inactive mode manually while playback. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
On Wed, Feb 07, 2007 at 10:40:44PM +0100, Udo Richter wrote: > Marko Mäkelä wrote: > >>You can shut down while playback, you just have to confirm it. And if > >>you don't confirm it, VDR will shut down 5 minutes after the playback > >>ends. > > > >Sure, if the playback ends. It won't end with my patched softdevice > >that stops the playback of recordings when Shutdown.IsUserInactive() > >returns true. > > I do understand this right: If your softdevice detects IsUserInactive, > then it sends a 'stop playback' to VDR? Weired... It doesn't actually send anything to VDR; it'll just return 0 from cDevice::PlayVideo() and cDevice::PlayAudio(). It will also have to sleep a little, because otherwise VDR would use 100% of CPU. > I guess the most natural behavior would be to pretend that you're > playing back normally, eg. make softdevice eat the incoming data stream > at normal speed without decoding it. Well, that would still break this scenario: You're watching a recording while it is being recorded. Then you get interrupted and push the Power button. Before the timed recording finishes and VDR gets a chance to shut down, you get back and push a button to switch to interactive state. You will be surprised to see that the playback doesn't resume from the same position. > >Then, VDR wouldn't shut down unexpectedly while playing back > >a recording even if the inactivity timeout kicks in. But VDR wouldn't > >ask for confirmation when pressing the Power key. Thus, no new > >configuration option would be necessary. > > More easy, just drop the playback check completely. A running playback > means that the !Interact check in vdr.c will prevent any housekeeping > and thus automatic shutdown. Before writing my previous message, I added #if 0 #endif around the NowReplaying() check in shutdown.c, and it seems to work. VDR will be powered off during playback if there is no timed recording going on. > But again, that way you cannot get VDR into inactive mode manually while > playback. Is that feature necessary? If you believe so, maybe you could introduce a configuration option for enabling it? The default behaviour would be to obey the Power button immediately. The option could be named something like "Shutdown during playback must be confirmed". Marko ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
Marko Mäkelä wrote: Well, that would still break this scenario: You're watching a recording while it is being recorded. Then you get interrupted and push the Power button. Before the timed recording finishes and VDR gets a chance to shut down, you get back and push a button to switch to interactive state. You will be surprised to see that the playback doesn't resume from the same position. Actually I wouldn't. Its the POWER key, not the PAUSE key. If I do that with my old VCR (means, switch off the TV instead of pausing the VCR) the same thing would happen. But again, that way you cannot get VDR into inactive mode manually while playback. Is that feature necessary? If you believe so, maybe you could introduce a configuration option for enabling it? The default behaviour would be to obey the Power button immediately. The option could be named something like "Shutdown during playback must be confirmed". Its mainly because the 'old' code did not shut down while playback, at least since 1.3.25. (No longer stopping Transfer Mode or replay immediately when the Power button is pressed (thanks to Rolf Ahrenberg)) Before, I think, the power button stopped playback and did shut down. I don't want to add yet another config option, either we let the power button work directly while playback, or we ask for confirmation on playback. Whatever the majority wants. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
On 2/7/07, Udo Richter <[EMAIL PROTECTED]> wrote: I don't want to add yet another config option, either we let the power button work directly while playback, or we ask for confirmation on playback. Whatever the majority wants. Recording is one thing but I've never seen a VCR, DVD player, DVR, etc. that asks you to confirm if you hit the power button during playback. People don't usually hit a power button on accident, they hit it expecting that the device shut off. If I hit the power button on my dvd player while I'm watching a movie, I don't have to confirm anything. I hit the button and go on my way without waiting around to see what happens. This is by far the most common behavior of any device with a power button. I'm honestly surprised forcing conditions on the power button is even a consideration! The idea was bad from the start (sorry Rolf Ahrenberg). ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
R: R: [vdr] VDR & Multiple frontends
Since I don't get any news you, I'm working on implementing this. I had to modify these files: device.c device.h dvbdevice.c dvbdevice.h At the moment I don't get any image yet from second frontend yet, but changing channel I get EPG from second tuner. I hope in the next day sto submit a patch Best Regards, Eddi > -Messaggio originale- > Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per conto di > Klaus Schmidinger > Inviato: domenica 10 dicembre 2006 11.14 > A: vdr@linuxtv.org > Oggetto: Re: R: [vdr] VDR & Multiple frontends > > Eddi wrote: > >> Eddi wrote: > >>> Hi, > >>> > >>> I wrote a patch to Steve Toth hvr3000 repository, so my FlyDVB Trio > can > >>> use multiple frontend. > >>> > >>> The bus of the two frontend is shared, isn't possible to get access to > >>> both frontend simultaneously, so I get an -EBUSY error by trying > >>> accessing frontend1 if frontend0 is in use. > >>> > >>> VDR doesn't support yet the second frontend, and it try to get > exclusive > >>> access on both frontend on start, so the second frontend is inusabile. > >>> > >>> Vdr should probe for multiple frontend at start, and access frontend > >>> only on channel change. > >> Wouldn't it be better to hide this deficiency in the driver? > >> Klaus > > > > Actually it seems that on Hybrid card is and will be quite common that > > multiple frontend share a single bus. > > > > Linuxtv API tell that a driver may offer frontendN nodes > > www.linuxtv.org/download/linux-dvb-api-1.0.0.pdf > > that vdr don't support > > > > I think is impossibile, to solve by driver, since switching between > frontend > > happened by opening the frontend/demux device. > > > > VDR try access to frontend on start (actually it doesn't start multiple > fe > > on same adapter, so I solved with symlink), and open all the frontend. > > > > If open fails it refuse to use the frontend. If open with success, it > start > > N thread as many as the number of adapter/frontend. > > > > I don't understand what you mean for deficiency, if you mean the EBUSY, > yes > > I could remove it, but it doesn't solve since with two tread open I > should > > get a ping-pong between the two frontend so I can't get any image. > > > > If you mean for deficiency the two frontend on the same adapter, is > > logically correct, and is a deficiency that vdr doesn't supporti t. > > > > Since I like VDR, I'd like it support this. > > I've gone through the LinuxDVB API description regarding the frontend > again and apparently it is documented that multiple frontends on the same > adapter can't be open in read/write mode at the same time (so the > "deficiency" > is actually on VDR's side ;-). > > Well, so VDR could open them in read-only mode first and switch one of > them > to read/write mode shortly whenever it does a tuning operation, and go > back > to read-only after that. It would also have to switch to read/write > shortly > whenever it reads a frontend event with ioctl(FE_GET_EVENT). With such > modifications > it should be possible to make VDR support a multiple frontend adapter. > In order to set up the necessary VDR devices, cDvbDevice::Initialize() > would also have to be enhanced to probe for multiple frontends > on the same adapter. > > Klaus > > ___ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[PATCH] R: R: [vdr] VDR & Multiple frontends
The patch is ready and available as attachment to this mail and at http://tux.dpeddi.com/lr319sta/downloads/vdr_1.4.5_eddi-multiple-frontend.pa tch Card detection should work in all environment, and the patch should be transparent in environment with adapters that have a single tuner or adapter that provide a bus for each tuner. In this case the frontend appear as a VDR device. At the moment, sometime channel change works and sometime fails, I suppose is due to the time thread needs to close. Can someone do a regression test with my patch applied? I need help to solve this? I have to use valgring? Best Regards, Eddi > -Messaggio originale- > Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per conto di > Eddi > Inviato: giovedì 8 febbraio 2007 0.34 > A: 'VDR Mailing List' > Oggetto: R: R: [vdr] VDR & Multiple frontends > > Since I don't get any news you, I'm working on implementing this. > > I had to modify these files: > device.c device.h dvbdevice.c dvbdevice.h > > At the moment I don't get any image yet from second frontend yet, but > changing channel I get EPG from second tuner. > > I hope in the next day sto submit a patch > > Best Regards, > > Eddi > > > > > -Messaggio originale- > > Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per conto > di > > Klaus Schmidinger > > Inviato: domenica 10 dicembre 2006 11.14 > > A: vdr@linuxtv.org > > Oggetto: Re: R: [vdr] VDR & Multiple frontends > > > > Eddi wrote: > > >> Eddi wrote: > > >>> Hi, > > >>> > > >>> I wrote a patch to Steve Toth hvr3000 repository, so my FlyDVB Trio > > can > > >>> use multiple frontend. > > >>> > > >>> The bus of the two frontend is shared, isn't possible to get access > to > > >>> both frontend simultaneously, so I get an -EBUSY error by trying > > >>> accessing frontend1 if frontend0 is in use. > > >>> > > >>> VDR doesn't support yet the second frontend, and it try to get > > exclusive > > >>> access on both frontend on start, so the second frontend is > inusabile. > > >>> > > >>> Vdr should probe for multiple frontend at start, and access frontend > > >>> only on channel change. > > >> Wouldn't it be better to hide this deficiency in the driver? > > >> Klaus > > > > > > Actually it seems that on Hybrid card is and will be quite common that > > > multiple frontend share a single bus. > > > > > > Linuxtv API tell that a driver may offer frontendN nodes > > > www.linuxtv.org/download/linux-dvb-api-1.0.0.pdf > > > that vdr don't support > > > > > > I think is impossibile, to solve by driver, since switching between > > frontend > > > happened by opening the frontend/demux device. > > > > > > VDR try access to frontend on start (actually it doesn't start > multiple > > fe > > > on same adapter, so I solved with symlink), and open all the frontend. > > > > > > If open fails it refuse to use the frontend. If open with success, it > > start > > > N thread as many as the number of adapter/frontend. > > > > > > I don't understand what you mean for deficiency, if you mean the > EBUSY, > > yes > > > I could remove it, but it doesn't solve since with two tread open I > > should > > > get a ping-pong between the two frontend so I can't get any image. > > > > > > If you mean for deficiency the two frontend on the same adapter, is > > > logically correct, and is a deficiency that vdr doesn't supporti t. > > > > > > Since I like VDR, I'd like it support this. > > > > I've gone through the LinuxDVB API description regarding the frontend > > again and apparently it is documented that multiple frontends on the > same > > adapter can't be open in read/write mode at the same time (so the > > "deficiency" > > is actually on VDR's side ;-). > > > > Well, so VDR could open them in read-only mode first and switch one of > > them > > to read/write mode shortly whenever it does a tuning operation, and go > > back > > to read-only after that. It would also have to switch to read/write > > shortly > > whenever it reads a frontend event with ioctl(FE_GET_EVENT). With such > > modifications > > it should be possible to make VDR support a multiple frontend adapter. > > In order to set up the necessary VDR devices, cDvbDevice::Initialize() > > would also have to be enhanced to probe for multiple frontends > > on the same adapter. > > > > Klaus > > > > ___ > > vdr mailing list > > vdr@linuxtv.org > > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > > > ___ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr vdr_1.4.5_eddi-multiple-frontend.patch Description: Binary data ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
Udo Richter wrote: > Marko Mäkelä wrote: >> Well, that would still break this scenario: You're watching a recording >> while it is being recorded. Then you get interrupted and push the Power >> button. Before the timed recording finishes and VDR gets a chance to >> shut down, you get back and push a button to switch to interactive state. >> You will be surprised to see that the playback doesn't resume from the >> same position. > > Actually I wouldn't. Its the POWER key, not the PAUSE key. If I do that > with my old VCR (means, switch off the TV instead of pausing the VCR) > the same thing would happen. > >>> But again, that way you cannot get VDR into inactive mode manually >>> while playback. >> >> Is that feature necessary? If you believe so, maybe you could introduce >> a configuration option for enabling it? The default behaviour would be >> to obey the Power button immediately. The option could be named >> something like "Shutdown during playback must be confirmed". > > Its mainly because the 'old' code did not shut down while playback, at > least since 1.3.25. (No longer stopping Transfer Mode or replay > immediately when the Power button is pressed (thanks to Rolf Ahrenberg)) > Before, I think, the power button stopped playback and did shut down. > > > I don't want to add yet another config option, either we let the power > button work directly while playback, or we ask for confirmation on > playback. Whatever the majority wants. I'd also say that the Power button should shutdown without confirmation unless there is a recording going on or a plugin is Active(). To avoid accidental shutdowns it might still prompt the user with "Shutdown - press any key to stay up" or something like that for a few seconds, but it shouldn't be necessary to confirm anything, even if a replay is currently going on. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
