Re: [vdr] [ANNOUNCE] VDR version 1.4.5 released
Klaus Schmidinger wrote: > VDR version 1.4.5 is now available at > > ftp://ftp.cadsoft.de/vdr/vdr-1.4.5.tar.bz2 I have updated the SUSE Linux RPM packages at http://software.opensuse.org/download/vdr/ to 1.4.5 as well. I have also added the vdr-plugins package. It contains some additional plugins. cu Ludwig -- (o_ Ludwig Nussel //\ SUSE LINUX Products GmbH, Development V_/_ http://www.suse.de/ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.0
Heikki Manninen wrote: > On su, 2007-01-14 at 14:48 +0100, Klaus Schmidinger wrote: > >> Your CAM doesn't respond to the QUERY that VDR sends to it. >> So VDR can't ask the CAM whether it is able to decrypt a certain >> channel (in addition to others it is already decrypting). >> So it's a hard-/firmware restriction of your CAM. >> >> The only CAM I have here that actually can decrypt more than one >> channel is the Alphacrypt with firmware revision 3.09. > > Conax 4.00e is able to decrypt 2-3 channels at the same time. Although > when used with VDR 1.5.0 it is not. Also when using previous versions of If the CAM doesn't respond to a QUERY, then how is VDR supposed to know whether it can decrypt more than one channel at a time? > VDR you have to fake fixed receiver number in the channels.conf for this > to be possible - if you put in B00 it doesn't work anymore :) It's > sometimes a bit unrealiable but works. VDR 1.4 used the FIRST/MORE/LAST method to send multiple CaPmts. Since some CAMs apparently don't handle this correctly, I changed that to the simpler ADD/UPDATE method, which should be supported by any CAM that can decrypt more than one channel. Can you please check if there is a newer firmware for the Conax CAM and maybe try that? Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.0
Klaus Schmidinger wrote: > Heikki Manninen wrote: > >>On su, 2007-01-14 at 14:48 +0100, Klaus Schmidinger wrote: >> >> >>>Your CAM doesn't respond to the QUERY that VDR sends to it. >>>So VDR can't ask the CAM whether it is able to decrypt a certain >>>channel (in addition to others it is already decrypting). >>>So it's a hard-/firmware restriction of your CAM. >>> >>>The only CAM I have here that actually can decrypt more than one >>>channel is the Alphacrypt with firmware revision 3.09. >> >>Conax 4.00e is able to decrypt 2-3 channels at the same time. Although >>when used with VDR 1.5.0 it is not. Also when using previous versions of > > If the CAM doesn't respond to a QUERY, then how is VDR supposed to > know whether it can decrypt more than one channel at a time? I think i can say with resonable confidence that most VDR-Systems don't change at a regular basis, but stay unchanged (more or less) for sometimes years(*). So why not make a "probe capabilities" function (where you could also probe "unsafe" things, with a bit of user interaction(*2)) and then store the information away in a config-file. The next time the system has significant changes you can probe again. *: My first VDR-machine is for e.g. practically unchanged (hardware-wise) since i build it sometime near end of 2000(!). *2: Ever installed Windows? I've seen: "The screen may go blank and the computer can freeze", or something in the same sense. Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. ___ 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 Sat, Jan 13, 2007 at 09:48:47PM +0100, Udo Richter wrote: > >A more important suggestion: Could you please add a notification method > >to status.h for notifying plugins whether VDR is currently in > >interactive mode? > > You can poll this state on your own by calling > Shutdown.IsUserInactive(). There is currently no internal notification > anyway, VDR itself does poll it and would need to poll it to call > MsgSetSuspend. Can you please explain to me why this could not be based on events? While VDR is running, I would guess that the only way it can become interactive is by receiving button events from the remote control unit. You could have the RCU dispatcher thread (or any other place that changes the flag) call MsgSetInteractive(). If this is not possible, then you could declare a condition variable. The main loop of the main thread would check it with pthread_cond_timedwait() and call MsgSetInteractive() when the status changes. > The function itself is a light-weighted inline function, > so its no problem to poll it once a second from cPlugin::MainThreadHook > or similar. Users would certainly prefer not to wait for a random time (0..1 seconds) for VDR to become active. In softdevice, this delay could be bypassed when softdevice is in charge of the remote control unit. But softdevice (or DirectFB) doesn't support all types of remote control units. Marko ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] OSD-Resolution
Hi Guys, I remember that someone had some kind of patch for increasing the OSD-resoluion in VDR. I just can't find that post that mentioned about that... Could anyone post a link to that site that had that patch.. I would like to try that out :-) Regards, René ___ 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: While VDR is running, I would guess that the only way it can become interactive is by receiving button events from the remote control unit. Hmm, ok, I was mainly thinking of becoming inactive - since this is after a certain time has passed, it can only be polled. For lots of cases the current patch wont poll this state at all for a long time. But becoming active again is a different thing of course. Users would certainly prefer not to wait for a random time (0..1 seconds) for VDR to become active. Actually, the key press lets the VDR main loop spin, and directly after the key press was handled, there's a call to MainThreadHook, so its not that long. Anyway, I'll think about that. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.0
Klaus Schmidinger wrote: Heikki Manninen wrote: On su, 2007-01-14 at 14:48 +0100, Klaus Schmidinger wrote: Your CAM doesn't respond to the QUERY that VDR sends to it. So VDR can't ask the CAM whether it is able to decrypt a certain channel (in addition to others it is already decrypting). So it's a hard-/firmware restriction of your CAM. The only CAM I have here that actually can decrypt more than one channel is the Alphacrypt with firmware revision 3.09. Conax 4.00e is able to decrypt 2-3 channels at the same time. Although when used with VDR 1.5.0 it is not. Also when using previous versions of If the CAM doesn't respond to a QUERY, then how is VDR supposed to know whether it can decrypt more than one channel at a time? Didn't mean that it is supposed to. Just informed you to let you (and others) now that sometimes it's possible :) VDR you have to fake fixed receiver number in the channels.conf for this to be possible - if you put in B00 it doesn't work anymore :) It's sometimes a bit unrealiable but works. VDR 1.4 used the FIRST/MORE/LAST method to send multiple CaPmts. Since some CAMs apparently don't handle this correctly, I changed that to the simpler ADD/UPDATE method, which should be supported by any CAM that can decrypt more than one channel. Can you please check if there is a newer firmware for the Conax CAM and maybe try that? Hmm.. have to try. Although I'm not aware how to do it. Should it be able to update from the broadcast signal? -- Heikki M ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
