[vdr] [ANNOUNCE] svdrpservice-0.0.3
Hi there, svdrpservice is a helper plugin which makes it easy for other plugins to send SVDRP commands to an other VDR. Homepage: http://vdr.schmirler.de. Most important changes in 0.0.3: No longer using a fixed buffer size. Users of the epgsync plugin might appreciate this when using external EPG sources with e.g. tvmovie2vdr. The amount of data provided there was often too large for the old buffer. The plugin has its own setup menu now. You can specify default values for the server IP and port, so these values no longer have to be entered in each and every plugin using svdrpservice. If a plugin requests a connection to the special IP 0.0.0.0 or the IP is missing completely (empty string), the default value from the svdrpservice setup will be used. Likewise port number 0 will be replaced. Note that yet it's not possible to enter port number 0 in the plugins which use svdrpservice. Future versions will fix this. A silent change of the service specification came along with the new setup options: Server IP and port are now in/out parameters. After the service call for a new connection these parameter contain the actual values for IP and port, i.e. the svdrpservice default values are returned if they have been used. Note that the service version has not been increased as the modification does not break compatibility. Changelog: - Dynamic buffer size - New setup options: default server IP and port - Silent change of service interface: serverIP and serverPort are now in/out params - Connection handle was not reset to -1 when disconnecting a shared connection which is still in use - Non-blocking connect Enjoy, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Handling of temporarily encrypted channels
Luca Olivetti wrote: En/na Ondrej Wisniewski ha escrit: I am using VDR 1.4.5 with the integrated auto pid feature and without any CAM. When tuning to an encrypted channel, the CA value gets set accordingly and "channel not available" is displayed. So far so good. However there are channels that encrypt only certain programs and are free the rest of the time. When tuning to this "free" channel while the program is encrypted, the CA value will be set and "channel not available" shown. But when tuning to the same channel again when it is not encrypted any more it seems that VDR just checks the CA value and displays "channel not available" instead of checking the currently broadcast CA value. So the channel cannot be watched even if it is free in the moment. This is quite annoying and decreases the WAF a lot :-/ Is there an easy way to fix this? Edit the file dvbdevice.c, insert a line "return true;" at the beginning of the method cDvbDevice::ProvidesCa. With this modification you can tune to encoded channels, however you'll never see a "channel not available", you'll just see a black screen. This, btw, also solves the problem of channels that declare they're scrambled when they aren't. Bye OK, that seems like a good workaround. But it is not a real solution. I mean I still want to see "channel not available" but only when it is really not available (it is currently encrypted). That would be the correct behaviour. Furthermore I am not sure what happens when a recording on such a channel starts and it is really encrypted. The current solution is safe because it doesn't tune to the channel if the CA value is set. However it has the drawback of not recording even if the channel might be FTA again (that's a real show stopper). So I propose that VDR should always tune to a channel that is requested, get the current CA value from the data stream (and not from the channels.conf) and then decide if the channel can be shown/recorded. Does that sound like a good solution? Any obvious drawbacks? Ondrej ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Handling of temporarily encrypted channels
Stone wrote: > Is there an easy way to fix this? Edit the file dvbdevice.c, insert a line "return true;" at the beginning of the method cDvbDevice::ProvidesCa. With this modification you can tune to encoded channels, however you'll never see a "channel not available", you'll just see a black screen. This, btw, also solves the problem of channels that declare they're scrambled when they aren't. With this modification to dvbdevice.c, I wonder if VDR will still crash when a timer goes off on a channel and all the sudden it becomes encrypted. This would normally cause a broken data stream and VDR would do an emergency exit. Regards. I remember these crashes with VDR 1.2.6 but if I'm not wrong there are no restarts any more with 1.4.5. If a channel gets encrypted during live view, the picture just freezes. Then I can safely switch to another channel manually. If the encryption starts during a recording, the recording just stops. But now I'm not so sure any more because VDR could just have restarted without me noticing. And after the restart it doesn't continue the recording because now the CA value is set in the channels.conf Ondrej ... ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr doesn't recognise some remote keys when using LIRC
I'm using a lirc setup with inputlircd daemon with a hauppauge remote on a dvb card. Everything works with the remote plugins using /dev/ input/eventX, but I'm trying to share the remote with several applications. For some reason when trying to learn keys with LIRC, when I'm running the inputlircd daemon, VDR refuses to react to them. I can see the keys being interpreted properly with irw. Does anyone know why this can be? -- Torgeir Veimo [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr doesn't recognise some remote keys when using LIRC
Hello Torgeir, * Torgeir Veimo <[EMAIL PROTECTED]> [06-03-07 11:44]: > For some reason when trying to learn keys with LIRC, when I'm running > the inputlircd daemon, VDR refuses to react to them. I can see the > keys being interpreted properly with irw. Does anyone know why this > can be? I use a small self build IR receiver which works perfectly. See: http://lirc.org/receivers.html http://lirc.org/images/schematics.gif 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 version 1.4.6 released
On 3/3/07, Klaus Schmidinger <[EMAIL PROTECTED]> wrote: VDR version 1.4.6 is now available at Should the APIVERSION be incremented to 1.4.6? Best Regards. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr doesn't recognise some remote keys when using LIRC
In <[EMAIL PROTECTED]>, Torgeir Veimo wrote: > I'm using a lirc setup with inputlircd daemon with a hauppauge remote > on a dvb card. Everything works with the remote plugins using /dev/ > input/eventX, but I'm trying to share the remote with several > applications. > > For some reason when trying to learn keys with LIRC, when I'm running > the inputlircd daemon, VDR refuses to react to them. I can see the > keys being interpreted properly with irw. Does anyone know why this > can be? Have you tried inputlirc? It's a LIRC emulator for input devices so you can use it with any LIRC client without having to patch and configure lircd. -- TH * http://www.realh.co.uk ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr doesn't recognise some remote keys when using LIRC
On 6 Mar 2007, at 14:20, Tony Houghton wrote: In <[EMAIL PROTECTED]>, Torgeir Veimo wrote: I'm using a lirc setup with inputlircd daemon with a hauppauge remote on a dvb card. Everything works with the remote plugins using /dev/ input/eventX, but I'm trying to share the remote with several applications. For some reason when trying to learn keys with LIRC, when I'm running the inputlircd daemon, VDR refuses to react to them. I can see the keys being interpreted properly with irw. Does anyone know why this can be? Have you tried inputlirc? It's a LIRC emulator for input devices so you can use it with any LIRC client without having to patch and configure lircd. Inputlirc and inputlircd are the same? I'm using inputlircd at the moment. -- Torgeir Veimo [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr doesn't recognise some remote keys when using LIRC
In <[EMAIL PROTECTED]>, Torgeir Veimo wrote: > On 6 Mar 2007, at 14:20, Tony Houghton wrote: > > >In <[EMAIL PROTECTED]>, Torgeir Veimo > >wrote: > > > >>For some reason when trying to learn keys with LIRC, when I'm > >>running the inputlircd daemon, VDR refuses to react to them. I can > >>see the keys being interpreted properly with irw. Does anyone know > >>why this can be? > > > >Have you tried inputlirc? It's a LIRC emulator for input devices so > >you can use it with any LIRC client without having to patch and > >configure lircd. > > Inputlirc and inputlircd are the same? I'm using inputlircd at the > moment. Oops, I didn't let your message filter into my brain properly. I just assumed you wouldn't be using that because it seems quite obscure unless you're using Debian. -- TH * http://www.realh.co.uk ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re[2]: [vdr] vdr-1.5.1 & problems with the new shutdown code
Hi Udo, I've applied your patch to vdr.c and it seems that it's working now. Cheers, Juergen Udo schrieb am Sonntag, 4. März 2007 um 11:06: > Jürgen Schilling wrote: >> I've the same problem with VDR 1.5.1... The VDR does not shutdown >> after a recording. > It looks like VDR assumed the start to be manually, not automatically. > Same for you: Check the logs for "assuming manual start of VDR", "next > timer event at" and "next plugin wakeup at" messages, and check > setup.conf for the NextWakeupTime line. These infos should explain what > went wrong. > Cheers, > Udo > ___ > 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
Re: [vdr] [ANNOUNCE] VDR version 1.4.6 released
On Tuesday 06 March 2007, Stone wrote: > On 3/3/07, Klaus Schmidinger <[EMAIL PROTECTED]> wrote: > > VDR version 1.4.6 is now available at > > Should the APIVERSION be incremented to 1.4.6? No, there were no API changes between 1.4.5 and 1.4.6. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] frontend 1 timed out while tuning to channel 0
Hi, I get a lot of these messages in my logfile. What does channel 0 mean ? --snip-- video:~ # grep "timed out while tuning" /var/log/vdr Mar 6 19:47:54 video vdr: [19313] frontend 1 timed out while tuning to channel 0, tp 212522 Mar 6 19:50:00 video vdr: [19313] frontend 1 timed out while tuning to channel 0, tp 212699 Mar 6 19:50:22 video vdr: [19313] frontend 1 timed out while tuning to channel 0, tp 212728 Mar 6 19:54:12 video vdr: [19313] frontend 1 timed out while tuning to channel 0, tp 111914 Mar 6 19:59:49 video vdr: [19313] frontend 1 timed out while tuning to channel 0, tp 112544 Mar 6 20:01:55 video vdr: [19313] frontend 1 timed out while tuning to channel 0, tp 112721 Mar 6 20:11:01 video vdr: [19313] frontend 1 timed out while tuning to channel 0, tp 212090 Mar 6 20:14:52 video vdr: [19313] frontend 1 timed out while tuning to channel 0, tp 212522 Mar 6 20:16:58 video vdr: [19313] frontend 1 timed out while tuning to channel 0, tp 212699 Mar 6 20:17:19 video vdr: [19313] frontend 1 timed out while tuning to channel 0, tp 212728 Mar 6 20:21:10 video vdr: [19313] frontend 1 timed out while tuning to channel 0, tp 111914 Mar 6 20:26:46 video vdr: [19313] frontend 1 timed out while tuning to channel 0, tp 112544 --snip the first lines of my channels.conf looks like: --snip-- video:~ # head /etc/vdr/channels.conf :Freie Sender Das Erste;ARD:11836:hC34:S19.2E:27500:101:102=deu;106=deu:104:0:28106:1:1101:0 ZDF;ZDFvision:11953:hC34:S19.2E:27500:110:120=deu,121=2ch;125=dd:130:0:28006:1:1079:0 Bayerisches FS;ARD:11836:hC34:S19.2E:27500:201:202=deu:204:0:28107:1:1101:0 RTL Television,RTL;RTL World:12187:hC34:S19.2E:27500:163:104=deu;106=deu:105:0:12003:1:1089:0 SAT.1;ProSiebenSat.1:12480:vC34:S19.2E:27500:1791:1792=deu;1795=deu:34:0:46:133:33:0 RTL2;RTL World:12187:hC34:S19.2E:27500:166:128=deu:68:0:12020:1:1089:0 ProSieben;ProSiebenSat.1:12480:vC34:S19.2E:27500:255:256=deu;257=deu:32:0:898:133:33:0 Super RTL,S RTL;RTL World:12187:hC34:S19.2E:27500:165:120=deu:65:0:12040:1:1089:0 KABEL1;ProSiebenSat.1:12480:vC34:S19.2E:27500:511:512=deu:33:0:899:133:33:0 --snip-- I use vdr-1.4.5-2 and v4l-dvb from todays hg. -- Gruß Dieter -- I do not get viruses because I do not use MS software. If you use Outlook then please do not put my email address in your address-book so that WHEN you get a virus it won't use my address in the From field. pgpMhfq0siaoA.pgp Description: PGP signature ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
