Re: [vdr] BUG: DVB-T and DVB-S[2] do not work with VDR & multiproto
Hi,
Stefan Lucke schrieb:
>>> Same here.
>>> Which DVB-T device do you use ? I'm using a cinergyT2.
>>>
>>> Ioctl's for this device are not passed
>>> via the common frontend interface. The new "API" has to get
>>> integrated into the cinergyT2 driver or client programs like vdr etc.
>>> have to recognize the driver supported API ;-) .
>>
>> I am using two Hauppauge Nova-T (tda1004x and cx2388x).
>>
>> Manu said in an earlier thread that there should be compatibility with
>> the old API so he doesn't think that should be a problem. The driver
>> in the multiproto tree for my devices have not been changed so should
>> work through the compatibility layer.
>>
>> The odd thing is that when I use an older pre-compiled VDR 1.4.x with
>> the new multiproto drivers everything works fine but when I compile
>> 1.5.12 with multiproto includes it doesn't work.
I spent the whole evening with Manu looking through the emulation
layer and cannot see any obvious errors in the DVB-T case.
It looks like there is still an error in the translation from the
multiproto SET_PARAMS ioctl to the old SET_FRONTEND. Manu was so
kind and created the attached patch, which prints the original
values given to SET_PARAMS in the DVB-T case and the translated
values which tda1004x' set_frontend() implementation receives.
Morfsta: as you have such a card and reported that VDR-1.4.x
tunes to DVB-T using the multiproto drivers (but old API) I ask
you to test this patch.
Make sure that VDR only uses the device with the tda1004x on it
by adding a suitable -Dx argument to VDR's command line.
To activate the logging messages, load the module dvb_core with
parameter dvb_frontend_debug=1 and the module tda1004x with
parameter debug=1.
Then use VDR-1.4.x (limited to only one device) and tune to a
certain DVB-T channel. Have a look what the driver reports (see
dmesg or /var/log/messages or anything else which suits your
system) at least for the set_frontend() function.
Next use VDR-1.5.12-dvbs2-... (limited to only one device) and
tune to the same DVB-T channel. Check what the driver reports
this time. Additionally to the set_frontend() output there must a
similar output before it which shows the parameters which VDR
passed to the emulation layer.
Please report the debug output here for further investigation.
> So I guess in your case, there is still an issue with the compatibility
> layer of http://jusst.de/hg/multiproto/ .
>
> In my case I managed to get my cinergyT2 work with Reinhard's
> modified vdr, with attached diff.
Hmm, looks like you provide your own emulation layer :-(
Anyway, Manu agrees with me that it is not a good idea to have
multiple implementations of an emulation layer with the expense
of fixing the same bugs in every single driver.
Only when a device requires to use the new API (e. g. to report
DELSYS_DVBS2), the driver should be ported to the new API and
typically it should drop support for the old API at the same
time, too.
So, please revert your change and apply the attached patch. Copy
the debug output code from the tda1004x to your driver's file and
take part in the test.
Thanks in advance.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
diff -r 4df151d5b3fe linux/drivers/media/dvb/dvb-core/dvb_frontend.c
--- a/linux/drivers/media/dvb/dvb-core/dvb_frontend.c Sat Dec 01 01:50:24 2007 +0400
+++ b/linux/drivers/media/dvb/dvb-core/dvb_frontend.c Sun Jan 13 02:11:39 2008 +0400
@@ -371,6 +371,15 @@ int newapi_to_olddrv(struct dvbfe_params
p->frequency = params->frequency;
p->inversion = params->inversion;
+ dprintk("%s (Debug): __func__\n,\
+ Frequency=0x%04x\n,\
+ Inversion=0x%04x\n,\
+ Delivery System=0x%04x\n",\
+ __func__,\
+ p->frequency,\
+ p->inversion,\
+ delsys);
+
switch (delsys) {
case DVBFE_DELSYS_DVBS:
qpsk->symbol_rate = dvbs->symbol_rate;
@@ -382,6 +391,25 @@ int newapi_to_olddrv(struct dvbfe_params
newfec_to_oldfec(dvbc->fec, &qam->fec_inner);
break;
case DVBFE_DELSYS_DVBT:
+ dprintk("%s (Debug): Delivery System=DVB-T\n,\
+ Bandwidth=0x%04x\n,\
+ Code Rate HP=0x%04x\n,\
+ Code Rate LP=0x%04x\n,\
+ Constellation=0x%04x\n,\
+ Transmission mode=0x%04x\n,\
+ Guard Interval=0x%04x\n,\
+ Hierarchy=0x%04x\n,\
+ Alpha=0x%04x\n",\
+ __func__,\
+ dvbt->bandwidth,\
+ dvbt->code_rate_HP,\
+ dvbt->code_rate_LP,\
+ dvbt->constellation,\
+ dvbt->transmission_mode,\
+ dvbt->guard_interval,\
+ dvbt->hierarchy,\
+ dvbt->alpha);
+
switch (dvbt->bandwidth) {
case DVBFE_BANDWIDTH_8_MHZ:
ofdm->bandwidth = BANDWIDTH_8_MHZ;
diff -r 4df151d5b3fe linux/drivers/media/dvb/frontends/tda1004x.c
--- a/linux/drivers/media/dvb/frontends/tda1004x.c Sat Dec 01 01:50:24 2007 +0400
+++ b/linux/drivers/media/dvb/frontends/tda1004x.c Sun Jan 13 02:19:05 2008 +0400
@@ -688,6 +688,26 @@ static int tda1004x_set_fe(struct dvb_fr
int inversion;
dprintk("%s\n", __FUNCTION__);
+ dprintk("%s (Debug):\n,\
+ Frequency=0x%04x\n,\
+
Re: [vdr] BUG: DVB-T and DVB-S[2] do not work with VDR & multiproto [Was: Two VDR's on one machine]
On Saturday 12 January 2008, Morfsta wrote:
> On Jan 12, 2008 3:37 PM, Stefan Lucke <[EMAIL PROTECTED]> wrote:
> > Same here.
> > Which DVB-T device do you use ? I'm using a cinergyT2.
> >
> > Ioctl's for this device are not passed
> > via the common frontend interface. The new "API" has to get
> > integrated into the cinergyT2 driver or client programs like vdr etc.
> > have to recognize the driver supported API ;-) .
> >
>
> I am using two Hauppauge Nova-T (tda1004x and cx2388x).
>
> Manu said in an earlier thread that there should be compatibility with
> the old API so he doesn't think that should be a problem. The driver
> in the multiproto tree for my devices have not been changed so should
> work through the compatibility layer.
>
> The odd thing is that when I use an older pre-compiled VDR 1.4.x with
> the new multiproto drivers everything works fine but when I compile
> 1.5.12 with multiproto includes it doesn't work.
So I guess in your case, there is still an issue with the compatibility
layer of http://jusst.de/hg/multiproto/ .
In my case I managed to get my cinergyT2 work with Reinhard's
modified vdr, with attached diff.
--
Stefan Lucke
diff -r 4df151d5b3fe linux/drivers/media/dvb/cinergyT2/cinergyT2.c
--- a/linux/drivers/media/dvb/cinergyT2/cinergyT2.c Sat Dec 01 01:50:24
2007 +0400
+++ b/linux/drivers/media/dvb/cinergyT2/cinergyT2.c Sat Jan 12 22:45:29
2008 +0100
@@ -1,5 +1,5 @@
/*
- * TerraTec Cinergy T²/qanu USB2 DVB-T adapter.
+ * TerraTec Cinergy T²/qanu USB2 DVB-T adapter.
*
* Copyright (C) 2004 Daniel Mack <[EMAIL PROTECTED]> and
* Holger Waechtler <[EMAIL PROTECTED]>
@@ -511,6 +511,106 @@ static uint16_t compute_tps (struct dvb_
return tps;
}
+static uint16_t compute_newtps (struct dvbfe_params *fep)
+{
+ uint16_t tps = 0;
+
+ switch (fep->delsys.dvbt.code_rate_HP) {
+ case DVBFE_FEC_2_3:
+ tps |= (1 << 7);
+ break;
+ case DVBFE_FEC_3_4:
+ tps |= (2 << 7);
+ break;
+ case DVBFE_FEC_5_6:
+ tps |= (3 << 7);
+ break;
+ case DVBFE_FEC_7_8:
+ tps |= (4 << 7);
+ break;
+ case DVBFE_FEC_1_2:
+ case DVBFE_FEC_AUTO:
+ default:
+ /* tps |= (0 << 7) */;
+ }
+
+ switch (fep->delsys.dvbt.code_rate_LP) {
+ case DVBFE_FEC_2_3:
+ tps |= (1 << 4);
+ break;
+ case DVBFE_FEC_3_4:
+ tps |= (2 << 4);
+ break;
+ case DVBFE_FEC_5_6:
+ tps |= (3 << 4);
+ break;
+ case DVBFE_FEC_7_8:
+ tps |= (4 << 4);
+ break;
+ case DVBFE_FEC_1_2:
+ case DVBFE_FEC_AUTO:
+ default:
+ /* tps |= (0 << 4) */;
+ }
+
+ switch (fep->delsys.dvbt.constellation) {
+ case DVBFE_MOD_QAM16:
+ tps |= (1 << 13);
+ break;
+ case DVBFE_MOD_QAM64:
+ tps |= (2 << 13);
+ break;
+ case DVBFE_MOD_QPSK:
+ default:
+ /* tps |= (0 << 13) */;
+ }
+
+ switch (fep->delsys.dvbt.transmission_mode) {
+ case DVBFE_TRANSMISSION_MODE_8K:
+ tps |= (1 << 0);
+ break;
+ case DVBFE_TRANSMISSION_MODE_2K:
+ default:
+ /* tps |= (0 << 0) */;
+ }
+
+ switch (fep->delsys.dvbt.guard_interval) {
+ case DVBFE_GUARD_INTERVAL_1_16:
+ tps |= (1 << 2);
+ break;
+ case DVBFE_GUARD_INTERVAL_1_8:
+ tps |= (2 << 2);
+ break;
+ case DVBFE_GUARD_INTERVAL_1_4:
+ tps |= (3 << 2);
+ break;
+ case DVBFE_GUARD_INTERVAL_1_32:
+ default:
+ /* tps |= (0 << 2) */;
+ }
+
+ switch (fep->delsys.dvbt.hierarchy) {
+ case DVBFE_HIERARCHY_ON:
+ switch (fep->delsys.dvbt.alpha) {
+ case DVBFE_ALPHA_1:
+ tps |= (1 << 10);
+ break;
+ case DVBFE_ALPHA_2:
+ tps |= (2 << 10);
+ break;
+ case DVBFE_ALPHA_4:
+ tps |= (3 << 10);
+ break;
+ }
+
Re: [vdr] BUG: DVB-T and DVB-S[2] do not work with VDR & multiproto [Was: Two VDR's on one machine]
On Jan 12, 2008 3:37 PM, Stefan Lucke <[EMAIL PROTECTED]> wrote: > Same here. > Which DVB-T device do you use ? I'm using a cinergyT2. > > Ioctl's for this device are not passed > via the common frontend interface. The new "API" has to get > integrated into the cinergyT2 driver or client programs like vdr etc. > have to recognize the driver supported API ;-) . > I am using two Hauppauge Nova-T (tda1004x and cx2388x). Manu said in an earlier thread that there should be compatibility with the old API so he doesn't think that should be a problem. The driver in the multiproto tree for my devices have not been changed so should work through the compatibility layer. The odd thing is that when I use an older pre-compiled VDR 1.4.x with the new multiproto drivers everything works fine but when I compile 1.5.12 with multiproto includes it doesn't work. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] BUG: DVB-T and DVB-S[2] do not work with VDR & multiproto [Was: Two VDR's on one machine]
On Saturday 12 January 2008, Morfsta wrote: > Hi, > > Thanks for speaking with Marco, Reinhard - its appreciated. > > Unfortunately, the patch does not fix the problem. Still no picture on > DVB-T transmissions. Same here. Which DVB-T device do you use ? I'm using a cinergyT2. Ioctl's for this device are not passed via the common frontend interface. The new "API" has to get integrated into the cinergyT2 driver or client programs like vdr etc. have to recognize the driver supported API ;-) . > > Regards > > On Jan 11, 2008 7:21 PM, Reinhard Nissl <[EMAIL PROTECTED]> wrote: > > Hi, > > > > Reinhard Nissl schrieb: > > > > > So it seems to me that either the emulation layer has a bug for > > > DVB-T or the patched VDR passes incorrect data to the new API. > > > > Looks like the latter is true: Marco Schlüßler informed me that > > the mapping of TransmissionModes in nit.c for DVB-T is wrong. > > > > I've created the attached patch according to his' instructions. > > > > Please give the patch a try and report success or failure. > > > > > > Bye. Stefan Lucke ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] BUG: DVB-T and DVB-S[2] do not work with VDR & multiproto [Was: Two VDR's on one machine]
Hi, Thanks for speaking with Marco, Reinhard - its appreciated. Unfortunately, the patch does not fix the problem. Still no picture on DVB-T transmissions. Regards On Jan 11, 2008 7:21 PM, Reinhard Nissl <[EMAIL PROTECTED]> wrote: > Hi, > > Reinhard Nissl schrieb: > > > So it seems to me that either the emulation layer has a bug for > > DVB-T or the patched VDR passes incorrect data to the new API. > > Looks like the latter is true: Marco Schlüßler informed me that > the mapping of TransmissionModes in nit.c for DVB-T is wrong. > > I've created the attached patch according to his' instructions. > > Please give the patch a try and report success or failure. > > > Bye. > -- > Dipl.-Inform. (FH) Reinhard Nissl > mailto:[EMAIL PROTECTED] > > ___ > 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] [ANNOUNCE] Hard link cutter patch 0.2.0
Hi list, I've improved the hard link cutter patch. The new 0.2.0 version has support for multiple /videoXX folders. The new patch tries to find a compatible /videoXX folder that can hold a hard link for each file. Deep mounted video folders (like mount to /video/nfs-server/ or /video/usb-disk/) should work too. WARNING: As I don't use multiple /videoXX folders myself, this feature is only minimally tested, and should be used with EXTREME CARE. Feedback is welcome! Quick info: The hard link cutter patch changes the recording editing algorithms of VDR to use file system hard links to 'copy' recording files whenever possible to speed up editing recordings noticeably. For a complete list of changes, see web page. Don't miss the README-HLCUTTER included in the patch. http://www.udo-richter.de/vdr/patches.html#hlcutter http://www.udo-richter.de/vdr/patches.en.html#hlcutter Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] improved LIRC remote for VDR-1.5.12
On Saturday 12 January 2008, Reinhard Nissl wrote: > Ville Skyttä schrieb: > > > Also, somewhat off topic: when running powertop[1] on my VDR box, I see > > lircd waking up the CPU from idle about 1000 times a second while VDR is > > connected to it: > > > > Top causes for wakeups: > > 54.3% (988.1) lircd : schedule_timeout (process_timeout) > > 28.5% (518.4) vdr : futex_wait (hrtimer_wakeup) > > [...] > > > > I already tried adding some cCondWait::SleepMs's to VDR's lirc action > > loop but it didn't seem to have any effect. Any ideas whether this is > > something that VDR could do anything about, or if it's a LIRC internal > > thing? > > Well VDR's lirc action loop uses a timeout only when it needs to > generate a keyup event after a key repeat event. Otherwise it > blocks in cFile::FileReady's select() until a button gets pressed > on the remote. > > Try running irw instead of VDR and check powertop again. Yep, same thing with irw so I suppose this needs to be addressed in LIRC, not VDR. Thanks. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] improved LIRC remote for VDR-1.5.12
Hi, Ville Skyttä schrieb: >> I think, the LIRC protocol misses a timestamp for each button >> press. Or an even more favorable solution would be to put the >> timeout and frequency processing into LIRC and have VDR to >> process each key as it arrives, just like with the KBD remote. > > Would using liblirc_client instead of the current "homebrew" implementation > help out with this? When liblirc_client uses the same interface of lircd, then I don't think that it will help. > Also, somewhat off topic: when running powertop[1] on my VDR box, I see lircd > waking up the CPU from idle about 1000 times a second while VDR is connected > to it: > > Top causes for wakeups: > 54.3% (988.1) lircd : schedule_timeout (process_timeout) > 28.5% (518.4) vdr : futex_wait (hrtimer_wakeup) > [...] > > I already tried adding some cCondWait::SleepMs's to VDR's lirc action loop > but > it didn't seem to have any effect. Any ideas whether this is something that > VDR could do anything about, or if it's a LIRC internal thing? Well VDR's lirc action loop uses a timeout only when it needs to generate a keyup event after a key repeat event. Otherwise it blocks in cFile::FileReady's select() until a button gets pressed on the remote. Try running irw instead of VDR and check powertop again. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] improved LIRC remote for VDR-1.5.12
On Saturday 12 January 2008, Reinhard Nissl wrote: > I think, the LIRC protocol misses a timestamp for each button > press. Or an even more favorable solution would be to put the > timeout and frequency processing into LIRC and have VDR to > process each key as it arrives, just like with the KBD remote. Would using liblirc_client instead of the current "homebrew" implementation help out with this? Also, somewhat off topic: when running powertop[1] on my VDR box, I see lircd waking up the CPU from idle about 1000 times a second while VDR is connected to it: Top causes for wakeups: 54.3% (988.1) lircd : schedule_timeout (process_timeout) 28.5% (518.4) vdr : futex_wait (hrtimer_wakeup) [...] I already tried adding some cCondWait::SleepMs's to VDR's lirc action loop but it didn't seem to have any effect. Any ideas whether this is something that VDR could do anything about, or if it's a LIRC internal thing? [1] http://www.lesswatts.org/projects/powertop/ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] contact to femon plugin developer
Hello vdr readers, is there a possibility to contact the femon-plugin developer? I want to give any feature request for make the femon plugin accessible for braille users. -- Best regards Sebastian ICQ: 264706583 | MSM: [EMAIL PROTECTED] | Skype: sebo_de | Yahoo: de_sebo E-Mail: [EMAIL PROTECTED] | Web: www.blindzeln.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
