Re: [vdr] vdr on AllWinner A10, possible or madness?
You probably should ask this also in the linux-sunxi mailling list. While I cannot answer all questions for you, I can tell you that video decoding could be problematic for now. The A10 has a proprietary video decoder for HD stuff. There is support for XBMC from empat0 and someone is working on vlc +libcedarx support, but that's it. VDR can use xine amongst other softpipes and that is not supported yet to my knowledge. VDR backend with XBMC frontend however could work. Your DVB device has kernel support and should be compilable. On 03-12-12 10:10, cedric.dew...@telfort.nl wrote: Hi All, I now have a standard PC running arch linux and VDR. This works ok, but it uses between 80-150W of power. Much heat and noise, and cost :-). Therefore I was looking for a more power-eficient system. Is it possible to run archlinux and vdr on a system like this? Mele A1000: http://www.elbay.net/nl/content/mele-a1000-allwinner-a10-cortex-a8 I'm wondering if the following works: -HD playback using close source mali driver -Driver for dib07000 based USB DVB receivers -ACPI wake-up and shutdown (does the RTC code work?) -Does VDR and the following plugins compile and run? vdr-addon-acpiwakeup 0.0.10-1 vdr-plugin-epgsearch-git 20120311-1 vdr-plugin-live-git 0.2.0.git-16 vdr-plugin-sc-hg 574-3 vdr-plugin-xineliboutput-git 20120911-1 oscam Best regards, Cedric ___ 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] Digital Devices (Linux 4 Media) 4 port (8 tuner) octopus/Duoflex experiences
On 27-11-12 07:44, Halim Sahin wrote: Hi, On Mon, Nov 26, 2012 at 09:20:30PM +0100, Lars Hanisch wrote: Hi, Am 26.11.2012 20:10, schrieb Halim Sahin: On Mon, Nov 26, 2012 at 06:20:56PM +0100, Lars Hanisch wrote: My DVB-C/T card is working here for months with no problems. Second dual tuner is ordered... :) What about cam support in vdr for this card??? It's not implemented yet. You can however redirect the input of one tuner through the ci, so you can decrypt one transponder. Well this is not good news for users in germany because without a working cam, you can't watch much channels with dvb-c. Don't know but I can't understand, why cam handling must be done in userspace for these new cards.c And oscam doesn't support this? I feel softcam support to be much easier then a hardcam these days. As for driver support, you can of course ask Digital Devices if they can implement said feature of course :) Having not found any user on DVB-S(2) and only one DVB-CT user on this list so far, I do feel there aren't many using these cards yet, hence the lack of support. ciao Halim ___ 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] Digital Devices (Linux 4 Media) 4 port (8 tuner) octopus/Duoflex experiences
On 27-11-12 10:33, Ralph Metzler wrote: Oliver Schinagl writes: I'm interested for such information. (I'm looking also for good well supported DVB-S2 device to target multiple satellite) I've a question for you Olivier. I don't know that brand. Why going to 1 dualtuner board and the octopus. In the same brand you can also use the Cine S2 that could eventually be expended with a dualtuner board for example. What are the limitation? From what I know, is that the hardware is nearly identical on both setups. The Cine S2 is an octopus with only 2 connectors (which allows 4 extra tuners) and has 2 onboard tuners, so 6 tuners maximum. The Octopus is ONLY the bridge chip (in FPGA form strangly in the latest revisions, was the nGene before, driver is the same so maybe they got some IP from micronas to put in the FPGA due to performance/scaling issues?) but has 4 connectors for expansion cards. So you can connect 8 Micronas has nothing to do with the new bridge. nGene is no longer in production and it also lacked inputs and outputs to support more tuners/CIs.\ Well the new FPGA based design uses the nGene driver, so it at the very least is compatible on an API front. It would sound somewhat reasonable that either they re-implemented part of the chip or got some secret IP from micronas ;) In any case, there is an FPGA on the board that behaves 'like' the nGene :) Regards, Ralph ___ 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] Digital Devices (Linux 4 Media) 4 port (8 tuner) octopus/Duoflex experiences
On 27-11-12 10:37, Ralph Metzler wrote: Oliver Schinagl writes: On 11/26/12 22:39, Oliver Schinagl wrote: On 11/26/12 21:28, Lars Hanisch wrote: Hi, Am 26.11.2012 21:24, schrieb Oliver Schinagl: Why build it externally? I was quite certain that the ddbridge drivers are in mainline for a while now? Which modules to you select? ddbridge is upstream with DVB-S2 support, but not the driver for my C/T-module. What C/T driver module are you using? I do have a Terratec DVB-T dual (which does dvb-c too on 1 of the dual tuners) which features the drxk demodulator. So I think your card should be quite supported in mainline already. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=drivers/media/pci/ngene/ngene-cards.c;hb=HEAD even lists: \/ so unless I go digging into the linux-media code, I think even dvb-CT support has been mainlined :) static int port_has_drxk(struct i2c_adapter *i2c, int port) The newer C/T modules use ST demods. I think the DRX-K is also no longer being produced. I bought a Terratec dual T PCI-e which features two DRX-K demods. While not the newest card, it's reasonably new and driver support is 6 months old. I guess there's a huge batch of DRX-K's still being used up? What demod/tuner is being used on the DVB-S2 bit? Just to know the state of support of the demod/tuner. Regards, Ralph ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Digital Devices (Linux 4 Media) 4 port (8 tuner) octopus/Duoflex experiences
On 27-11-12 11:03, Ralph Metzler wrote: Oliver Schinagl writes: The newer C/T modules use ST demods. I think the DRX-K is also no longer being produced. I bought a Terratec dual T PCI-e which features two DRX-K demods. While not the newest card, it's reasonably new and driver support is 6 More like 6 year old card and driver. It only got remerged recently. months old. I guess there's a huge batch of DRX-K's still being used up? I guess but it is not being used on any new Digital Devices cards. What demod/tuner is being used on the DVB-S2 bit? Just to know the state of support of the demod/tuner. stv0900/stv6110 It uses the drivers stv090x and stv6110x which are also used by several different cards from other manufacturers and are working very well. Thank you for your report, 'very' well sounds indeed very promising and I just placed my order with l4m :) Regards, Ralph ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Digital Devices (Linux 4 Media) 4 port (8 tuner) octopus/Duoflex experiences
Hey VDR friends, I'm thinking of getting into the whole satellite thing (DVB-T user for now) and was searching for interesting DVB-S2 tuners. I found that the l4m octopus/duoflex-s2 a very interesting device. While expensive you can connect up to 8 tuners! to a single PCI-e 1x lane (Bandwith should be more then enough). While I know there is a octopus mini-pcie device, I heard that there where some PCB issues so decided on getting the PCI-e version. I have tried googling for some up to date linux! information but found very little. Are there any l4m/dd octopus/duoflex DVB-S2 (or even CAM/DVB-C/DVB-T) users here that can share their current (and past) experiences? The tuner (only 1 dualtuner board and the octopus) will set you back a good 200Euro so I want to be sure that the devices is properly supported. Thanks, Oliver ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Digital Devices (Linux 4 Media) 4 port (8 tuner) octopus/Duoflex experiences
On 26-11-12 11:28, Davide Chiarini wrote: 2012/11/26 Oliver Schinagl oliver+l...@schinagl.nl mailto:oliver+l...@schinagl.nl I have tried googling for some up to date linux! information but found very little. I think you've already answered your question here. Being an early adopter rarely pays off in the linux world, unless you have the skills to troubleshoot the drivers yourself and enjoy doing so. The 'ddbridge' is already in the kernel. They claim on their site that it has linux support. Their linux4media site sells these specifically aimed at the linux market. So in theory, it should work and should work well. But since there's so little results (price related?) under linux for this 2008 or so board, could be either really good (it works and works well) or nobody has bought it yet. Having had such problems in the past with other devices, even if 200EUR/8 tuners sounds like a good deal it really depends on how much you value your free time. It's 200E for 2 tuners only. each additional 2 tuners is about 150E. So you pay 50E for the 'base' board, without any tuner, and 150E for each dual-tuner tuner module, which can be either DVB-S2 or DVB-T/DVB-C. Also keep in mind that theoretically every tuner needs its own cable coming from the dish, right now I have two of them and having 8 for me would be impossible (if you want to make them go inside the walls through existing pipes). Well I don't even have a dish yet, but this would be for future upgrades of course. Yes running 8 wires through the wall is a lot, but manageable. FYI, my vdr box is an old PIII 1000 with 2 DVB-S2 tuners and one DVB-T (all of them PCI). I've been using it for about 4 years now. ciao davide ___ 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] Digital Devices (Linux 4 Media) 4 port (8 tuner) octopus/Duoflex experiences
On 26-11-12 11:32, Michael Stilmant wrote: Hello, I'm interested for such information. (I'm looking also for good well supported DVB-S2 device to target multiple satellite) I've a question for you Olivier. I don't know that brand. Why going to 1 dualtuner board and the octopus. In the same brand you can also use the Cine S2 that could eventually be expended with a dualtuner board for example. What are the limitation? From what I know, is that the hardware is nearly identical on both setups. The Cine S2 is an octopus with only 2 connectors (which allows 4 extra tuners) and has 2 onboard tuners, so 6 tuners maximum. The Octopus is ONLY the bridge chip (in FPGA form strangly in the latest revisions, was the nGene before, driver is the same so maybe they got some IP from micronas to put in the FPGA due to performance/scaling issues?) but has 4 connectors for expansion cards. So you can connect 8 tuners maximally :) That said, they also have a single/dual CI expansion module to go onto 1 of those connectors, but I dare not to find out how their CI driver support is. Usually softcams work much better. Regards, Michael -Original Message- From: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] On Behalf Of Oliver Schinagl Sent: 26 November 2012 10:14 To: VDR Mailing List Subject: [vdr] Digital Devices (Linux 4 Media) 4 port (8 tuner) octopus/Duoflex experiences Hey VDR friends, I'm thinking of getting into the whole satellite thing (DVB-T user for now) and was searching for interesting DVB-S2 tuners. I found that the l4m octopus/duoflex-s2 a very interesting device. While expensive you can connect up to 8 tuners! to a single PCI-e 1x lane (Bandwith should be more then enough). While I know there is a octopus mini-pcie device, I heard that there where some PCB issues so decided on getting the PCI-e version. I have tried googling for some up to date linux! information but found very little. Are there any l4m/dd octopus/duoflex DVB-S2 (or even CAM/DVB-C/DVB-T) users here that can share their current (and past) experiences? The tuner (only 1 dualtuner board and the octopus) will set you back a good 200Euro so I want to be sure that the devices is properly supported. Thanks, Oliver ___ 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 mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Digital Devices (Linux 4 Media) 4 port (8 tuner) octopus/Duoflex experiences
Why build it externally? I was quite certain that the ddbridge drivers are in mainline for a while now? Which modules to you select? On 11/26/12 18:20, Lars Hanisch wrote: Hi, Am 26.11.2012 10:13, schrieb Oliver Schinagl: I'm thinking of getting into the whole satellite thing (DVB-T user for now) and was searching for interesting DVB-S2 tuners. I found that the l4m octopus/duoflex-s2 a very interesting device. While expensive you can connect up to 8 tuners! to a single PCI-e 1x lane (Bandwith should be more then enough). While I know there is a octopus mini-pcie device, I heard that there where some PCB issues so decided on getting the PCI-e version. I have tried googling for some up to date linux! information but found very little. Are there any l4m/dd octopus/duoflex DVB-S2 (or even CAM/DVB-C/DVB-T) users here that can share their current (and past) experiences? The tuner (only 1 dualtuner board and the octopus) will set you back a good 200Euro so I want to be sure that the devices is properly supported. I'm using a DuoFlex with a DVB-C/T dual tuner modul. How to build the latest drivers is described here (german only): http://www.vdr-portal.de/board16-video-disk-recorder/board85-hdtv-dvb-s2/113367-aktuelle-treiber-f%C3%BCr-octopus-ddbridge-cines2-ngene-ddbridge-duoflex-s2-duoflex-ct-cinect-sowie-tt-s2-6400-teil-2/ If you'r using Ubuntu or yaVDR, there's the linux-media-dkms package with this driver included. My DVB-C/T card is working here for months with no problems. Second dual tuner is ordered... :) Lars. ___ 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] Digital Devices (Linux 4 Media) 4 port (8 tuner) octopus/Duoflex experiences
On 11/26/12 21:28, Lars Hanisch wrote: Hi, Am 26.11.2012 21:24, schrieb Oliver Schinagl: Why build it externally? I was quite certain that the ddbridge drivers are in mainline for a while now? Which modules to you select? ddbridge is upstream with DVB-S2 support, but not the driver for my C/T-module. Ah! that explains a lot. I did a quick read through that german site, but they simply pull the latest media-linux git tree, so that should go into mainline every cycle or so I guess. Nevertheless, good to know that DVB-S2 on the ngene is well supported (I guess ) :) Lars. On 11/26/12 18:20, Lars Hanisch wrote: Hi, Am 26.11.2012 10:13, schrieb Oliver Schinagl: I'm thinking of getting into the whole satellite thing (DVB-T user for now) and was searching for interesting DVB-S2 tuners. I found that the l4m octopus/duoflex-s2 a very interesting device. While expensive you can connect up to 8 tuners! to a single PCI-e 1x lane (Bandwith should be more then enough). While I know there is a octopus mini-pcie device, I heard that there where some PCB issues so decided on getting the PCI-e version. I have tried googling for some up to date linux! information but found very little. Are there any l4m/dd octopus/duoflex DVB-S2 (or even CAM/DVB-C/DVB-T) users here that can share their current (and past) experiences? The tuner (only 1 dualtuner board and the octopus) will set you back a good 200Euro so I want to be sure that the devices is properly supported. I'm using a DuoFlex with a DVB-C/T dual tuner modul. How to build the latest drivers is described here (german only): http://www.vdr-portal.de/board16-video-disk-recorder/board85-hdtv-dvb-s2/113367-aktuelle-treiber-f%C3%BCr-octopus-ddbridge-cines2-ngene-ddbridge-duoflex-s2-duoflex-ct-cinect-sowie-tt-s2-6400-teil-2/ If you'r using Ubuntu or yaVDR, there's the linux-media-dkms package with this driver included. My DVB-C/T card is working here for months with no problems. Second dual tuner is ordered... :) Lars. ___ 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 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] Digital Devices (Linux 4 Media) 4 port (8 tuner) octopus/Duoflex experiences
On 11/26/12 22:39, Oliver Schinagl wrote:
On 11/26/12 21:28, Lars Hanisch wrote:
Hi,
Am 26.11.2012 21:24, schrieb Oliver Schinagl:
Why build it externally? I was quite certain that the ddbridge
drivers are in mainline for a while now?
Which modules to you select?
ddbridge is upstream with DVB-S2 support, but not the driver for my
C/T-module.
What C/T driver module are you using?
I do have a Terratec DVB-T dual (which does dvb-c too on 1 of the dual
tuners) which features the drxk demodulator. So I think your card should
be quite supported in mainline already.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=drivers/media/pci/ngene/ngene-cards.c;hb=HEAD
even lists: \/ so unless I go digging into the linux-media code, I think
even dvb-CT support has been mainlined :)
static int port_has_drxk(struct i2c_adapter *i2c, int port)
{
u8 val;
if (i2c_read(i2c, 0x29+port, val) 0)
return 0;
return 1;
}
static int demod_attach_drxk(struct ngene_channel *chan,
struct i2c_adapter *i2c)
{
struct drxk_config config;
memset(config, 0, sizeof(config));
config.microcode_name = drxk_a3.mc;
config.qam_demod_parameter_count = 4;
config.adr = 0x29 + (chan-number ^ 2);
chan-fe = dvb_attach(drxk_attach, config, i2c);
if (!chan-fe) {
printk(KERN_ERR No DRXK found!\n);
return -ENODEV;
}
chan-fe-sec_priv = chan;
chan-gate_ctrl = chan-fe-ops.i2c_gate_ctrl;
chan-fe-ops.i2c_gate_ctrl = drxk_gate_ctrl;
return 0;
}
Ah! that explains a lot. I did a quick read through that german site,
but they simply pull the latest media-linux git tree, so that should go
into mainline every cycle or so I guess.
Nevertheless, good to know that DVB-S2 on the ngene is well supported (I
guess ) :)
Lars.
On 11/26/12 18:20, Lars Hanisch wrote:
Hi,
Am 26.11.2012 10:13, schrieb Oliver Schinagl:
I'm thinking of getting into the whole satellite thing (DVB-T user
for now) and was searching for interesting DVB-S2
tuners. I found that the l4m octopus/duoflex-s2 a very interesting
device. While expensive you can connect up to 8
tuners! to a single PCI-e 1x lane (Bandwith should be more then
enough). While I know there is a octopus mini-pcie
device, I heard that there where some PCB issues so decided on
getting the PCI-e version.
I have tried googling for some up to date linux! information but
found very little. Are there any l4m/dd octopus/duoflex
DVB-S2 (or even CAM/DVB-C/DVB-T) users here that can share their
current (and past) experiences? The tuner (only 1
dualtuner board and the octopus) will set you back a good 200Euro
so I want to be sure that the devices is properly
supported.
I'm using a DuoFlex with a DVB-C/T dual tuner modul. How to build
the latest drivers is described here (german only):
http://www.vdr-portal.de/board16-video-disk-recorder/board85-hdtv-dvb-s2/113367-aktuelle-treiber-f%C3%BCr-octopus-ddbridge-cines2-ngene-ddbridge-duoflex-s2-duoflex-ct-cinect-sowie-tt-s2-6400-teil-2/
If you'r using Ubuntu or yaVDR, there's the linux-media-dkms
package with this driver included.
My DVB-C/T card is working here for months with no problems.
Second dual tuner is ordered... :)
Lars.
___
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 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 mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.30
On 19-09-12 09:25, Mika Laitio wrote: From the log I can see that the driver apparently makes DVB-S/DVB-S2 available under adapter1/frontend0 and tries to provide DVB-T on adapter1/frontend1. But if it does so, it tells the application that it can provide DVB-S/DVB-S2 *and* DVB-T at the *same* time - which apparently isn't the case. Yes, you are correct. If I use frontend0 for DVB-S, I can't use frontend 1 at a same time for DVB-T. I will try in the evening to build the latest drivers myself to check whether both frontends are still created also with that one. Are there some other cards/drivers available with similar limitation where only a single frontend0 is created? I unfortunatly missed half the discussion, but for two frontends to work, you need a dual-tuner card. I currently have a Terratec Cynergy dual T PCI-e card, that has two tuners that can be individually be controlled with dvb-fe-tool. I think the name dual-tuner is actually wrong, as it should be dual-frontend, tripple tuner in my case. One front-end can be connected to DVB-T-tuner Or Analogue TV-tuner (currently not working afaik) and the second frontend can be connected to a different DVB-T-tuner Or DVB-C-tuner. Check the output of dvb-fe-tool and see what it outputs. Or, your driver is bugged/manufacturer lied about it's actual capabilities! Mika ___ 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] [PATCH] Make RGYB buttons customizable (attempt 2)
On 08/12/12 14:32, Klaus Schmidinger wrote: On 12.08.2012 14:28, Jouni Karvo wrote: On 12.08.2012 12:23, Klaus Schmidinger wrote: But is it really that necessary? It is not necessary, but having a remote with different order of coulours, it is weird to have them in a different order on the OSD and in the remote. Plus the skip 1min forwards and 1min backwards during a replay of a recording - it would be nicer to have the buttons in the right order in the remote for this. But naturally these are not functional problems, they are usability issues (and not a very big issue for me). Do you actually *have* a remote control with non-standard color keys? Yes, hence why I wrote the patch. My remote is actually quite common, it's the one from iMon, supplied with many HTPC cases, such as silverstone cases. 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
Re: [vdr] [PATCH] Make RGYB buttons customizable (attempt 2)
On 08/12/12 16:15, Jouni Karvo wrote: On 12.08.2012 15:46, JJussi wrote: On 12.8.2012 15.32, Klaus Schmidinger wrote: On 12.08.2012 14:28, Jouni Karvo wrote: On 12.08.2012 12:23, Klaus Schmidinger wrote: But is it really that necessary? It is not necessary, but having a remote with different order of coulours, it is weird to have them in a different order on the OSD and in the remote. Plus the skip 1min forwards and 1min backwards during a replay of a recording - it would be nicer to have the buttons in the right order in the remote for this. But naturally these are not functional problems, they are usability issues (and not a very big issue for me). Do you actually *have* a remote control with non-standard color keys? Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr I have too.. Already for years (from 2005).. I have RGBY. It's Silver Stone -case with integrated IR remote. Me too. RGBY Try the patch, see if it works for you :D yours, Jouni ___ 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] [PATCH] Make RGYB buttons customizable (attempt 2)
Patch reminder, in case it was missed the first time around :)
On 07/23/12 11:21, oliver+l...@schinagl.nl wrote:
From: Oliver Schinagloli...@schinagl.nl
I've noticed a nasty typo in menu.c where all 4 buttons would be displayed
as Button0. So a cosmetic issue only! Since there where no comments on my
previous e-mails have not been answerd yet, so sending it as a whole patch
again instead of a simple patch upon patch ;)
VDR currently assumes all remote controls have the same order of buttons.
This is not always the case. This patch allows you to change the order
of buttons in the UI.
This feature obviously only works on patched skins. Classic, lcars and
sttng skins are patched. Unpatched skins will remain to work fine, but
will ignore button order. Patching of the skin takes very minimum effort.
config.*: Load/Save Button information
menu.c : Add button selection to the UI
skin*.c : Use button order from the config file
Signed-off-by: Oliver Schinagloli...@schinagl.nl
---
config.c | 12
config.h |4
menu.c|9 +
skinclassic.c | 11 +++
skinlcars.c | 19 +++
skinsttng.c | 11 +++
6 files changed, 50 insertions(+), 16 deletions(-)
diff --git a/config.c b/config.c
index 56454df..165bcee 100644
--- a/config.c
+++ b/config.c
@@ -424,6 +424,10 @@ cSetup::cSetup(void)
UseDolbyDigital = 1;
ChannelInfoPos = 0;
ChannelInfoTime = 5;
+ Button0 = 0;
+ Button1 = 1;
+ Button2 = 2;
+ Button3 = 3;
OSDLeftP = 0.03;
OSDTopP = 0.03;
OSDWidthP = 0.93;
@@ -620,6 +624,10 @@ bool cSetup::Parse(const char *Name, const char *Value)
else if (!strcasecmp(Name, UseDolbyDigital)) UseDolbyDigital=
atoi(Value);
else if (!strcasecmp(Name, ChannelInfoPos)) ChannelInfoPos =
atoi(Value);
else if (!strcasecmp(Name, ChannelInfoTime)) ChannelInfoTime=
atoi(Value);
+ else if (!strcasecmp(Name, Button0)) Button0=
atoi(Value);
+ else if (!strcasecmp(Name, Button1)) Button1=
atoi(Value);
+ else if (!strcasecmp(Name, Button2)) Button2=
atoi(Value);
+ else if (!strcasecmp(Name, Button3)) Button3=
atoi(Value);
else if (!strcasecmp(Name, OSDLeftP))OSDLeftP =
atof(Value);
else if (!strcasecmp(Name, OSDTopP)) OSDTopP=
atof(Value);
else if (!strcasecmp(Name, OSDWidthP)) { OSDWidthP =
atof(Value); ChkDoublePlausibility(OSDWidthP, 0.87); }
@@ -719,6 +727,10 @@ bool cSetup::Save(void)
Store(UseDolbyDigital,UseDolbyDigital);
Store(ChannelInfoPos, ChannelInfoPos);
Store(ChannelInfoTime,ChannelInfoTime);
+ Store(Button0,Button0);
+ Store(Button1,Button1);
+ Store(Button2,Button2);
+ Store(Button3,Button3);
Store(OSDLeftP, OSDLeftP);
Store(OSDTopP,OSDTopP);
Store(OSDWidthP, OSDWidthP);
diff --git a/config.h b/config.h
index acdf77a..3dd86ae 100644
--- a/config.h
+++ b/config.h
@@ -294,6 +294,10 @@ public:
int UseDolbyDigital;
int ChannelInfoPos;
int ChannelInfoTime;
+ int Button0;
+ int Button1;
+ int Button2;
+ int Button3;
double OSDLeftP, OSDTopP, OSDWidthP, OSDHeightP;
int OSDLeft, OSDTop, OSDWidth, OSDHeight;
double OSDAspect;
diff --git a/menu.c b/menu.c
index 9f4c54e..bea03b1 100644
--- a/menu.c
+++ b/menu.c
@@ -2510,6 +2510,7 @@ void cMenuSetupBase::Store(void)
class cMenuSetupOSD : public cMenuSetupBase {
private:
const char *useSmallFontTexts[3];
+ const char *buttonColorTexts[4];
int osdLanguageIndex;
int numSkins;
int originalSkinIndex;
@@ -2560,12 +2561,20 @@ void cMenuSetupOSD::Set(void)
useSmallFontTexts[0] = tr(never);
useSmallFontTexts[1] = tr(skin dependent);
useSmallFontTexts[2] = tr(always);
+ buttonColorTexts[0] = tr(Key$Red);
+ buttonColorTexts[1] = tr(Key$Green);
+ buttonColorTexts[2] = tr(Key$Yellow);
+ buttonColorTexts[3] = tr(Key$Blue);
Clear();
SetSection(tr(OSD));
Add(new cMenuEditStraItem(tr(Setup.OSD$Language),osdLanguageIndex,
I18nNumLanguagesWithLocale(),I18nLanguages()-At(0)));
Add(new cMenuEditStraItem(tr(Setup.OSD$Skin),skinIndex, numSkins,
skinDescriptions));
if (themes.NumThemes())
Add(new cMenuEditStraItem(tr(Setup.OSD$Theme),themeIndex,
themes.NumThemes(), themes.Descriptions()));
+ Add(new cMenuEditStraItem(tr(Setup.OSD$Button0),data.Button0, 4,
buttonColorTexts));
+ Add(new cMenuEditStraItem(tr(Setup.OSD$Button1),data.Button1, 4,
buttonColorTexts));
+ Add(new cMenuEditStraItem(tr(Setup.OSD$Button2),data.Button2, 4,
buttonColorTexts));
+ Add(new cMenuEditStraItem(tr(Setup.OSD$Button3),data.Button3, 4,
buttonColorTexts));
Add(new cMenuEditPrcItem( tr(Setup.OSD$Left (%)),data.OSDLeftP, 0.0,
0.5));
Add(new cMenuEditPrcItem( tr(Setup.OSD$Top
Re: [vdr] [PATCH] Make RGYB buttons customizable (attempt 2)
On 08/11/12 23:48, VDR User wrote: On Mon, Jul 23, 2012 at 2:21 AM,oliver+l...@schinagl.nl wrote: VDR currently assumes all remote controls have the same order of buttons. This is not always the case. This patch allows you to change the order of buttons in the UI. This feature obviously only works on patched skins. Classic, lcars and sttng skins are patched. Unpatched skins will remain to work fine, but will ignore button order. Patching of the skin takes very minimum effort. The ability to customize the order of the colored buttons is something I was hoping to see in the VDR reboot/redesign/next-generation/whatever, after 2.0 is released. If your patch is adopted before that, I would hope so, it is a rather trivial patch I don't think an altered button order should be displayed if the skin doesn't support it since it could cause confusion for the user -- more specifically the wives and kids in VDR world. :) Indeed :) In other words, does the skin support button reorder? if yes, then reorder them in the osd if no, do not reorder them in the osd It should exactly do that. Button order is stored in VDR, but the skin decides whether it uses it or not. I patched the default 3 skins included in VDR to follow the reordering. 3rd party skins I have not patched and thus are not using the re-ording. It is fully optional for skin devs. That said, in the skin it is also very trivial to use :) ___ 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] Quiet times...
I'll bite too :) I'm still 'waiting' for comments on my patch that I posted on 23-07-12; 11:21 [PATCH] Make RGYB buttons customizable (attempt 2) On 06-08-12 09:04, Klaus Schmidinger wrote: It's been rather quiet on the VDR mailing list lately, but I guess everybody (like myself) is enjoying the summer and engaged in outdoor activities... 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] [PATCH] Make RGYB buttons customizable
Ages ago (2012-09-16 04:05) I wrote a patch against VDR 1.6. There was some
discussion about this subject but died away without anything really.
I rewrote the patch against current git (1.7.29) so should be applyable.
VDR currently assumes all remote controls have the same order of buttons.
This is not always the case. This patch allows you to change the order
of buttons in the UI.
This feature obviously only works on patched skins. Classic, lcars and
sttng skins are patched. Unpatched skins will remain to work fine, but
will ignore button order. Patching of the skin takes very minimum effort.
config.*: Load/Save Button information
menu.c : Add button selection to the UI
skin*.c : Use button order from the config file
Signed-off-by: Oliver Schinagl oli...@schinagl.nl
---
config.c | 12
config.h |4
menu.c|9 +
skinclassic.c | 11 +++
skinlcars.c | 19 +++
skinsttng.c | 11 +++
6 files changed, 50 insertions(+), 16 deletions(-)
diff --git a/config.c b/config.c
index 56454df..165bcee 100644
--- a/config.c
+++ b/config.c
@@ -424,6 +424,10 @@ cSetup::cSetup(void)
UseDolbyDigital = 1;
ChannelInfoPos = 0;
ChannelInfoTime = 5;
+ Button0 = 0;
+ Button1 = 1;
+ Button2 = 2;
+ Button3 = 3;
OSDLeftP = 0.03;
OSDTopP = 0.03;
OSDWidthP = 0.93;
@@ -620,6 +624,10 @@ bool cSetup::Parse(const char *Name, const char *Value)
else if (!strcasecmp(Name, UseDolbyDigital)) UseDolbyDigital=
atoi(Value);
else if (!strcasecmp(Name, ChannelInfoPos)) ChannelInfoPos =
atoi(Value);
else if (!strcasecmp(Name, ChannelInfoTime)) ChannelInfoTime=
atoi(Value);
+ else if (!strcasecmp(Name, Button0)) Button0=
atoi(Value);
+ else if (!strcasecmp(Name, Button1)) Button1=
atoi(Value);
+ else if (!strcasecmp(Name, Button2)) Button2=
atoi(Value);
+ else if (!strcasecmp(Name, Button3)) Button3=
atoi(Value);
else if (!strcasecmp(Name, OSDLeftP))OSDLeftP =
atof(Value);
else if (!strcasecmp(Name, OSDTopP)) OSDTopP=
atof(Value);
else if (!strcasecmp(Name, OSDWidthP)) { OSDWidthP =
atof(Value); ChkDoublePlausibility(OSDWidthP, 0.87); }
@@ -719,6 +727,10 @@ bool cSetup::Save(void)
Store(UseDolbyDigital,UseDolbyDigital);
Store(ChannelInfoPos, ChannelInfoPos);
Store(ChannelInfoTime,ChannelInfoTime);
+ Store(Button0,Button0);
+ Store(Button1,Button1);
+ Store(Button2,Button2);
+ Store(Button3,Button3);
Store(OSDLeftP, OSDLeftP);
Store(OSDTopP,OSDTopP);
Store(OSDWidthP, OSDWidthP);
diff --git a/config.h b/config.h
index acdf77a..3dd86ae 100644
--- a/config.h
+++ b/config.h
@@ -294,6 +294,10 @@ public:
int UseDolbyDigital;
int ChannelInfoPos;
int ChannelInfoTime;
+ int Button0;
+ int Button1;
+ int Button2;
+ int Button3;
double OSDLeftP, OSDTopP, OSDWidthP, OSDHeightP;
int OSDLeft, OSDTop, OSDWidth, OSDHeight;
double OSDAspect;
diff --git a/menu.c b/menu.c
index 9f4c54e..d7bce03 100644
--- a/menu.c
+++ b/menu.c
@@ -2510,6 +2510,7 @@ void cMenuSetupBase::Store(void)
class cMenuSetupOSD : public cMenuSetupBase {
private:
const char *useSmallFontTexts[3];
+ const char *buttonColorTexts[4];
int osdLanguageIndex;
int numSkins;
int originalSkinIndex;
@@ -2560,12 +2561,20 @@ void cMenuSetupOSD::Set(void)
useSmallFontTexts[0] = tr(never);
useSmallFontTexts[1] = tr(skin dependent);
useSmallFontTexts[2] = tr(always);
+ buttonColorTexts[0] = tr(Key$Red);
+ buttonColorTexts[1] = tr(Key$Green);
+ buttonColorTexts[2] = tr(Key$Yellow);
+ buttonColorTexts[3] = tr(Key$Blue);
Clear();
SetSection(tr(OSD));
Add(new cMenuEditStraItem(tr(Setup.OSD$Language),
osdLanguageIndex, I18nNumLanguagesWithLocale(), I18nLanguages()-At(0)));
Add(new cMenuEditStraItem(tr(Setup.OSD$Skin),
skinIndex, numSkins, skinDescriptions));
if (themes.NumThemes())
Add(new cMenuEditStraItem(tr(Setup.OSD$Theme),
themeIndex, themes.NumThemes(), themes.Descriptions()));
+ Add(new cMenuEditStraItem(tr(Setup.OSD$Button0),
data.Button0, 4, buttonColorTexts));
+ Add(new cMenuEditStraItem(tr(Setup.OSD$Button0),
data.Button1, 4, buttonColorTexts));
+ Add(new cMenuEditStraItem(tr(Setup.OSD$Button0),
data.Button2, 4, buttonColorTexts));
+ Add(new cMenuEditStraItem(tr(Setup.OSD$Button0),
data.Button3, 4, buttonColorTexts));
Add(new cMenuEditPrcItem( tr(Setup.OSD$Left (%)),
data.OSDLeftP, 0.0, 0.5));
Add(new cMenuEditPrcItem( tr(Setup.OSD$Top (%)),
data.OSDTopP, 0.0, 0.5));
Add(new cMenuEditPrcItem( tr(Setup.OSD$Width
Re: [vdr] Patch suggestion: Force CAM reset before upcoming recording
On 29-02-12 16:39, Klaus Schmidinger wrote:
On 29.02.2012 12:44, Kende wrote:
On Wed, Feb 29, 2012 at 12:18:00PM +0100, Klaus Schmidinger wrote:
On 29.02.2012 12:13, Heikki Manninen wrote:
I have a number of different Conax CAM modules from different
manufacturers and all of them disappear from VDR after a couple of
days running. Hitting CAM reset on the CI menu will bring it back
online. Naturally all Conax channel recordings will fail silently
as a result of this until the CAM has been brought back up.
Switching to an encrypted channel just gives the standard channel
not available message.
This happens (for me) with Satelco DVB-C card with Satelco CI. From
what I understand, this seems to be a common problem though I'm not
sure whether it is limited to Satelco devices only.
Would it be possible to force CAM reset on all CI slots when VDR is
trying to start recording non-FTA channel?
Wouldn't it be better to fix the actual problem and prevent
the CAM from disappearing?
Hola,
For me this seems to be driver issue, not VDRs fault. CI poll ioctl
write seems to fail sometimes with my KNC One (saa7146) budget cards
. Following patch seems to help in my case:
--- dvbci.c 2007-01-04 14:49:10.0 +0200
+++ ../vdr-1.7.21/dvbci.c 2011-10-12 10:49:45.689684447 +0300
@@ -62,8 +62,10 @@
void cDvbCiAdapter::Write(const uint8_t *Buffer, int Length)
{
if (Buffer Length 0) {
- if (safe_write(fd, Buffer, Length) != Length)
+if (safe_write(fd, Buffer, Length) != Length) {
esyslog(ERROR: can't write to CI adapter on device %d:
%m, device-De
viceNumber());
+ Reset(device-DeviceNumber());
+}
}
}
I tried this, but I'm afraid it doesn't help.
The Reset() call was never triggered, even though my CAM went from normal
operation to the CAM ready state, and not even an explicit reset via
the Setup/CAM menu brought it to life again. Only after reloading the
driver and restarting VDR did it work again.
My theory is that switching channels is what's causing the problem.
YES! I have so far only experienced this issue when switching channels.
Staying on the same channel hasn't ever caused any problems. Changing
channels causes various things, one being the cam needing to be reset.
When I trigger an EPG scan, the problem typically occurs after a while.
Maybe it's caused by tuning to channels that are no longer available,
so the frontend times out. However, there's no reason why a frontend
timeout should lead to a CAM freeze...
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
Re: [vdr] [Patch] Make RGYB buttons customizeable
Not wanting to throw any oil on this fire, or make things worse, I still don't see any mention of an order for these keys. Not even all colors are defined. A quote from the site you linked: other keys marked in various colours (e.g.: red, green, yellow, blue) Various colors, meaning there's no limit to the amount of colors. E.g. meaning, for example red, green, yellow and blue. It doesn't state 'only red green yellow and blue, in this order' Actually, the whole point of TOP teletekst using colors and not order was that order did not matter. Hence even big name manufactures of big name remotes (Logitech, Sony as mentioned here, my iMon that came with my silverstone case as menitoned by me, and it even has purple as mentioned by someone else which also falls under the category 'various colours') don't always use this specific order and layout. Anyway, I wrote a simple patch to solve this issue 4 months ago, and was simple asking for a review. So I'll simply re-send that mail and we can all move on and get a long :) On 04/05/11 00:33, fnu wrote: === Your theory that the RGYB color scheme is a worldwide standard with only cheap obscure non-media remotes being 'non-compliant' has already been thrown out the window. I don't know why you think pasting a link to an Italian website can somehow resurrect the dead theory. Btw, no link you ever paste will outweigh what color scheme people see on their physical remotes. If you want to argue about it further then contact Panasonic, Sony, and your friends at Logitech to start with. === Well, that's a claim. It's not just any italian URL, this is the main page of the inventor and license holder for TOP Teletext. This is the company where all manufacturer do pay their license fees to, if their TV set do provide this function. The invention of T(able) O(f) P(ages) Teletext brought us the colored keys on TV remotes 25 years ago, not surprisingly in the order R(ed) G(reen) Y(ellow) B(lue). Fifteen years later, Klaus adopt these common keys and standardized this order, RGYB, for his awesome and incredible solution VDR, as they are anywhere available, except on some trashy ones ... Regards fnu ___ 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] [Patch] Make RGYB buttons customizeable
Hey all,
Ever had the trouble that your remote's color navigation key weren't the
same as VDR's? Well I wrote this patch the past 4 hours which lets you
configure them.
By doing so, the order of the buttons in the menu changes depending on
whatever you tell it to. So finally that remote can match whatever is
displayed on screen.
This only works for the classic and st-tng skins, as those are supplied
with VDR. The Skin needs to support this feature. If there is no skin
support, the setting simply gets ignored by that skin. Since only the
order of the buttons in the skin are being changed any plugin
configuration will be independent from this change. What I mean is that,
when a plugin has configured blue to take you straight to the photo
gallery, the blue button will still do this, no matter where it is on
the remote. If the plugin however used the blue key to fast forward,
because it is the right most key, and thus made sense logically there,
it will no longer when you move the keys around. Practically, this will
boil down to a handful of plugins depending on location which imo is a
little weird anyway :)
Also, I patched it on a Gentoo box using the latest 1.6 ebuild they have
so line numbers may be a little off in the patch due to various patches
Gentoo may apply. It's the only dev. box for VDR I have so forgive me on
that.
I'm looking forward to the review :)
Oliver
diff -ru config.c.orig config.c
--- config.c.orig 2010-09-16 03:34:59.0 +0200
+++ config.c 2010-09-16 03:35:36.0 +0200
@@ -218,6 +218,10 @@
strcpy(OSDLanguage, ); // default is taken from environment
strcpy(OSDSkin, sttng);
strcpy(OSDTheme, default);
+ Button0 = 0;
+ Button1 = 1;
+ Button2 = 2;
+ Button3 = 3;
PrimaryDVB = 1;
ShowInfoOnChSwitch = 1;
TimeoutRequChInfo = 1;
@@ -417,6 +421,10 @@
if (!strcasecmp(Name, OSDLanguage)) { strn0cpy(OSDLanguage, Value, sizeof(OSDLanguage)); I18nSetLocale(OSDLanguage); }
else if (!strcasecmp(Name, OSDSkin)) Utf8Strn0Cpy(OSDSkin, Value, MaxSkinName);
else if (!strcasecmp(Name, OSDTheme))Utf8Strn0Cpy(OSDTheme, Value, MaxThemeName);
+ else if (!strcasecmp(Name, Button0)) Button0= atoi(Value);
+ else if (!strcasecmp(Name, Button1)) Button1= atoi(Value);
+ else if (!strcasecmp(Name, Button2)) Button2= atoi(Value);
+ else if (!strcasecmp(Name, Button3)) Button3= atoi(Value);
else if (!strcasecmp(Name, PrimaryDVB)) PrimaryDVB = atoi(Value);
else if (!strcasecmp(Name, ShowInfoOnChSwitch)) ShowInfoOnChSwitch = atoi(Value);
else if (!strcasecmp(Name, TimeoutRequChInfo)) TimeoutRequChInfo = atoi(Value);
@@ -524,6 +532,10 @@
Store(OSDLanguage,OSDLanguage);
Store(OSDSkin,OSDSkin);
Store(OSDTheme, OSDTheme);
+ Store(Button0,Button0);
+ Store(Button1,Button1);
+ Store(Button2,Button2);
+ Store(Button3,Button3);
Store(PrimaryDVB, PrimaryDVB);
Store(ShowInfoOnChSwitch, ShowInfoOnChSwitch);
Store(TimeoutRequChInfo, TimeoutRequChInfo);
diff -ru config.h.orig config.h ~/Desktop/config.h.diff
--- config.h.orig 2010-09-16 03:34:39.0 +0200
+++ config.h 2010-09-16 03:35:38.0 +0200
@@ -219,6 +219,10 @@
char OSDLanguage[I18N_MAX_LOCALE_LEN];
char OSDSkin[MaxSkinName];
char OSDTheme[MaxThemeName];
+ int Button0;
+ int Button1;
+ int Button2;
+ int Button3;
int PrimaryDVB;
int ShowInfoOnChSwitch;
int TimeoutRequChInfo;
diff -ru menu.c.orig menu.c
--- menu.c.orig 2010-09-16 03:34:44.0 +0200
+++ menu.c 2010-09-16 03:35:36.0 +0200
@@ -2422,6 +2422,7 @@
const char *useSmallFontTexts[3];
const char *mainMenuTitle[MAXMAINMENUTITLE];
int osdLanguageIndex;
+ const char *buttonColorTexts[4];
int numSkins;
int originalSkinIndex;
int skinIndex;
@@ -2475,12 +2476,20 @@
mainMenuTitle[1]=tr(VDR - text);
mainMenuTitle[2]=tr(text);
mainMenuTitle[3]=tr(VDR - version);
+ buttonColorTexts[0]=tr(Key$Red);
+ buttonColorTexts[1]=tr(Key$Green);
+ buttonColorTexts[2]=tr(Key$Yellow);
+ buttonColorTexts[3]=tr(Key$Blue);
Clear();
SetSection(tr(OSD));
Add(new cMenuEditStraItem(tr(Setup.OSD$Language), osdLanguageIndex, I18nNumLanguagesWithLocale(), I18nLanguages()-At(0)));
Add(new cMenuEditStraItem(tr(Setup.OSD$Skin), skinIndex, numSkins, skinDescriptions));
if (themes.NumThemes())
Add(new cMenuEditStraItem(tr(Setup.OSD$Theme), themeIndex, themes.NumThemes(), themes.Descriptions()));
+ Add(new cMenuEditStraItem(tr(Setup.OSD$Button0),data.Button0, 4, buttonColorTexts));
+ Add(new cMenuEditStraItem(tr(Setup.OSD$Button1),data.Button1, 4, buttonColorTexts));
+ Add(new cMenuEditStraItem(tr(Setup.OSD$Button2),data.Button2, 4,
Re: [vdr] [Patch] Make RGYB buttons customizeable
Ah, I use a lirc based remote and don't learn anything. I've just told VDR, that my VDR_RED is LIRC_RED etc, so when I press the red button, the action that is bound to VDR_RED is executed, regardless of the location of the button. This patch only changes the OSD location of the button, to match the location on the remote. On 03/31/11 15:40, Rainer Blickle wrote: 2011/3/30 Steffen Barszus steffenbpu...@googlemail.com: 2011/3/30 Oliver Schinagl oli...@schinagl.nl: I belive that is exactly only what this patch does, it changes the positions on the screen for the ST-NG theme I think (it's been a while I admit). So if VDR is told that the red button performs the job of the red button, then everything is ok. To recap, the problem I had with VDR that caused me to write this patch, was: My Remote control had 2 buttons different from where VDR expected the buttons to be. E.g. VDR wants Red Yellow Green Blue, but my remote control was Red Yellow Blue Green. My remote has the color order Yellow, Red, Blue, Green (only an example, i dont have the remote at hand). Lets say the buttons are Button0, Button1, Button2, Button3 When learning, vdr wants the keys Red,Yellow, Green, Blue to get pressed. In the vdr layout Button0 is Red, Button1 is Yellow and so on ... while watching a recording vdr jumps 1 minute in the past when pressing yellow and one minute in the future when pressing green. These are the middle color buttons. I also wanted to have this functionality in the middle buttons (on the buttons 1 and 2). So i pressed the Buttons Yellow, Red, Blue, Green while learning Red,Yellow, Green, Blue. Then i have the jumping +/-1 Minute functionality still on the middle color buttons. The only thing left is that the color on the osd has to be adjusted, but not the positions of the text on it. If have dont this by modifying your patch (the texts for -DrawText are taken directly from the parameters, not from the mapping). My (and perhaps only my) opinion is that vdr should request the leftmost color button, then the color right next to it (and so on) while learning. The color displayed in the osd should be assigned via the setup menu. @Klaus: If there is a change to integrate this into the vdr, i would provide a patch for it. So in the end, this patch works for you and does what you want? Or is your remote layed out as VDR expects it? I would say better patch your remote. A sharp knife and a screwdriver might be quite effective and will fix the problem also for the next vdr releases ^^ This would be a real good solution, but i dont want to void my warranty :-) SCNR Steffen ___ 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 mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [Patch] Make RGYB buttons customizeable
I actually wrote the patch and posted it on this list, about 4? months ago. It was maybe 20 lines total? It is a realyl small patch. And so far, I have not found 99.999% to follow the same coloring standard at all actually. Personally, I wasn't aware that the order of buttons was standarized on remotes (I could agree that most teletekst screens would be identical). On 04/01/11 12:13, fnu wrote: My remote has the color order Yellow, Red, Blue, Green (only an example, i dont have the remote at hand). Lets say the buttons are Button0, Button1, Button2, Button3 My (and perhaps only my) opinion is that vdr should request the leftmost color button, then the color right next to it (and so on) while learning. The color displayed in the osd should be assigned via the setup menu. Are you seriously asking for a major change like this, just for your most propably unique remote control? The color order of the RGYB buttons is a common standard, defined for Teletext centuries ago. So, 99.999% of all remotes providing these keys do have this order. http://en.wikipedia.org/wiki/Teletext Regards fnu ___ 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] [Patch] Make RGYB buttons customizeable
I have a iMon remote control, which also doesn't use this 'standard' order ;) Additionally on my previous mail (I hit send by accident actually :p) I checked the wikipage, and i couldn't find any mention of color or colour in relation to the order of the buttons. Also searching for Yellow didn't result in a single hit, nor did RGYB. So I'm not so sure of this 'standard order for remotes' yet? On 04/01/11 14:54, Rainer Blickle wrote: Yes i do. But the request can be refused, of course. Why not asking. I have a hama MCE ir. Dont know how many people use this remote. 2011/4/1 fnu v...@auktion.hostingkunde.de: My remote has the color order Yellow, Red, Blue, Green (only an example, i dont have the remote at hand). Lets say the buttons are Button0, Button1, Button2, Button3 My (and perhaps only my) opinion is that vdr should request the leftmost color button, then the color right next to it (and so on) while learning. The color displayed in the osd should be assigned via the setup menu. Are you seriously asking for a major change like this, just for your most propably unique remote control? The color order of the RGYB buttons is a common standard, defined for Teletext centuries ago. So, 99.999% of all remotes providing these keys do have this order. http://en.wikipedia.org/wiki/Teletext Regards fnu ___ 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 mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [Patch] Make RGYB buttons customizeable
I belive that is exactly only what this patch does, it changes the positions on the screen for the ST-NG theme I think (it's been a while I admit). So if VDR is told that the red button performs the job of the red button, then everything is ok. To recap, the problem I had with VDR that caused me to write this patch, was: My Remote control had 2 buttons different from where VDR expected the buttons to be. E.g. VDR wants Red Yellow Green Blue, but my remote control was Red Yellow Blue Green. So in the end, this patch works for you and does what you want? Or is your remote layed out as VDR expects it? On 03/30/11 13:39, Rainer Blickle wrote: Sorry for the noise, because: when learning lirc i havn't pressed the colors vdr wanted to be pressed, i pressed them from left to right. Afterwards, when switching the colors of the on-screen buttons, i thought only the color but not the positions of the on screen buttons get changed. When pressing the correct color buttons while learning, everything is ok. But i don't want this because then jumping +/- 1 minute while watching a recording are not on the middle color keys. All i would like to have is that only the color on the on-screen buttons changes. 2011/3/29 Rainer Blickle rainer.blic...@googlemail.com: I will take a look on it 2011/3/29 Oliver Schinagl oli...@schinagl.nl: I've never heard of that plugin before, and don't have it as such, so no idea how it goes wrong. Can you more closely describe how it goes wrong? From the description, I think they implement their own additional 'skin' and thus the plugin would have to be ported aswel. On 03/29/11 10:00, Rainer Blickle wrote: I've tried the patch and it worked at the first glance. But with the plugin Extrecmenu there are problems with the color keys. So i rolled back the patch. 2010/10/19 VDR User user@gmail.com: On Tue, Oct 19, 2010 at 12:16 AM, Oliver Schinagl oli...@schinagl.nl wrote: Nobody has any comment at all? :) I haven't found an issue as of yet running this for weeks now on my own VDR. I must say, it is nice to have the color order of the buttons match my remote :) The color arrangement already matches all of my remotes so I don't have any use for it. However, because I think it's useful to other users since a lot of remotes have a different color order, I'll help test it if you provide a VDR-1.7.16 compatible patch. That's my only condition as I'm not willing to downgrade my VDR boxes for this. If your patch made it into VDR and there are any plugins which use position to relate functions as you described (for example, right most key=ffwd) then maybe there also needs to be some mechanism for plugins to know which key is where (if there isn't one already). After VDR has been programmed for red/green/blue/yellow keys, then it can associate something like color1/color2/color3/color4 to the color order. Another thought is that VDR is supposed to get a truecolor OSD upgrade so we'll finally be able to have a great looking (HD) interface to use VDR with. Maybe the functionality of your patch is something Klaus has already considered during that upgrade. That's only speculation however but worth asking I think. Regards. ___ 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 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 mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [Patch] Make RGYB buttons customizeable
I've never heard of that plugin before, and don't have it as such, so no idea how it goes wrong. Can you more closely describe how it goes wrong? From the description, I think they implement their own additional 'skin' and thus the plugin would have to be ported aswel. On 03/29/11 10:00, Rainer Blickle wrote: I've tried the patch and it worked at the first glance. But with the plugin Extrecmenu there are problems with the color keys. So i rolled back the patch. 2010/10/19 VDR User user@gmail.com: On Tue, Oct 19, 2010 at 12:16 AM, Oliver Schinagl oli...@schinagl.nl wrote: Nobody has any comment at all? :) I haven't found an issue as of yet running this for weeks now on my own VDR. I must say, it is nice to have the color order of the buttons match my remote :) The color arrangement already matches all of my remotes so I don't have any use for it. However, because I think it's useful to other users since a lot of remotes have a different color order, I'll help test it if you provide a VDR-1.7.16 compatible patch. That's my only condition as I'm not willing to downgrade my VDR boxes for this. If your patch made it into VDR and there are any plugins which use position to relate functions as you described (for example, right most key=ffwd) then maybe there also needs to be some mechanism for plugins to know which key is where (if there isn't one already). After VDR has been programmed for red/green/blue/yellow keys, then it can associate something like color1/color2/color3/color4 to the color order. Another thought is that VDR is supposed to get a truecolor OSD upgrade so we'll finally be able to have a great looking (HD) interface to use VDR with. Maybe the functionality of your patch is something Klaus has already considered during that upgrade. That's only speculation however but worth asking I think. Regards. ___ 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 mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-sxfe open hug OSD
And the reason why I hadn't tried those: vdr-sxfe: option '--hud' doesn't allow an argument vdr-sxfe: unrecognized option '--opengl' So I come back to the fact, that I can get -hud (guessing on opengl) working when starting everything from a termina, X; wm; vdr, but when i start it from .xinitrc, VDR just goes black, and nothing works. On 02/01/11 08:38, Oliver Schinagl wrote: --hud=opengl --opengl ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-sxfe open hug OSD
* media-plugins/vdr-xineliboutput Latest version available: 1.0.5-r1 Latest version installed: 1.0.5-r1 is the version i'm havinga vailable to me on gentoo :) On 02/01/11 20:54, Niko Mikkilä wrote: On 2011-02-01 19:48 +0100, Oliver Schinagl wrote: And the reason why I hadn't tried those: vdr-sxfe: option '--hud' doesn't allow an argument vdr-sxfe: unrecognized option '--opengl' Then you have an old version of Xineliboutput. What does vdr-sxfe -h say about the options? For example, I'm using the yaVDR-packaged version, which is probably two or three weeks older than rofa's CVS build, and it has these switches: -D, --hudHead Up Display OSD mode using compositing -Q, --opengl-always Always use OpenGL for video and Head Up Display OSD -O, --opengl-hud Head Up Display OSD mode using OpenGL Since SourceForge's CVS servers are still down, it may be a bit tricky to get the latest and greatest version. -- Niko ___ 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] vdr-sxfe open hug OSD
I'm still having trouble getting this all working. I used http://www.vdr-portal.de/board/thread.php?postid=818661 to get me through the setup, without avail. --opengl-all doesn't seem to be a valid option? Or I can't find anything about it. --hud works however. Firstly, what I did manage to get working. Starting from a bare terminal: X DISPLAY=:0.0 matchbox-window-manager (matchbox has a built in composite manager, making xcompmgr redundant) DISPLAY=:0.0 xsetroot -cursor emptycursor emptycursor vdr-sxfe --verbose xvdr://127.0.0.1 --video=xv --audio=alsa --aspect=16:9 --lirc --fullscreen --hud 2 ~/output.log This works, with the only exception that the OSD is a small and only in the left quarter of the screen. Acceptable even I suppose, though ideally a centered OSD would be nice. I read on the forum topic that others had the same problem, but never clearly found a solution. So I then decided to move this to my .xinitrc; matchbox-window-manager vdr-sxfe --verbose xvdr://127.0.0.1 --video=xv --audio=alsa --aspect=16:9 --lirc --fullscreen --hud 2 ~/output.log (I have tried it with and without xcompmgr inbetween/before there too, doesn't matter) Now, the X server starts, matchbox starts, vdr-sxfe seems to start without error, but I only get a black screen. No sound, no response to input. adding aterm -e infront of vdr-sxfe makes vdr-sxfe start normally again, but not in an opengl window. changing my .bashrc to load as from the bare terminal (e.g. just start X ). I tried several plenty of other combinations, but I just can't get it to work :S would have been loads easier if vdr-sxfe would simply act as the most minimalistic window manager by itself and create the hud window itself. Anybody got any idea's where to take it from here? On 01/13/11 18:09, Oliver Schinagl wrote: On 01/13/11 15:46, Gerald Dachs wrote: On 01/13/11 13:31, Rolf Ahrenberg wrote: On Wed, 12 Jan 2011, VDR User wrote: And you get VDR's full osd doing this? FYI, xineliboutput provides three different OSD implementations: xinelib, composite HUD, and opengl HUD. For example the composite HUD OSD is drawn directly onto transparent window located exactly over the (xine-lib powered) video window and therefore is completely independent from the actual video decoding library. I'm curious as to how you got the composite and opengl HUD's working, I have been far from successful. It appears to just not work at all :S Both are working. You need a compositing manager like xcompmgr or compiz for the first possibility, or the option --opengl-all (not sure about correct typing for the second possibility. i'll try --opengl-all then; i have xcompmgr installed, i do have a very bare install however, i use aterm -e to launch the client, with aterm being my 'window manager'. Gerald ___ 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 mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-sxfe open hug OSD
On 01/31/11 20:45, Rolf Ahrenberg wrote: On Mon, 31 Jan 2011, Oliver Schinagl wrote: I'm still having trouble getting this all working. I used http://www.vdr-portal.de/board/thread.php?postid=818661 to get me through the setup, without avail. --opengl-all doesn't seem to be a valid option? Or I can't find anything about it. --hud works however. $ vdr-sxfe --help vdr-sxfe 1.0.90-cvs (build with xine-lib 1.1.90, using xine-lib 1.1.90) snip -D, --hud[=flag[,flag]] Head Up Display OSD mode using compositing flags: xshape Use XShape instead of compositing opengl Use OpenGL instead of compositing -O, --openglUse OpenGL for video and Head Up Display OSD snip -- vdr-sxfe --hud vdr-sxfe --hud=xshape vdr-sxfe --hud=opengl vdr-sxfe --hud=opengl --opengl but no --opengl-all I will shamefully admit that I forgot to revisit those options and check those out. would have been loads easier if vdr-sxfe would simply act as the most minimalistic window manager by itself and create the hud window itself. Patches are always welcome. I'm still using an older 1.6 package, once I'll get a 1.7 snapshot going, i'll work on it BR, -- rofa ___ 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] Remote receiver options...
I have an Silverstone LC16M which came preinstalled with a USB Imon pad i think it's called and I too replaced my homebuild serial LIRC device. It actually works better, in the sense that it can actually power on/off my pc from standby which was a big plus for me. (The serial version would have been able to pull that off to in the end, as there was options for this sorta) On 01/25/11 10:53, Laz wrote: I've been following various threads over the past year or so exploring various options for having a server-client vdr setup and it got me thinking. I'm currently using a home-brew LIRC receiver attached to a serial port which works perfectly. The ION-based boards look very nice as a vdr front end (using xinelibout or some yet-to-be-written plugin!) because they can do hardware HD decoding. However, I suspect a lot of these lack a serial port so my simple LIRC receiver would be no good. What are others doing in this sort of situation? USB-based receiver (there are a couple described at lirc.org), or do most of the ION boards still have a serial header (must admit, not looked into this properly yet!)? Several DVB devices do contain receivers but that pretty much defeats the object of having a server containing DVB devices and a client just for viewing. It all looks nice in principle but any lack of a remote is a deal breaker! Cheers, Laz ___ 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] Developer versions
On 01/13/11 15:46, Gerald Dachs wrote: On 01/13/11 13:31, Rolf Ahrenberg wrote: On Wed, 12 Jan 2011, VDR User wrote: And you get VDR's full osd doing this? FYI, xineliboutput provides three different OSD implementations: xinelib, composite HUD, and opengl HUD. For example the composite HUD OSD is drawn directly onto transparent window located exactly over the (xine-lib powered) video window and therefore is completely independent from the actual video decoding library. I'm curious as to how you got the composite and opengl HUD's working, I have been far from successful. It appears to just not work at all :S Both are working. You need a compositing manager like xcompmgr or compiz for the first possibility, or the option --opengl-all (not sure about correct typing for the second possibility. i'll try --opengl-all then; i have xcompmgr installed, i do have a very bare install however, i use aterm -e to launch the client, with aterm being my 'window manager'. Gerald ___ 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] dvbscan vs builtin update generates double entries.
On 19.12.2010 02:46, Oliver Schinagl wrote: I have created a channel.conf from dvbscan and used the built update function from VDR. All channels seem to be added/modified properly, but the FTA channels are different. Instead of modifying my current entry, it created new ones. Nederland 1;Digitenne:54600:C12D12M64B8T8G4Y0:T:27500::::0:1101:8720:2214:0 Nederland 1;Digitenne:54600:C12D12M64B8T8G4Y0:T:27500:7011:7012:7013:0:1101:8720:2211:0 Nederland 2;Digitenne:54600:C12D12M64B8T8G4Y0:T:27500::::0:1102:8720:2214:0 Nederland 2;Digitenne:54600:C12D12M64B8T8G4Y0:T:27500:7021:7022:7023:0:1102:8720:2211:0 Nederland 3;Digitenne:54600:C12D12M64B8T8G4Y0:T:27500::::0:1103:8720:2214:0 Nederland 3;Digitenne:54600:C12D12M64B8T8G4Y0:T:27500:7031:7032:7033:0:1103:8720:2211:0 I took the liberty of expanding the VID, AID and TID from 0 to so they'd align better in this e-mail only. All entries work however! Which baffles me. How can something without vid/aid work at all? Also, it seems that the 'proper' entry doesn't display EPG data at all. Ironically, the scrambled channels all seem to work just fine. Any clues on this? The channels with zero PIDs have a TID (Transport stream ID) of 2214, ehile those with actual PIDs have 2211. Only one of these can be right, I guess. Yip, I changed the TID to 2214 to get both epg info and not have VDR re-add it over and over again. Question remains, why does dvbscan and vdr-backgroundscanner find different TID's :S 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
Re: [vdr] CAM auto resetting - feature request??
On 12/25/10 09:48, Halim Sahin wrote: Hello, On Thu, Dec 23, 2010 at 09:59:19PM +0100, Oliver Schinagl wrote: so its nothing illegal, also you can use 1 smartcard on more than 1 dvb card, even CI-less cards. I don't think that it's legal in germany or in other countries. I don't think softcams are illegal, using cardsharing services is .. legally debatable, but a softcam, in combination with your own smartcard, should be legal. Please don't spam this thread with such suggestions. Hardly spam, just a suggestion/workaround to get a workable legal solution. And with all the CI-less hardware out there, from PCI cards to USB cards and even WinTV offering a cardreader only (I belive they might be using a softcam in their win-ware) this may be the only solution to some. The is a problem which can be reproduced by other vdr users as well so that should be fixed in core vdr. Is this problem only to VDR? or has anybody noticed this same behaviour with, say Myth or something else. Could it be a kernel bug? It seems/feels like the cam is crashing and that's why it needs to be reset, as sometimes the cam menu brings a 'CAM: -' message, indicating it isn't initialized any longer. Unrelated btw, I sometimes have a horribly A/V sync issue when changing encrypted channels. E.g. the video runs fine, but the audio is first missing, then slowly starts dripping in, kinda like how a torrents work, until after about 10 seconds all the sound runs smoothly. It only happens occasionally though ... very strange, but could be related. Suggesting these plugins will not help everyone. It very well may help people until this bug is solved. :( Btw, I'm not sure if I mentioned, but this is happening in VDR 1.6, and I belive Halim has it on 1.7? So it has been around for quite a while. I can try patches if needed, as it should be pretty straight forward applying them on Gentoo, but 1.6 would be prefered. BR. Halim ___ 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] CAM auto resetting - feature request??
On 12/23/10 04:48, Simon Baxter wrote: On 12/23/10 00:14, Simon Baxter wrote: hello Klaus, I tried the patch below with a knc1 dvb-c, tt c1500 and tt connect ct-3650 I used a alphacrypt light and I also tried the classic module always the same behavior - if I zap from encrypted channel to encrypted channel in some situations vdr says channel not available if I reset the cam manually it works again immediately I also tried vdr 1.4 with my old tt ff c2300 and I had no problems maybe its a general vdr 1.7.x cam handling problem any idea - what I can do or test to identify where the problem is? thanks I had assumed this was due to some problem with CAM keys from the provider expiring, or something. I still intermittantly get channel not available, but haven't found any way to recreate the problem at will. I have exactly this aswel. It happens from 'surfing channels'. Never happens while watching the same channel continuously. Cannot say for sure it doesn't happen when surfing within the same bouquet. I have multiple cards, 2x DVB-C+CAM, 2xDVB-S FTA. I sometimes get these messages when watching FTA too, when encrypted channels are recording and changing in the background. I also occasionally have a CAM crash - where the status in goes from ALPHACRYPT to CAM PRESENT or CAM READY. A manual reset (or multiple) fixes this, but I get no decryption during a crash. Yep, also this, only for Conax Conditional Acess. Resetting it works best when using an FTA channel it seems. ...problems I've had to live with for months. Gave up asking and installed an FTA satellite dish for 50% of my mostly watched channels. I'm looking at an oscam solution right now, but need to get a proper card reader, or try to get my old towitoko chipdrive going. Don't know anything about oscam... oscam is a softcam, it requires a smartcard reader and your smartcard, so its nothing illegal, also you can use 1 smartcard on more than 1 dvb card, even CI-less cards. ___ 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] CAM auto resetting - feature request??
On 12/23/10 00:14, Simon Baxter wrote: hello Klaus, I tried the patch below with a knc1 dvb-c, tt c1500 and tt connect ct-3650 I used a alphacrypt light and I also tried the classic module always the same behavior - if I zap from encrypted channel to encrypted channel in some situations vdr says channel not available if I reset the cam manually it works again immediately I also tried vdr 1.4 with my old tt ff c2300 and I had no problems maybe its a general vdr 1.7.x cam handling problem any idea - what I can do or test to identify where the problem is? thanks I had assumed this was due to some problem with CAM keys from the provider expiring, or something. I still intermittantly get channel not available, but haven't found any way to recreate the problem at will. I have exactly this aswel. It happens from 'surfing channels'. Never happens while watching the same channel continuously. Cannot say for sure it doesn't happen when surfing within the same bouquet. I also occasionally have a CAM crash - where the status in goes from ALPHACRYPT to CAM PRESENT or CAM READY. A manual reset (or multiple) fixes this, but I get no decryption during a crash. Yep, also this, only for Conax Conditional Acess. Resetting it works best when using an FTA channel it seems. ...problems I've had to live with for months. Gave up asking and installed an FTA satellite dish for 50% of my mostly watched channels. I'm looking at an oscam solution right now, but need to get a proper card reader, or try to get my old towitoko chipdrive going. ___ 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] Cam not decoding content (VDR 1.6 TT-1500 T CI PCI)
Having pulled out my hair so far over the weekend, I have figured out, that maybe, I need to change the ca field in channels.conf. After a scan from dvbscan, it is set to 0, which appearantly means fta. Changing it to 1 isn't a magical fix, but I think it is something that is needed? After this however, I am kinda stuck. There is hardly anything to be found on this subject and most/all info I find is about softcams and cardsharing. Nobody has any pointer in the right direction to get VDR working with a hardware cam? Thanks, Oliver On 12/17/10 22:21, Oliver Schinagl wrote: And this time, with the log actually attached. On 12/17/10 22:18, Oliver Schinagl wrote: Ok, i found that i get the debugging from running vdr and piping it output to a file. I removed the log serial numbers hopefully. I can't see anything wrong though, i changed from fta, to encrypted channels and back, also went through the cam menu while on the encrpyted channels. Do I need to do anything with channels.conf to let it know i have encrypted channels? I just piped the output from dvbscan to channels.conf ... oliver ___ 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] Cam not decoding content (VDR 1.6 TT-1500 T CI PCI)
Success! I removed the pvrinput plugin and set the update to add new transponders on. And after doing a new dvbscan vdr made it all worked. Incidently, my smartcard is properly updated now too (in the log, it said somewhere that the start/end dates was 1 jan 1990; those read reasonable values now. In any case, with pvrinput, i had the xineliboutput setup that the OSD was partially transparant and 'smooth'. Changing specific settings (cropping, overscanning etc) made the menu be non-transparant and extremly slow. Before, I _think_ my FTA channels worked that way too, but now, I can't seem to get the background to be transparant. I'm guessing I could remove my xineliboutput settings, but i'm sure there's an easier way? One other strange thing, in the DVB menu my dvb card is listed 2nd card. If i change it to first, all goes away again. I guess the easy way is to reset my config and start over :) (For the next few months, I might want to keep my PVR somewhere highup, channels 50+) Anyway! I checked what my channels.conf said, and my CA or CA-ID (caid) field was changed to B00. zap and i think my CAM menu mentioned that my cam was 0x0b00. So VDR entered my CA to the Cam id. Hopefully google will pick this up for anybody searching for this stuff sometime in the future :) On 12/18/10 22:18, Halim Sahin wrote: Hi, Try the following: set in menu-settings-dvb Update channels to add new transponders then press ok. Then set the ca field to unencrypted and switch to that channel in vdr. Vdr should detect the ca field and change the vallue. HTH. Halim Halim Sahin E-Mail: halim.sahin (at) t-online.de ___ 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] dvbscan vs builtin update generates double entries.
I have created a channel.conf from dvbscan and used the built update function from VDR. All channels seem to be added/modified properly, but the FTA channels are different. Instead of modifying my current entry, it created new ones. Nederland 1;Digitenne:54600:C12D12M64B8T8G4Y0:T:27500::::0:1101:8720:2214:0 Nederland 1;Digitenne:54600:C12D12M64B8T8G4Y0:T:27500:7011:7012:7013:0:1101:8720:2211:0 Nederland 2;Digitenne:54600:C12D12M64B8T8G4Y0:T:27500::::0:1102:8720:2214:0 Nederland 2;Digitenne:54600:C12D12M64B8T8G4Y0:T:27500:7021:7022:7023:0:1102:8720:2211:0 Nederland 3;Digitenne:54600:C12D12M64B8T8G4Y0:T:27500::::0:1103:8720:2214:0 Nederland 3;Digitenne:54600:C12D12M64B8T8G4Y0:T:27500:7031:7032:7033:0:1103:8720:2211:0 I took the liberty of expanding the VID, AID and TID from 0 to so they'd align better in this e-mail only. All entries work however! Which baffles me. How can something without vid/aid work at all? Also, it seems that the 'proper' entry doesn't display EPG data at all. Ironically, the scrambled channels all seem to work just fine. Any clues on this? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Cam not decoding content (VDR 1.6 TT-1500 T CI PCI)
Ok, i found that i get the debugging from running vdr and piping it output to a file. I removed the log serial numbers hopefully. I can't see anything wrong though, i changed from fta, to encrypted channels and back, also went through the cam menu while on the encrpyted channels. Do I need to do anything with channels.conf to let it know i have encrypted channels? I just piped the output from dvbscan to channels.conf ... oliver On 12/17/10 00:36, Oliver Schinagl wrote: I think it's working I got this from my cam in my message: Dec 17 00:24:01 erin vdr: [14866] CAM 1: Menu -- Dec 17 00:24:01 erin vdr: [14866] CAM 1: 'Conax Conditional Access' Dec 17 00:24:01 erin vdr: [14866] CAM 1: 'Main menu' Dec 17 00:24:01 erin vdr: [14866] CAM 1: 'Subscription status' Dec 17 00:24:01 erin vdr: [14866] CAM 1: 'Event status' Dec 17 00:24:01 erin vdr: [14866] CAM 1: 'Tokens status' Dec 17 00:24:01 erin vdr: [14866] CAM 1: 'Change CA PIN' Dec 17 00:24:01 erin vdr: [14866] CAM 1: 'Maturity Rating' Dec 17 00:24:01 erin vdr: [14866] CAM 1: 'Modem Ordering' Dec 17 00:24:01 erin vdr: [14866] CAM 1: 'About Conax CA' Dec 17 00:24:01 erin vdr: [14866] CAM 1: 'Message' Dec 17 00:24:01 erin vdr: [14866] CAM 1: 'Language' Dec 17 00:24:01 erin vdr: [14866] CAM 1: 'Loader status' Dec 17 00:24:01 erin vdr: [14866] CAM 1: 'Press 'OK' to select; Press 'EXIT' to return' Dec 17 00:24:02 erin vdr: [14866] max. latency time 3 seconds Dec 17 00:24:03 erin vdr: [14866] CAM 1: select 0 Dec 17 00:24:03 erin vdr: [14866] CAM 1: Menu -- Dec 17 00:24:03 erin vdr: [14866] CAM 1: 'Conax Conditional Access' Dec 17 00:24:03 erin vdr: [14866] CAM 1: 'Subscription status' Dec 17 00:24:03 erin vdr: [14866] CAM 1: 'Name: Digitenne ' Dec 17 00:24:03 erin vdr: [14866] CAM 1: 'Start date 01. Dec 2010 01. Jan 1990' Dec 17 00:24:03 erin vdr: [14866] CAM 1: 'End date 31. Dec 2010 01. Jan 1990' Dec 17 00:24:03 erin vdr: [14866] CAM 1: 'Entitlement 010b 01ff' Dec 17 00:24:03 erin vdr: [14866] CAM 1: 'The First Entitlement' Dec 17 00:24:03 erin vdr: [14866] CAM 1: 'The End Entitlement' Dec 17 00:24:03 erin vdr: [14866] CAM 1: 'OK - view subscription status' Dec 17 00:24:39 erin vdr: [15132] ERROR: no useful data seen within 10540220 byte of video stream Dec 17 00:27:48 erin vdr: [15132] PES packet shortened to 27080 bytes (expected: 53845 bytes) Dec 17 00:30:32 erin vdr: [14866] CAM 1: select 4 Dec 17 00:30:33 erin vdr: [14866] CAM 1: Menu -- Dec 17 00:30:33 erin vdr: [14866] CAM 1: 'Conax Conditional Access' Dec 17 00:30:33 erin vdr: [14866] CAM 1: 'Subscription status' Dec 17 00:30:33 erin vdr: [14866] CAM 1: 'Name: Digitenne ' Dec 17 00:30:33 erin vdr: [14866] CAM 1: 'Start date 01. Dec 2010 01. Jan 1990' Dec 17 00:30:33 erin vdr: [14866] CAM 1: 'End date 31. Dec 2010 01. Jan 1990' Dec 17 00:30:33 erin vdr: [14866] CAM 1: 'Entitlement 010b 01ff' Dec 17 00:30:33 erin vdr: [14866] CAM 1: 'The First Entitlement' Dec 17 00:30:33 erin vdr: [14866] CAM 1: 'The End Entitlement' Dec 17 00:30:33 erin vdr: [14866] CAM 1: 'OK - view subscription status' Dec 17 00:30:33 erin vdr: [14866] [xine..put] OSD bandwidth: 1077562 bytes/s (8418 kbit/s) Dec 17 00:30:34 erin vdr: [14866] CAM 1: Menu -- Dec 17 00:30:34 erin vdr: [14866] CAM 1: 'Conax Conditional Access' Dec 17 00:30:34 erin vdr: [14866] CAM 1: 'Main menu' Dec 17 00:30:34 erin vdr: [14866] CAM 1: 'Subscription status' Dec 17 00:30:34 erin vdr: [14866] CAM 1: 'Event status' Dec 17 00:30:34 erin vdr: [14866] CAM 1: 'Tokens status' Dec 17 00:30:34 erin vdr: [14866] CAM 1: 'Change CA PIN' Dec 17 00:30:34 erin vdr: [14866] CAM 1: 'Maturity Rating' Dec 17 00:30:34 erin vdr: [14866] CAM 1: 'Modem Ordering' Dec 17 00:30:34 erin vdr: [14866] CAM 1: 'About Conax CA' Dec 17 00:30:34 erin vdr: [14866] CAM 1: 'Message' Dec 17 00:30:34 erin vdr: [14866] CAM 1: 'Language' Dec 17 00:30:34 erin vdr: [14866] CAM 1: 'Loader status' Dec 17 00:30:34 erin vdr: [14866] CAM 1: 'Press 'OK' to select; Press 'EXIT' to return' Dec 17 00:30:35 erin vdr: [14866] [xine..put] OSD bandwidth: 918770 bytes/s (7177 kbit/s) Dec 17 00:30:35 erin vdr: [14866] CAM 1: select 1 Dec 17 00:30:36 erin vdr: [14866] CAM 1: Menu -- Dec 17 00:30:36 erin vdr: [14866] CAM 1: '' Dec 17 00:30:36 erin vdr: [14866] CAM 1: 'No Entitlement!' Dec 17 00:30:36 erin vdr: [14866] [xine..put] OSD bandwidth: 857737 bytes/s (6701 kbit/s) Dec 17 00:30:37 erin vdr: [14866] CAM 1: Menu -- Dec 17 00:30:37 erin vdr: [14866] CAM 1: 'Conax Conditional Access' Dec 17 00:30:37 erin vdr: [14866] CAM 1: 'Main menu' Dec 17 00:30:37 erin vdr: [14866] CAM 1: 'Subscription status' Dec 17 00:30:37 erin vdr: [14866] CAM 1: 'Event status' Dec 17 00:30:37 erin vdr: [14866] CAM 1: 'Tokens status' Dec 17 00:30:37 erin vdr: [14866] CAM 1: 'Change CA PIN' Dec 17 00:30:37
[vdr] Cam not decoding content (VDR 1.6 TT-1500 T CI PCI)
Hello all, I have recently purchased a TechnoTrend 1500 DVB-T PCI card with CI daughter board. I also have an official CAM and Smartcard for our local DVB-T service. The DVB-T in the air broadcasts 4 FtA channels and the rest encrypted. I can scan and find all the channels properly. Also watching FtA channels works without a problem. EPG I also receive for all channels in question. The CAM menu lists my cam properly (Conax 4.00e) and all information seems to be proper. I activated my smartcard via the phone this morning so that sh ould also not cause any problem. dmesg lists my cam as successfully initialized: Dec 16 16:19:11 erin kernel: [ 2771.999892] dvb_ca adapter 0: DVB CAM detected and initialised successfully I also have a ivtv based device in the box using the pvrinput plugin, but that shouldn't cause this? From the log I find the following after changing from channel 42 (FtA) to 64 (Scrambled) and back. Dec 16 17:58:55 erin vdr: [2756] switching to channel 42 Dec 16 17:58:55 erin vdr: [2884] transfer thread ended (pid=2756, tid=2884) Dec 16 17:58:55 erin vdr: [2756] buffer stats: 40232 (1%) used Dec 16 17:58:55 erin vdr: [2888] transfer thread started (pid=2756, tid=2888) Dec 16 17:58:55 erin vdr: [2887] osdteletext-receiver thread ended (pid=2756, tid=2887) Dec 16 17:58:55 erin vdr: [2756] buffer stats: 0 (0%) used Dec 16 17:58:55 erin vdr: [2889] osdteletext-receiver thread started (pid=2756, tid=2889) Dec 16 17:58:56 erin vdr: [2888] [xine..put] Detected video size 704x576 Dec 16 17:58:56 erin vdr: [2888] setting audio track to 1 (0) Dec 16 17:58:59 erin vdr: [2756] switching to channel 64 Dec 16 17:58:59 erin vdr: [2888] transfer thread ended (pid=2756, tid=2888) Dec 16 17:58:59 erin vdr: [2756] buffer stats: 75388 (3%) used Dec 16 17:58:59 erin vdr: [2889] osdteletext-receiver thread ended (pid=2756, tid=2889) Dec 16 17:58:59 erin vdr: [2890] transfer thread started (pid=2756, tid=2890) Dec 16 17:59:00 erin vdr: [2886] TS buffer on device 1 thread ended (pid=2756, tid=2886) Dec 16 17:59:00 erin vdr: [2885] buffer stats: 78960 (3%) used Dec 16 17:59:00 erin vdr: [2885] receiver on device 1 thread ended (pid=2756, tid=2885) Dec 16 17:59:00 erin vdr: [2891] receiver on device 1 thread started (pid=2756, tid=2891) Dec 16 17:59:00 erin vdr: [2756] buffer stats: 0 (0%) used Dec 16 17:59:00 erin vdr: [2756] creating directory /var/cache/osdteletext/T-8720-2213-32 Dec 16 17:59:00 erin vdr: [2893] TS buffer on device 1 thread started (pid=2756, tid=2893) Dec 16 17:59:00 erin vdr: [2892] osdteletext-receiver thread started (pid=2756, tid=2892) Dec 16 17:59:01 erin vdr: [2756] retuning due to modification of channel 64 Dec 16 17:59:01 erin vdr: [2756] switching to channel 64 Dec 16 17:59:01 erin vdr: [2890] transfer thread ended (pid=2756, tid=2890) Dec 16 17:59:01 erin vdr: [2756] buffer stats: 39480 (1%) used Dec 16 17:59:01 erin vdr: [2894] transfer thread started (pid=2756, tid=2894) Dec 16 17:59:04 erin vdr: [2756] switching to channel 42 any idea why the scrambled stream isn't being decoded? 00:0a.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) Subsystem: Technotrend Systemtechnik GmbH DVB T-1500 Flags: bus master, medium devsel, latency 32, IRQ 18 Memory at fc123000 (32-bit, non-prefetchable) [size=512] Kernel driver in use: budget_ci dvb Kernel modules: budget-ci Module Size Used by snd_pcm_oss26176 0 snd_mixer_oss 10616 1 snd_pcm_oss radeon620116 2 wm8775 2416 1 tuner 14720 2 cx2584023108 1 lirc_imon 19540 1 tda1004x 11484 1 ivtv 114436 1 ttm37408 1 radeon budget_ci 15716 16 drm_kms_helper 17912 1 radeon rc_hauppauge_new 984 0 lirc_dev8312 3 lirc_imon budget_core 5580 1 budget_ci saa714610336 2 budget_ci,budget_core cx2341x 8636 1 ivtv cfbcopyarea 2776 1 radeon imon 17728 0 cfbimgblt 1800 1 radeon tveeprom 12204 1 ivtv cfbfillrect 2664 1 radeon ttpci_eeprom1288 1 budget_core crw-rw+ 1 root video 212, 6 Dec 16 15:33 ca0 crw-rw+ 1 root video 212, 4 Dec 16 15:33 demux0 crw-rw+ 1 root video 212, 5 Dec 16 15:33 dvr0 crw-rw+ 1 root video 212, 3 Dec 16 15:33 frontend0 crw-rw+ 1 root video 212, 7 Dec 16 15:33 net0 Thanks, Oliver ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Cam not decoding content (VDR 1.6 TT-1500 T CI PCI)
I think this should be it with CI enabled in the source, any easy way I can check this on the binary? Dec 16 22:18:38 erin vdr: [14866] switching to channel 42 Dec 16 22:18:38 erin vdr: [15019] transfer thread ended (pid=14866, tid=15019) Dec 16 22:18:38 erin vdr: [14866] buffer stats: 2632 (0%) used Dec 16 22:18:38 erin vdr: [15022] transfer thread started (pid=14866, tid=15022) Dec 16 22:18:38 erin vdr: [15021] TS buffer on device 1 thread ended (pid=14866, tid=15021) Dec 16 22:18:38 erin vdr: [15020] buffer stats: 2256 (0%) used Dec 16 22:18:38 erin vdr: [15020] receiver on device 1 thread ended (pid=14866, tid=15020) Dec 16 22:18:38 erin vdr: [15023] receiver on device 1 thread started (pid=14866, tid=15023) Dec 16 22:18:38 erin vdr: [15024] TS buffer on device 1 thread started (pid=14866, tid=15024) Dec 16 22:18:38 erin vdr: [15025] osdteletext-receiver thread started (pid=14866, tid=15025) Dec 16 22:18:39 erin vdr: [15022] [xine..put] Detected video size 704x576 Dec 16 22:18:39 erin vdr: [15022] setting audio track to 1 (0) Dec 16 22:18:43 erin vdr: [14866] switching to channel 64 Dec 16 22:18:43 erin vdr: [15022] transfer thread ended (pid=14866, tid=15022) Dec 16 22:18:43 erin vdr: [14866] buffer stats: 49632 (2%) used Dec 16 22:18:43 erin vdr: [15025] osdteletext-receiver thread ended (pid=14866, tid=15025) Dec 16 22:18:43 erin vdr: [15026] transfer thread started (pid=14866, tid=15026) Dec 16 22:18:43 erin vdr: [15024] TS buffer on device 1 thread ended (pid=14866, tid=15024) Dec 16 22:18:43 erin vdr: [15023] buffer stats: 52828 (2%) used Dec 16 22:18:43 erin vdr: [15023] receiver on device 1 thread ended (pid=14866, tid=15023) Dec 16 22:18:43 erin vdr: [15027] receiver on device 1 thread started (pid=14866, tid=15027) Dec 16 22:18:43 erin vdr: [14866] buffer stats: 0 (0%) used Dec 16 22:18:43 erin vdr: [15028] TS buffer on device 1 thread started (pid=14866, tid=15028) Dec 16 22:18:43 erin vdr: [15029] osdteletext-receiver thread started (pid=14866, tid=15029) On 12/16/10 19:31, Simon Baxter wrote: Dec 16 17:58:55 erin vdr: [2756] switching to channel 42 Dec 16 17:58:55 erin vdr: [2884] transfer thread ended (pid=2756, tid=2884) Dec 16 17:58:55 erin vdr: [2756] buffer stats: 40232 (1%) used Dec 16 17:58:55 erin vdr: [2888] transfer thread started (pid=2756, tid=2888) Dec 16 17:58:55 erin vdr: [2887] osdteletext-receiver thread ended (pid=2756, tid=2887) Dec 16 17:58:55 erin vdr: [2756] buffer stats: 0 (0%) used Dec 16 17:58:55 erin vdr: [2889] osdteletext-receiver thread started (pid=2756, tid=2889) Dec 16 17:58:56 erin vdr: [2888] [xine..put] Detected video size 704x576 Dec 16 17:58:56 erin vdr: [2888] setting audio track to 1 (0) Dec 16 17:58:59 erin vdr: [2756] switching to channel 64 Dec 16 17:58:59 erin vdr: [2888] transfer thread ended (pid=2756, tid=2888) Dec 16 17:58:59 erin vdr: [2756] buffer stats: 75388 (3%) used Dec 16 17:58:59 erin vdr: [2889] osdteletext-receiver thread ended (pid=2756, tid=2889) Dec 16 17:58:59 erin vdr: [2890] transfer thread started (pid=2756, tid=2890) Dec 16 17:59:00 erin vdr: [2886] TS buffer on device 1 thread ended (pid=2756, tid=2886) Dec 16 17:59:00 erin vdr: [2885] buffer stats: 78960 (3%) used Dec 16 17:59:00 erin vdr: [2885] receiver on device 1 thread ended (pid=2756, tid=2885) Dec 16 17:59:00 erin vdr: [2891] receiver on device 1 thread started (pid=2756, tid=2891) Dec 16 17:59:00 erin vdr: [2756] buffer stats: 0 (0%) used Dec 16 17:59:00 erin vdr: [2756] creating directory /var/cache/osdteletext/T-8720-2213-32 Dec 16 17:59:00 erin vdr: [2893] TS buffer on device 1 thread started (pid=2756, tid=2893) Dec 16 17:59:00 erin vdr: [2892] osdteletext-receiver thread started (pid=2756, tid=2892) Dec 16 17:59:01 erin vdr: [2756] retuning due to modification of channel 64 Dec 16 17:59:01 erin vdr: [2756] switching to channel 64 Dec 16 17:59:01 erin vdr: [2890] transfer thread ended (pid=2756, tid=2890) Dec 16 17:59:01 erin vdr: [2756] buffer stats: 39480 (1%) used Dec 16 17:59:01 erin vdr: [2894] transfer thread started (pid=2756, tid=2894) Dec 16 17:59:04 erin vdr: [2756] switching to channel 42 any idea why the scrambled stream isn't being decoded? Have you tried turning on debugging in ci.c? // Set these to 'true' for debug output: static bool DumpTPDUDataTransfer = false; static bool DebugProtocol = false; static bool DumpPolls = false; static bool DumpDateTime = false; ___ 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] Cam not decoding content (VDR 1.6 TT-1500 T CI PCI)
I think it's working I got this from my cam in my message: Dec 17 00:24:01 erin vdr: [14866] CAM 1: Menu -- Dec 17 00:24:01 erin vdr: [14866] CAM 1: 'Conax Conditional Access' Dec 17 00:24:01 erin vdr: [14866] CAM 1: 'Main menu' Dec 17 00:24:01 erin vdr: [14866] CAM 1: 'Subscription status' Dec 17 00:24:01 erin vdr: [14866] CAM 1: 'Event status' Dec 17 00:24:01 erin vdr: [14866] CAM 1: 'Tokens status' Dec 17 00:24:01 erin vdr: [14866] CAM 1: 'Change CA PIN' Dec 17 00:24:01 erin vdr: [14866] CAM 1: 'Maturity Rating' Dec 17 00:24:01 erin vdr: [14866] CAM 1: 'Modem Ordering' Dec 17 00:24:01 erin vdr: [14866] CAM 1: 'About Conax CA' Dec 17 00:24:01 erin vdr: [14866] CAM 1: 'Message' Dec 17 00:24:01 erin vdr: [14866] CAM 1: 'Language' Dec 17 00:24:01 erin vdr: [14866] CAM 1: 'Loader status' Dec 17 00:24:01 erin vdr: [14866] CAM 1: 'Press 'OK' to select; Press 'EXIT' to return' Dec 17 00:24:02 erin vdr: [14866] max. latency time 3 seconds Dec 17 00:24:03 erin vdr: [14866] CAM 1: select 0 Dec 17 00:24:03 erin vdr: [14866] CAM 1: Menu -- Dec 17 00:24:03 erin vdr: [14866] CAM 1: 'Conax Conditional Access' Dec 17 00:24:03 erin vdr: [14866] CAM 1: 'Subscription status' Dec 17 00:24:03 erin vdr: [14866] CAM 1: 'Name: Digitenne ' Dec 17 00:24:03 erin vdr: [14866] CAM 1: 'Start date 01. Dec 2010 01. Jan 1990' Dec 17 00:24:03 erin vdr: [14866] CAM 1: 'End date 31. Dec 2010 01. Jan 1990' Dec 17 00:24:03 erin vdr: [14866] CAM 1: 'Entitlement 010b 01ff' Dec 17 00:24:03 erin vdr: [14866] CAM 1: 'The First Entitlement' Dec 17 00:24:03 erin vdr: [14866] CAM 1: 'The End Entitlement' Dec 17 00:24:03 erin vdr: [14866] CAM 1: 'OK - view subscription status' Dec 17 00:24:39 erin vdr: [15132] ERROR: no useful data seen within 10540220 byte of video stream Dec 17 00:27:48 erin vdr: [15132] PES packet shortened to 27080 bytes (expected: 53845 bytes) Dec 17 00:30:32 erin vdr: [14866] CAM 1: select 4 Dec 17 00:30:33 erin vdr: [14866] CAM 1: Menu -- Dec 17 00:30:33 erin vdr: [14866] CAM 1: 'Conax Conditional Access' Dec 17 00:30:33 erin vdr: [14866] CAM 1: 'Subscription status' Dec 17 00:30:33 erin vdr: [14866] CAM 1: 'Name: Digitenne ' Dec 17 00:30:33 erin vdr: [14866] CAM 1: 'Start date 01. Dec 2010 01. Jan 1990' Dec 17 00:30:33 erin vdr: [14866] CAM 1: 'End date 31. Dec 2010 01. Jan 1990' Dec 17 00:30:33 erin vdr: [14866] CAM 1: 'Entitlement 010b 01ff' Dec 17 00:30:33 erin vdr: [14866] CAM 1: 'The First Entitlement' Dec 17 00:30:33 erin vdr: [14866] CAM 1: 'The End Entitlement' Dec 17 00:30:33 erin vdr: [14866] CAM 1: 'OK - view subscription status' Dec 17 00:30:33 erin vdr: [14866] [xine..put] OSD bandwidth: 1077562 bytes/s (8418 kbit/s) Dec 17 00:30:34 erin vdr: [14866] CAM 1: Menu -- Dec 17 00:30:34 erin vdr: [14866] CAM 1: 'Conax Conditional Access' Dec 17 00:30:34 erin vdr: [14866] CAM 1: 'Main menu' Dec 17 00:30:34 erin vdr: [14866] CAM 1: 'Subscription status' Dec 17 00:30:34 erin vdr: [14866] CAM 1: 'Event status' Dec 17 00:30:34 erin vdr: [14866] CAM 1: 'Tokens status' Dec 17 00:30:34 erin vdr: [14866] CAM 1: 'Change CA PIN' Dec 17 00:30:34 erin vdr: [14866] CAM 1: 'Maturity Rating' Dec 17 00:30:34 erin vdr: [14866] CAM 1: 'Modem Ordering' Dec 17 00:30:34 erin vdr: [14866] CAM 1: 'About Conax CA' Dec 17 00:30:34 erin vdr: [14866] CAM 1: 'Message' Dec 17 00:30:34 erin vdr: [14866] CAM 1: 'Language' Dec 17 00:30:34 erin vdr: [14866] CAM 1: 'Loader status' Dec 17 00:30:34 erin vdr: [14866] CAM 1: 'Press 'OK' to select; Press 'EXIT' to return' Dec 17 00:30:35 erin vdr: [14866] [xine..put] OSD bandwidth: 918770 bytes/s (7177 kbit/s) Dec 17 00:30:35 erin vdr: [14866] CAM 1: select 1 Dec 17 00:30:36 erin vdr: [14866] CAM 1: Menu -- Dec 17 00:30:36 erin vdr: [14866] CAM 1: '' Dec 17 00:30:36 erin vdr: [14866] CAM 1: 'No Entitlement!' Dec 17 00:30:36 erin vdr: [14866] [xine..put] OSD bandwidth: 857737 bytes/s (6701 kbit/s) Dec 17 00:30:37 erin vdr: [14866] CAM 1: Menu -- Dec 17 00:30:37 erin vdr: [14866] CAM 1: 'Conax Conditional Access' Dec 17 00:30:37 erin vdr: [14866] CAM 1: 'Main menu' Dec 17 00:30:37 erin vdr: [14866] CAM 1: 'Subscription status' Dec 17 00:30:37 erin vdr: [14866] CAM 1: 'Event status' Dec 17 00:30:37 erin vdr: [14866] CAM 1: 'Tokens status' Dec 17 00:30:37 erin vdr: [14866] CAM 1: 'Change CA PIN' Dec 17 00:30:37 erin vdr: [14866] CAM 1: 'Maturity Rating' Dec 17 00:30:37 erin vdr: [14866] CAM 1: 'Modem Ordering' Dec 17 00:30:37 erin vdr: [14866] CAM 1: 'About Conax CA' Dec 17 00:30:37 erin vdr: [14866] CAM 1: 'Message' Dec 17 00:30:37 erin vdr: [14866] CAM 1: 'Language' Dec 17 00:30:37 erin vdr: [14866] CAM 1: 'Loader status' Dec 17 00:30:37 erin vdr: [14866] CAM 1: 'Press 'OK' to select; Press 'EXIT' to return' On 12/16/10 22:19, Oliver Schinagl wrote: I think this should be it with CI enabled in the source, any easy way I can check this on the binary
Re: [vdr] [Patch] Make RGYB buttons customizeable
Nobody has any comment at all? :) I haven't found an issue as of yet running this for weeks now on my own VDR. I must say, it is nice to have the color order of the buttons match my remote :) On 09/16/10 04:05, Oliver Schinagl wrote: Hey all, Ever had the trouble that your remote's color navigation key weren't the same as VDR's? Well I wrote this patch the past 4 hours which lets you configure them. By doing so, the order of the buttons in the menu changes depending on whatever you tell it to. So finally that remote can match whatever is displayed on screen. This only works for the classic and st-tng skins, as those are supplied with VDR. The Skin needs to support this feature. If there is no skin support, the setting simply gets ignored by that skin. Since only the order of the buttons in the skin are being changed any plugin configuration will be independent from this change. What I mean is that, when a plugin has configured blue to take you straight to the photo gallery, the blue button will still do this, no matter where it is on the remote. If the plugin however used the blue key to fast forward, because it is the right most key, and thus made sense logically there, it will no longer when you move the keys around. Practically, this will boil down to a handful of plugins depending on location which imo is a little weird anyway :) Also, I patched it on a Gentoo box using the latest 1.6 ebuild they have so line numbers may be a little off in the patch due to various patches Gentoo may apply. It's the only dev. box for VDR I have so forgive me on that. I'm looking forward to the review :) Oliver ___ 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] [Patch] Make RGYB buttons customizeable
Hey all,
Ever had the trouble that your remote's color navigation key weren't the
same as VDR's? Well I wrote this patch the past 4 hours which lets you
configure them.
By doing so, the order of the buttons in the menu changes depending on
whatever you tell it to. So finally that remote can match whatever is
displayed on screen.
This only works for the classic and st-tng skins, as those are supplied
with VDR. The Skin needs to support this feature. If there is no skin
support, the setting simply gets ignored by that skin. Since only the
order of the buttons in the skin are being changed any plugin
configuration will be independent from this change. What I mean is that,
when a plugin has configured blue to take you straight to the photo
gallery, the blue button will still do this, no matter where it is on
the remote. If the plugin however used the blue key to fast forward,
because it is the right most key, and thus made sense logically there,
it will no longer when you move the keys around. Practically, this will
boil down to a handful of plugins depending on location which imo is a
little weird anyway :)
Also, I patched it on a Gentoo box using the latest 1.6 ebuild they have
so line numbers may be a little off in the patch due to various patches
Gentoo may apply. It's the only dev. box for VDR I have so forgive me on
that.
I'm looking forward to the review :)
Oliver
diff -ru config.c.orig config.c
--- config.c.orig 2010-09-16 03:34:59.0 +0200
+++ config.c 2010-09-16 03:35:36.0 +0200
@@ -218,6 +218,10 @@
strcpy(OSDLanguage, ); // default is taken from environment
strcpy(OSDSkin, sttng);
strcpy(OSDTheme, default);
+ Button0 = 0;
+ Button1 = 1;
+ Button2 = 2;
+ Button3 = 3;
PrimaryDVB = 1;
ShowInfoOnChSwitch = 1;
TimeoutRequChInfo = 1;
@@ -417,6 +421,10 @@
if (!strcasecmp(Name, OSDLanguage)) { strn0cpy(OSDLanguage, Value, sizeof(OSDLanguage)); I18nSetLocale(OSDLanguage); }
else if (!strcasecmp(Name, OSDSkin)) Utf8Strn0Cpy(OSDSkin, Value, MaxSkinName);
else if (!strcasecmp(Name, OSDTheme))Utf8Strn0Cpy(OSDTheme, Value, MaxThemeName);
+ else if (!strcasecmp(Name, Button0)) Button0= atoi(Value);
+ else if (!strcasecmp(Name, Button1)) Button1= atoi(Value);
+ else if (!strcasecmp(Name, Button2)) Button2= atoi(Value);
+ else if (!strcasecmp(Name, Button3)) Button3= atoi(Value);
else if (!strcasecmp(Name, PrimaryDVB)) PrimaryDVB = atoi(Value);
else if (!strcasecmp(Name, ShowInfoOnChSwitch)) ShowInfoOnChSwitch = atoi(Value);
else if (!strcasecmp(Name, TimeoutRequChInfo)) TimeoutRequChInfo = atoi(Value);
@@ -524,6 +532,10 @@
Store(OSDLanguage,OSDLanguage);
Store(OSDSkin,OSDSkin);
Store(OSDTheme, OSDTheme);
+ Store(Button0,Button0);
+ Store(Button1,Button1);
+ Store(Button2,Button2);
+ Store(Button3,Button3);
Store(PrimaryDVB, PrimaryDVB);
Store(ShowInfoOnChSwitch, ShowInfoOnChSwitch);
Store(TimeoutRequChInfo, TimeoutRequChInfo);
diff -ru config.h.orig config.h ~/Desktop/config.h.diff
--- config.h.orig 2010-09-16 03:34:39.0 +0200
+++ config.h 2010-09-16 03:35:38.0 +0200
@@ -219,6 +219,10 @@
char OSDLanguage[I18N_MAX_LOCALE_LEN];
char OSDSkin[MaxSkinName];
char OSDTheme[MaxThemeName];
+ int Button0;
+ int Button1;
+ int Button2;
+ int Button3;
int PrimaryDVB;
int ShowInfoOnChSwitch;
int TimeoutRequChInfo;
diff -ru menu.c.orig menu.c
--- menu.c.orig 2010-09-16 03:34:44.0 +0200
+++ menu.c 2010-09-16 03:35:36.0 +0200
@@ -2422,6 +2422,7 @@
const char *useSmallFontTexts[3];
const char *mainMenuTitle[MAXMAINMENUTITLE];
int osdLanguageIndex;
+ const char *buttonColorTexts[4];
int numSkins;
int originalSkinIndex;
int skinIndex;
@@ -2475,12 +2476,20 @@
mainMenuTitle[1]=tr(VDR - text);
mainMenuTitle[2]=tr(text);
mainMenuTitle[3]=tr(VDR - version);
+ buttonColorTexts[0]=tr(Key$Red);
+ buttonColorTexts[1]=tr(Key$Green);
+ buttonColorTexts[2]=tr(Key$Yellow);
+ buttonColorTexts[3]=tr(Key$Blue);
Clear();
SetSection(tr(OSD));
Add(new cMenuEditStraItem(tr(Setup.OSD$Language), osdLanguageIndex, I18nNumLanguagesWithLocale(), I18nLanguages()-At(0)));
Add(new cMenuEditStraItem(tr(Setup.OSD$Skin), skinIndex, numSkins, skinDescriptions));
if (themes.NumThemes())
Add(new cMenuEditStraItem(tr(Setup.OSD$Theme), themeIndex, themes.NumThemes(), themes.Descriptions()));
+ Add(new cMenuEditStraItem(tr(Setup.OSD$Button0),data.Button0, 4, buttonColorTexts));
+ Add(new cMenuEditStraItem(tr(Setup.OSD$Button1),data.Button1, 4, buttonColorTexts));
+ Add(new cMenuEditStraItem(tr(Setup.OSD$Button2),data.Button2, 4,
