[linux-dvb] Pinnacle PCTV Sat Pro PCI DVB-S Card
Hi folks, I was wondering if someone could possibly advise me with regards to a Digital Satellite card which I am trying to get working. The card is a Pinnacle PCTV Sat Pro PCI card. I am running Ubuntu Edgy 6.10 with a 2.6.17-11 kernel. Now it appears that a driver isn't loaded at startup so I guessed that this kernel at least doesn't support the card. Now I'm not very good at coding, in fact I'm next to useless at it but I wondered if there is anything I could do to help try and get this card working? I'm not sure if this helps but below is the output of lspci -v for the card... 02:09.0 Multimedia controller: Pinnacle Systems Inc. Unknown device 0040 Subsystem: Pinnacle Systems Inc. Unknown device 0048 Flags: bus master, medium devsel, latency 32, IRQ 3 Memory at ea00 (32-bit, non-prefetchable) [size=4K] Capabilities: [40] Power Management version 2 02:09.2 Multimedia controller: Pinnacle Systems Inc. Unknown device 0042 Subsystem: Pinnacle Systems Inc. Unknown device 0048 Flags: bus master, medium devsel, latency 32, IRQ 3 Memory at ea001000 (32-bit, non-prefetchable) [size=4K] Capabilities: [40] Power Management version 2 More details on the card can be found at: http://www.pinnaclesys.com/PublicSite/uk/Products/Consumer+Products/PCTV+Tuners/PCTV+Digital+PVR+(DVB-S_DVB-T)/PCTV+Sat+Pro+PCI.htm If anyone could help I would be really grateful. Thanks in advance, Rob ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] CAM bonded to subscription card with DVB-C
Mattias Bergsten wrote: Bob wrote: My Cable co (StarHub Singapore) uses NagraVision Cards and CAMs which I know get bonded together in the Set Top Box at first boot, I have a spare card (never booted) as my package comes with 2 STBs is there a DVB-C card + CAM combo that can support this setup including grabbing the periodic key updates automatically? If you get yourself a Nagra CAM, use it in an STB (that does NOT have built-in Nagra) with your second card, it should theoretically be bonded to that CAM. No warranties, though, since I haven't tried it. So to do this I'd have to find a cable STB that doesn't have an integrated CAM and use it to bond a Nagra CAM and my subscription SmartCard together, than I could use that CAM + SmartCard combo together with a supported DVB-C card + CI to watch cable on the computer, they don't make it easy do they. With this would decryption key updates be automatic or would I have to put the CAM + SmartCard back in the STB periodically to receive updates? I'm nervous about buying all this and having it not work. The other alternative is finding the boxkey of your STB and using a softcam with a Phoenix interface to read your card. This I know works. Is there a HowTo on this, it's my least favored option as there seems to be some stigma attached to softcams, presumably because you could use it to do something dubious, but if they've made it impossible to do it any other way... Another thing I found is that Telewest in the UK also use NagraVision and there are reports of people getting it working with the Dragon CAM and a FireDTV box under Windows, could I use a Dragon CAM with another card or have the FireDTV drivers moved on since January 06? http://linuxtv.org/pipermail/linux-dvb/2006-January/007938.html http://www.jonathansblog.net/telewest_pvr Thanks for your reply ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] CAM bonded to subscription card with DVB-C
Bob wrote: My Cable co (StarHub Singapore) uses NagraVision Cards and CAMs which I know get bonded together in the Set Top Box at first boot, I have a spare card (never booted) as my package comes with 2 STBs is there a DVB-C card + CAM combo that can support this setup including grabbing the periodic key updates automatically? If you get yourself a Nagra CAM, use it in an STB (that does NOT have built-in Nagra) with your second card, it should theoretically be bonded to that CAM. No warranties, though, since I haven't tried it. The other alternative is finding the boxkey of your STB and using a softcam with a Phoenix interface to read your card. This I know works. /fnord ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] CAM bonded to subscription card with DVB-C
Hi don't thing this has been covered recently (if it has sorry) My Cable co (StarHub Singapore) uses NagraVision Cards and CAMs which I know get bonded together in the Set Top Box at first boot, I have a spare card (never booted) as my package comes with 2 STBs is there a DVB-C card + CAM combo that can support this setup including grabbing the periodic key updates automatically? My grueling research 8 months ago suggested not and a few searches just now don't show any change but, I wondered if things had moved on and my poor 5am search skills failed to show it? I'm not trying to do anything clever or dodgey, I don't want to watch any channels I haven't payed for, I'm just getting cheesed off with the quality and CPU time involved in capping everything off composite Thanks for any help, keep up the good work DVB devs PS: if it's one of those things where it would work, but none of the devs have the hardware, tell me what to buy and I'll chuck it in a dedicated box on a dedicated network and give you an account on it. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: TDA8290/TDA8275 with LNA
Hi, Nico Nico Sabbi schrieb: > Hartmut Hackmann wrote: >> Hi, Nico >> >> I found a bug in the tda827x module. A buffer was one byte too short. >> This might have been the cause of the crashes since the trouble started >> after the first tuning attempt and the bug was in the tuning function. >> So may i ask you to apply the attached patch or to pull from my personal >> repository at >> http://linuxtv.org/hg/~hhackmann/v4l-dvb >> >> Sorry for the inconvenience >>Hartmut > > it works! Thanks for your patch! > As for the gain I'll have to run some test and see if it helps. > At first sight it doesn't seem to make much difference. I'll report > tomorrow > Uff Thanks a lot for the quick report, this really worried me! I can't tell whether your card has these LNA But i would like to recommend to turn the debug options on for both, tuner and tda827x and watch what it tells about AGC2. Good luck and best regards Hartmut ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] RFC: merge dvb_tuner_ops & tuner-core second try
On 2/27/07, Marcel Siegert <[EMAIL PROTECTED]> wrote:
On Tuesday 27 February 2007, Markus Rechberger wrote:
> Hi guys,
>
> since I really want to get that xc3028 story done I propose to add
> some changes to the dvb framework which would allow to support loading
> tuner modules from v4l and dvb without having a real dependency of
> each other.
> The interface I aim at uses almost the same structure as dvb_tuner_ops.
>
> So to point it out more clearly:
>
> I'd like to replace or modify:
> struct dvb_tuner_ops {
>
> struct dvb_tuner_info info;
>
> int (*release)(struct dvb_frontend *fe);
> int (*init)(struct dvb_frontend *fe);
> int (*sleep)(struct dvb_frontend *fe);
>
> /** This is for simple PLLs - set all parameters in one go. */
> int (*set_params)(struct dvb_frontend *fe, struct
> dvb_frontend_parameters *p);
>
> /** This is support for demods like the mt352 - fills out the
> supplied buffer with what to write. */
> int (*calc_regs)(struct dvb_frontend *fe, struct
> dvb_frontend_parameters *p, u8 *buf, int buf_len);
>
> int (*get_frequency)(struct dvb_frontend *fe, u32 *frequency);
> int (*get_bandwidth)(struct dvb_frontend *fe, u32 *bandwidth);
>
> #define TUNER_STATUS_LOCKED 1
> int (*get_status)(struct dvb_frontend *fe, u32 *status);
>
> /** These are provided seperately from set_params in order to
> facilitate silicon
> * tuners which require sophisticated tuning loops,
> controlling each parameter seperately. */
> int (*set_frequency)(struct dvb_frontend *fe, u32 frequency);
> int (*set_bandwidth)(struct dvb_frontend *fe, u32 bandwidth);
> };
>
> with:
> struct v4l_dvb_tuner {
> /* wrapper */
> void *priv; /* some privat data for internal use */
> void *dev; /* v4l private data for tuner-core */
> struct dvb_frontend *fe; /* dvb_frontend, for dvb only
> drivers, internal use */
>
> int (*ioctl)(struct v4l_dvb_tuner *dev, int cmd, int arg);
> struct tuner_info info;
> int (*release)(struct v4l_dvb_tuner *dev);
> int (*init)(struct v4l_dvb_tuner *dev);
> int (*sleep)(struct v4l_dvb_tuner *dev);
>
> /** This is for simple PLLs - set all parameters in one go. */
> int (*set_params)(struct v4l_dvb_tuner *dev, struct
> tuner_parameters *p);
>
> /** This is support for demods like the mt352 - fills out the
> supplied buffer with what to write. */
> int (*calc_regs)(struct v4l_dvb_tuner *dev, struct
> tuner_parameters *p, u8 *buf, int buf_len);
>
> int (*get_frequency)(struct v4l_dvb_tuner *dev, u32 *frequency);
> int (*get_bandwidth)(struct v4l_dvb_tuner *dev, u32 *bandwidth);
>
> #define TUNER_STATUS_LOCKED 1
> int (*get_status)(struct v4l_dvb_tuner *dev, u32 *status);
>
> /** These are provided seperately from set_params in order to
> facilitate silicon
> * tuners which require sophisticated tuning loops,
> controlling each parameter seperately. */
> int (*set_frequency)(struct v4l_dvb_tuner *dev, u32 frequency);
> int (*set_bandwidth)(struct v4l_dvb_tuner *dev, u32 bandwidth);
>
> int (*set_mode)(struct v4l_dvb_tuner *dev, struct
> tuner_parameters *params);
> };
>
> tuner_parameters is an extended version of dvb_frontend_params
>
> struct dvb_frontend_parameters {
> __u32 frequency; /* (absolute) frequency in Hz for
QAM/OFDM/ATSC */
> /* intermediate frequency in kHz for QPSK */
> fe_spectral_inversion_t inversion;
> union {
> struct dvb_qpsk_parameters qpsk;
> struct dvb_qam_parameters qam;
> struct dvb_ofdm_parameters ofdm;
> struct dvb_vsb_parameters vsb;
> } u;
> };
>
> vs:
>
> struct tuner_parameters {
> __u32 frequency; /* (absolute) frequency in Hz for
QAM/OFDM/ATSC */
> /* intermediate frequency in kHz for QPSK */
> enum v4l2_tuner_typetype;
> v4l2_std_id std;
> fe_spectral_inversion_t inversion;
> union {
> struct dvb_qpsk_parameters qpsk;
> struct dvb_qam_parameters qam;
> struct dvb_ofdm_parameters ofdm;
> struct dvb_vsb_parameters vsb;
> } u;
> };
>
> for not breaking userspace we can use an internal converter for that
> format just like:
> #define V4L_OPS(i) ({ \
> struct tuner_parameters __o; \
> __o.frequency = i->frequency; \
> __o.inversion = i->inversion; \
>
> &__o; \
> })
>
> this seems to be a good approach for hybrid devices
> dvb only silicon tuners could still access dvb_frontend internally,
> hybrid tuners have to avoid this since the structure since it wouldn't
> be fully initialized.
> So what do you guys think about that?
>
> I already have some code whic
Re: [linux-dvb] Re: TDA8290/TDA8275 with LNA
Hartmut Hackmann wrote: Hi, Nico I found a bug in the tda827x module. A buffer was one byte too short. This might have been the cause of the crashes since the trouble started after the first tuning attempt and the bug was in the tuning function. So may i ask you to apply the attached patch or to pull from my personal repository at http://linuxtv.org/hg/~hhackmann/v4l-dvb Sorry for the inconvenience Hartmut it works! Thanks for your patch! As for the gain I'll have to run some test and see if it helps. At first sight it doesn't seem to make much difference. I'll report tomorrow -- "Without a frontend, mplayer is useless" - someone in mplayer-users ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: TDA8290/TDA8275 with LNA
Hi, Nico
I found a bug in the tda827x module. A buffer was one byte too short.
This might have been the cause of the crashes since the trouble started
after the first tuning attempt and the bug was in the tuning function.
So may i ask you to apply the attached patch or to pull from my personal
repository at
http://linuxtv.org/hg/~hhackmann/v4l-dvb
Sorry for the inconvenience
Hartmut
# HG changeset patch
# User Hartmut Hackmann <[EMAIL PROTECTED]>
# Date Tue Feb 27 22:18:52 2007 +0100
# Node ID 3116942ce085558a27e0bd51e0958275bb757af6
# parent: 065567ae3ae076caa8b08deedb80df2e305da8ec
Fixed 1 byte too short buffer in tda827x.c
From: Hartmut Hackmann <[EMAIL PROTECTED]>
- The i2c data buffer in tda827xa_set_params was 1 byte too short
- saa7134-dvb now gives an error mesage if tda827x could not be attached
- coding style fix in tda1004x.c
Signed-off-by: Hartmut Hackmann <[EMAIL PROTECTED]>
--- a/linux/drivers/media/dvb/frontends/tda1004x.c Sun Feb 25 10:09:33 2007 -0200
+++ b/linux/drivers/media/dvb/frontends/tda1004x.c Tue Feb 27 22:18:52 2007 +0100
@@ -695,7 +695,8 @@ static int tda1004x_set_fe(struct dvb_fr
// set frequency
if (fe->ops.tuner_ops.set_params) {
fe->ops.tuner_ops.set_params(fe, fe_params);
- if (fe->ops.i2c_gate_ctrl) fe->ops.i2c_gate_ctrl(fe, 0);
+ if (fe->ops.i2c_gate_ctrl)
+ fe->ops.i2c_gate_ctrl(fe, 0);
}
// Hardcoded to use auto as much as possible on the TDA10045 as it
--- a/linux/drivers/media/dvb/frontends/tda827x.c Sun Feb 25 10:09:33 2007 -0200
+++ b/linux/drivers/media/dvb/frontends/tda827x.c Tue Feb 27 22:18:52 2007 +0100
@@ -214,7 +214,7 @@ static int tda827xa_set_params(struct dv
struct dvb_frontend_parameters *params)
{
struct tda827x_priv *priv = fe->tuner_priv;
- u8 buf[10];
+ u8 buf[11];
struct i2c_msg msg = { .addr = priv->i2c_addr, .flags = 0,
.buf = buf, .len = sizeof(buf) };
--- a/linux/drivers/media/video/saa7134/saa7134-dvb.c Sun Feb 25 10:09:33 2007 -0200
+++ b/linux/drivers/media/video/saa7134/saa7134-dvb.c Tue Feb 27 22:18:52 2007 +0100
@@ -693,8 +693,11 @@ static void configure_tda827x_fe(struct
if (dev->dvb.frontend) {
if (tda_conf->i2c_gate)
dev->dvb.frontend->ops.i2c_gate_ctrl = tda8290_i2c_gate_ctrl;
- dvb_attach(tda827x_attach,dev->dvb.frontend,
- tda_conf->tuner_address,&dev->i2c_adap,&tda827x_cfg);
+ if (dvb_attach(tda827x_attach, dev->dvb.frontend, tda_conf->tuner_address,
+ &dev->i2c_adap,&tda827x_cfg) == NULL) {
+ printk ("saa7134/dvb: no tda827x tuner found at addr: %02x\n",
+tda_conf->tuner_address);
+ }
}
}
@@ -1039,9 +1042,12 @@ static int dvb_init(struct saa7134_dev *
&ads_tech_duo_config,
&dev->i2c_adap);
if (dev->dvb.frontend) {
- dvb_attach(tda827x_attach,dev->dvb.frontend,
+ if (dvb_attach(tda827x_attach,dev->dvb.frontend,
ads_tech_duo_config.tuner_address,
- &dev->i2c_adap,&ads_duo_cfg);
+ &dev->i2c_adap,&ads_duo_cfg) == NULL) {
+printk ("saa7134/dvb: no tda827x tuner found at addr: %02x\n",
+ ads_tech_duo_config.tuner_address);
+ }
}
break;
case SAA7134_BOARD_TEVION_DVBT_220RF:
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] RFC: merge dvb_tuner_ops & tuner-core second try
On Tuesday 27 February 2007, Markus Rechberger wrote:
> Hi guys,
>
> since I really want to get that xc3028 story done I propose to add
> some changes to the dvb framework which would allow to support loading
> tuner modules from v4l and dvb without having a real dependency of
> each other.
> The interface I aim at uses almost the same structure as dvb_tuner_ops.
>
> So to point it out more clearly:
>
> I'd like to replace or modify:
> struct dvb_tuner_ops {
>
> struct dvb_tuner_info info;
>
> int (*release)(struct dvb_frontend *fe);
> int (*init)(struct dvb_frontend *fe);
> int (*sleep)(struct dvb_frontend *fe);
>
> /** This is for simple PLLs - set all parameters in one go. */
> int (*set_params)(struct dvb_frontend *fe, struct
> dvb_frontend_parameters *p);
>
> /** This is support for demods like the mt352 - fills out the
> supplied buffer with what to write. */
> int (*calc_regs)(struct dvb_frontend *fe, struct
> dvb_frontend_parameters *p, u8 *buf, int buf_len);
>
> int (*get_frequency)(struct dvb_frontend *fe, u32 *frequency);
> int (*get_bandwidth)(struct dvb_frontend *fe, u32 *bandwidth);
>
> #define TUNER_STATUS_LOCKED 1
> int (*get_status)(struct dvb_frontend *fe, u32 *status);
>
> /** These are provided seperately from set_params in order to
> facilitate silicon
> * tuners which require sophisticated tuning loops,
> controlling each parameter seperately. */
> int (*set_frequency)(struct dvb_frontend *fe, u32 frequency);
> int (*set_bandwidth)(struct dvb_frontend *fe, u32 bandwidth);
> };
>
> with:
> struct v4l_dvb_tuner {
> /* wrapper */
> void *priv; /* some privat data for internal use */
> void *dev; /* v4l private data for tuner-core */
> struct dvb_frontend *fe; /* dvb_frontend, for dvb only
> drivers, internal use */
>
> int (*ioctl)(struct v4l_dvb_tuner *dev, int cmd, int arg);
> struct tuner_info info;
> int (*release)(struct v4l_dvb_tuner *dev);
> int (*init)(struct v4l_dvb_tuner *dev);
> int (*sleep)(struct v4l_dvb_tuner *dev);
>
> /** This is for simple PLLs - set all parameters in one go. */
> int (*set_params)(struct v4l_dvb_tuner *dev, struct
> tuner_parameters *p);
>
> /** This is support for demods like the mt352 - fills out the
> supplied buffer with what to write. */
> int (*calc_regs)(struct v4l_dvb_tuner *dev, struct
> tuner_parameters *p, u8 *buf, int buf_len);
>
> int (*get_frequency)(struct v4l_dvb_tuner *dev, u32 *frequency);
> int (*get_bandwidth)(struct v4l_dvb_tuner *dev, u32 *bandwidth);
>
> #define TUNER_STATUS_LOCKED 1
> int (*get_status)(struct v4l_dvb_tuner *dev, u32 *status);
>
> /** These are provided seperately from set_params in order to
> facilitate silicon
> * tuners which require sophisticated tuning loops,
> controlling each parameter seperately. */
> int (*set_frequency)(struct v4l_dvb_tuner *dev, u32 frequency);
> int (*set_bandwidth)(struct v4l_dvb_tuner *dev, u32 bandwidth);
>
> int (*set_mode)(struct v4l_dvb_tuner *dev, struct
> tuner_parameters *params);
> };
>
> tuner_parameters is an extended version of dvb_frontend_params
>
> struct dvb_frontend_parameters {
> __u32 frequency; /* (absolute) frequency in Hz for QAM/OFDM/ATSC
> */
> /* intermediate frequency in kHz for QPSK */
> fe_spectral_inversion_t inversion;
> union {
> struct dvb_qpsk_parameters qpsk;
> struct dvb_qam_parameters qam;
> struct dvb_ofdm_parameters ofdm;
> struct dvb_vsb_parameters vsb;
> } u;
> };
>
> vs:
>
> struct tuner_parameters {
> __u32 frequency; /* (absolute) frequency in Hz for QAM/OFDM/ATSC
> */
> /* intermediate frequency in kHz for QPSK */
> enum v4l2_tuner_typetype;
> v4l2_std_id std;
> fe_spectral_inversion_t inversion;
> union {
> struct dvb_qpsk_parameters qpsk;
> struct dvb_qam_parameters qam;
> struct dvb_ofdm_parameters ofdm;
> struct dvb_vsb_parameters vsb;
> } u;
> };
>
> for not breaking userspace we can use an internal converter for that
> format just like:
> #define V4L_OPS(i) ({ \
> struct tuner_parameters __o; \
> __o.frequency = i->frequency; \
> __o.inversion = i->inversion; \
>
> &__o; \
> })
>
> this seems to be a good approach for hybrid devices
> dvb only silicon tuners could still access dvb_frontend internally,
> hybrid tuners have to avoid this since the structure since it wouldn't
> be fully initialized.
> So what do you guys think about that?
>
> I already have some code which does this and it works
Re: [linux-dvb] cant get channels (DVB-C KNC1)
Marcel 't Hart wrote: > Dear All, > > I have a KNC one with device number 0022. I used the HG sources and > the patch from E9hack. my fedora box is able to find my device (from > dmesg): > KNC1-0: MAC addr = 00:09:d6:6d:75:5b > DVB: registering frontend 0 (Philips TDA10023 DVB-C)... > budget-av: ci interface initialised. > PCI: Found IRQ 9 for device :02:03.0 > PCI: Sharing IRQ 9 with :02:09.0 > budget-av: cam inserted A > Floppy drive(s): fd0 is 1.44M > FDC 0 is a post-1991 82077 > dvb_ca adapter 0: DVB CAM detected and initialised successfully > > scandvb will give me this (no succes): > scandvb -A2 -v nl-caiw > scanning nl-caiw > WARNING: >>> tuning failed!!! > ERROR: initial tuning failed > dumping lists (0 services) > Done. > > I cross checked my frequency, thos are ok. You might need an amplifier - at least the older KNC1 / Cinergy's are quite sensitive on the SNR, even when other DVB-C cards tune with no problem. If you happen to have Siemens DVB-C card and have a higher BER than ~500 on a frequency, chances are that the KNC1 can't tune - this appears to be the same with the Windows drivers. Anything with around 20 dB gain worked for me - however I have a TDA10021. I can recommend the 2 x 20 db BK Amplifier from kab24.de but try shorter cabling first if you can. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] module parameters "ir_debug" budget_ci
Hi, I am having same troubles as Jouni in this e-mail chain. http://www. mail-archive.com/linux-dvb@linuxtv.org/msg21617.html I tried to do modprobe budget_ci ir_debug=1 rc5_device=255 modprobe says -1 Unknown symbol in module and dmesg tells budget_ci: Unknown parameter 'rc5_device' ... 'ir_debug' Does the compiling need something special to make these module parameters work? I tried to googled but without success so that's why I am asking here. One more thing... is there a list about the values that corresponds on certain rc5_device. I think source says something like 1-31 I have changed this ir_debug=1 in the source file but I can't see this module messages in dmesg. Thanks, Hartsa ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Re: Nova-T 500 (dvb_usb_dib0700) usb disconnects
> It seems that the XactErr bit gets set occasionally but does > not always lead to hard failure: But then it seems that eventually it occasionally does: [17182959.448000] ehci_hcd :03:0c.2: XactErr, token=cd08 [17186270.50] ehci_hcd :03:0c.2: XactErr, token=4d08 [17192204.628000] ehci_hcd :03:0c.2: XactErr, token=4d08 [17207488.564000] ehci_hcd :03:0c.2: XactErr, token=80004d08 [17207534.812000] ehci_hcd :03:0c.2: XactErr, token=80004d08 [17210149.544000] ehci_hcd :03:0c.2: XactErr, token=80004d08 [17213184.564000] ehci_hcd :03:0c.2: XactErr, token=8000cd08 [17234794.928000] ehci_hcd :03:0c.2: XactErr, token=80004d08 [17269865.128000] ehci_hcd :03:0c.2: XactErr, token=4d08 [17289071.784000] ehci_hcd :03:0c.2: XactErr, token=8000cd08 [17290546.404000] ehci_hcd :03:0c.2: XactErr, token=80004d08 [17293014.016000] ehci_hcd :03:0c.2: XactErr, token=8000cd08 [17293428.86] ehci_hcd :03:0c.2: XactErr, token=80004d08 [17293474.04] ehci_hcd :03:0c.2: XactErr, token=80004d08 [17298119.66] ehci_hcd :03:0c.2: XactErr, token=8000cd08 [17299546.24] ehci_hcd :03:0c.2: XactErr, token=80004d08 [17300465.852000] ehci_hcd :03:0c.2: XactErr, token=80004d08 [17300788.188000] ehci_hcd :03:0c.2: XactErr, token=8000cd08 [17300925.768000] ehci_hcd :03:0c.2: XactErr, token=8000cd08 [17300972.004000] ehci_hcd :03:0c.2: XactErr, token=8000cd08 [17301063.372000] ehci_hcd :03:0c.2: XactErr, token=8000cd08 [17301155.772000] ehci_hcd :03:0c.2: XactErr, token=8000cd08 [17301248.172000] ehci_hcd :03:0c.2: XactErr, token=8038c948 [17301248.172000] ehci_hcd :03:0c.2: XactErr, token=a8002148 [17301248.172000] ehci_hcd :03:0c.2: devpath 1 ep3in 3strikes,t=a8002148 The last transaction error has also the Halted bit set for the status field of the token. The EHCI spec says: "This can be caused by babble, the error counter counting down to zero, or reception of the STALL handshake from the device during a transaction.". The "Babble Detected" bit is not set whereas the CERR is zero (but that we knew already from the 3strikes debug print). The previous transaction error has CERR==2, but there's no transaction error with CERR==1.. hmm.. Also the other transaction errors have all CERR==3 and transfer length of zero. I put the usbmon log to http://www.hut.fi/~apm/usb-disconnect3.txt.gz If my reasoning about the timestamps is correct the last transaction error is at timestamp 30344747. There is a transfer length 10240 at that timestamp which would match the token value a8002148. I suppose I'll go reading the USB2 spec now.. :-) -- http://www.iki.fi/~ananaza/ ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] cant get channels
Marcel 't Hart wrote: tune to: 55400:INVERSION_AUTO:690:FEC_NONE:QAM_64 tuning status == 0x03 tuning status == 0x00 tuning status == 0x00 tuning status == 0x03 0x03 means FE_HAS_CARRIER and FE_HAS_SIGNAL. The signal strength may be not high enough. - Hartmut ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: Nova-T 500 (dvb_usb_dib0700) usb disconnects
On Sun, 2007-02-25 at 12:11 +0200, Antti P Miettinen wrote:
> Chris Johns <[EMAIL PROTECTED]> writes:
> > I see the same sequence that you do. Here is the specific part that
> > matches what I see. Your trace has:
>
> Hmm.. I guess I need to learn to decipher the logs. Meanwhile there's
> another log at
>
> http://www.hut.fi/~apm/usb-disconnect2.txt.gz
>
> where the disconnect should be approximately at timestamp
> 1493044489. It might be that the disconnect can be provoked by
> interrupt load. I tried whether scanning/tuning/CPU load would trigger
> the disconnect but no luck with those. The latest disconnect happened
> while I was doing a big scp from the VDR box to another machine over
> local ethernet. Might be just coincidence..
>
> Anyone have a handy way of generating interrupt load?
>
The attached C program will generate 8192 interrupts per second
using /dev/rtc. You may need to run as root or otherwise do:
# echo 8192 > /proc/sys/dev/rtc/max-user-freq
Jon
#include
#include
#include
#include
#include
#include
#include
int main(int argc, char *argv[])
{
int fd = open("/dev/rtc", O_RDONLY);
long rate, fast = 8192;
if (fd < 0) {
perror("error opening /dev/rtc");
exit(1);
}
if (ioctl(fd, RTC_IRQP_READ, &rate) < 0) {
perror("error fetching rate");
exit(2);
}
printf("Current RTC IRQ rate = %ld\n", rate);
printf("New RTC IRQ rate = %ld\n", fast);
if (ioctl(fd, RTC_IRQP_SET, fast) < 0) {
perror("error setting fast rate");
exit(3);
}
if (ioctl(fd, RTC_PIE_ON, 0) < 0) {
perror("error enabling interrupts");
exit(4);
}
printf("Press enter to stop\n", fast);
getchar();
if (ioctl(fd, RTC_IRQP_SET, rate) < 0) {
perror("error setting original rate");
exit(5);
}
if (ioctl(fd, RTC_PIE_OFF, 0) < 0) {
perror("error disabling interrupts");
exit(6);
}
return 0;
}
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] RFC: merge dvb_tuner_ops & tuner-core second try
Hi guys,
since I really want to get that xc3028 story done I propose to add
some changes to the dvb framework which would allow to support loading
tuner modules from v4l and dvb without having a real dependency of
each other.
The interface I aim at uses almost the same structure as dvb_tuner_ops.
So to point it out more clearly:
I'd like to replace or modify:
struct dvb_tuner_ops {
struct dvb_tuner_info info;
int (*release)(struct dvb_frontend *fe);
int (*init)(struct dvb_frontend *fe);
int (*sleep)(struct dvb_frontend *fe);
/** This is for simple PLLs - set all parameters in one go. */
int (*set_params)(struct dvb_frontend *fe, struct
dvb_frontend_parameters *p);
/** This is support for demods like the mt352 - fills out the
supplied buffer with what to write. */
int (*calc_regs)(struct dvb_frontend *fe, struct
dvb_frontend_parameters *p, u8 *buf, int buf_len);
int (*get_frequency)(struct dvb_frontend *fe, u32 *frequency);
int (*get_bandwidth)(struct dvb_frontend *fe, u32 *bandwidth);
#define TUNER_STATUS_LOCKED 1
int (*get_status)(struct dvb_frontend *fe, u32 *status);
/** These are provided seperately from set_params in order to
facilitate silicon
* tuners which require sophisticated tuning loops,
controlling each parameter seperately. */
int (*set_frequency)(struct dvb_frontend *fe, u32 frequency);
int (*set_bandwidth)(struct dvb_frontend *fe, u32 bandwidth);
};
with:
struct v4l_dvb_tuner {
/* wrapper */
void *priv; /* some privat data for internal use */
void *dev; /* v4l private data for tuner-core */
struct dvb_frontend *fe; /* dvb_frontend, for dvb only
drivers, internal use */
int (*ioctl)(struct v4l_dvb_tuner *dev, int cmd, int arg);
struct tuner_info info;
int (*release)(struct v4l_dvb_tuner *dev);
int (*init)(struct v4l_dvb_tuner *dev);
int (*sleep)(struct v4l_dvb_tuner *dev);
/** This is for simple PLLs - set all parameters in one go. */
int (*set_params)(struct v4l_dvb_tuner *dev, struct
tuner_parameters *p);
/** This is support for demods like the mt352 - fills out the
supplied buffer with what to write. */
int (*calc_regs)(struct v4l_dvb_tuner *dev, struct
tuner_parameters *p, u8 *buf, int buf_len);
int (*get_frequency)(struct v4l_dvb_tuner *dev, u32 *frequency);
int (*get_bandwidth)(struct v4l_dvb_tuner *dev, u32 *bandwidth);
#define TUNER_STATUS_LOCKED 1
int (*get_status)(struct v4l_dvb_tuner *dev, u32 *status);
/** These are provided seperately from set_params in order to
facilitate silicon
* tuners which require sophisticated tuning loops,
controlling each parameter seperately. */
int (*set_frequency)(struct v4l_dvb_tuner *dev, u32 frequency);
int (*set_bandwidth)(struct v4l_dvb_tuner *dev, u32 bandwidth);
int (*set_mode)(struct v4l_dvb_tuner *dev, struct
tuner_parameters *params);
};
tuner_parameters is an extended version of dvb_frontend_params
struct dvb_frontend_parameters {
__u32 frequency; /* (absolute) frequency in Hz for QAM/OFDM/ATSC */
/* intermediate frequency in kHz for QPSK */
fe_spectral_inversion_t inversion;
union {
struct dvb_qpsk_parameters qpsk;
struct dvb_qam_parameters qam;
struct dvb_ofdm_parameters ofdm;
struct dvb_vsb_parameters vsb;
} u;
};
vs:
struct tuner_parameters {
__u32 frequency; /* (absolute) frequency in Hz for QAM/OFDM/ATSC */
/* intermediate frequency in kHz for QPSK */
enum v4l2_tuner_typetype;
v4l2_std_id std;
fe_spectral_inversion_t inversion;
union {
struct dvb_qpsk_parameters qpsk;
struct dvb_qam_parameters qam;
struct dvb_ofdm_parameters ofdm;
struct dvb_vsb_parameters vsb;
} u;
};
for not breaking userspace we can use an internal converter for that
format just like:
#define V4L_OPS(i) ({ \
struct tuner_parameters __o; \
__o.frequency = i->frequency; \
__o.inversion = i->inversion; \
&__o; \
})
this seems to be a good approach for hybrid devices
dvb only silicon tuners could still access dvb_frontend internally,
hybrid tuners have to avoid this since the structure since it wouldn't
be fully initialized.
So what do you guys think about that?
I already have some code which does this and it works fine.
So I'm looking for some feedback/suggestions here
thanks,
Markus
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Analog volume without distortion
Hello list, I setup a simple VDR system with the dvb card's analog outputs connected to the TV. I set an initial volume in VDR (in the range from 0 to 255) and then I use the TV's own volume control. I'm looking for a proper dvb volume value that doesn't add distortion to the sound. I think this would be a value where the dvb's little amp produces a gain of 0dB, no? Any idea what this value might be for a TT FF rev. 1.5/1.6? Thank you Sebastian ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] dvb_ttpci/STV0297 corrupted stream / need to reload the driver
Hi there, I have two Technotrend 2300-C in my server. They work pretty fine, but I have to reload the driver all couple of days, because the stream of one card (not always the same) is corrupted. MythTV shows many Started PESPacket, but !payloadstart (see txt file). Also Dvbsnoop shows many errors in the stream, but ber is normal and there are no unc. Starting/stopping MythTV doesn't help and I have to unload/load the dvb_ttpci driver completely to get it working again. I have tested several drivers, but all with the same effect. At the moment I use v4l-dvb-av7110-refactoring-8564d970f69c (patched to show ber/unc) on 2.6.17-hardened-r1 (gentoo). Attached are a corrupted EIT Packet (dvbsnoop-error.txt) and serveral outputs. Have anyone an idea how to solve this. Thanks WolfgangPID: 18 (0x0012) [= assigned for: DVB Event Information Table (EIT)] Guess table from table id... EIT-decoding Table_ID: 107 (0x6b) [= Event Information Table (EIT) - other transport stream, schedule] section_syntax_indicator: 0 (0x00) reserved_1: 0 (0x00) reserved_2: 2 (0x02) Section_length: 650 (0x028a) Service_ID: 20594 (0x5072) [= --> refers to PMT program_number] reserved_3: 1 (0x01) Version_number: 23 (0x17) current_next_indicator: 1 (0x01) [= valid now] Section_number: 122 (0x7a) Last_Section_number: 101 (0x65) Transport_stream_ID: 29555 (0x7373) Original_network_ID: 25189 (0x6265) [= >>ERROR: not (yet) defined... Report!<<] Segment_last_Section_number: 103 (0x67) Last_table_id: 105 (0x69) [= Event Information Table (EIT) - other transport stream, schedule] Event_ID: 28270 (0x6e6e) Start_time: 0x2067656765 [= 1882--3--26 65:67:65 (UTC)] Duration: 0x06e2073 [= 6e:20:73 (UTC)] Running_status: 3 (0x03) [= pausing] Free_CA_mode: 0 (0x00) [= unscrambled] Descriptors_loop_length: 2405 (0x965) DVB-DescriptorTag: 98 (0x62) [= frequency_list_descriptor] Descriptor_length: 101 (0x65) reserved_1: 27 (0x1b) coding_type: 2 (0x02) [= cable] Centre_frequency: 204de46e (= 204d.e46e MHz) Centre_frequency: 6e657220 (= 6e65.7220 MHz) Centre_frequency: 61757320 (= 6175.7320 MHz) Centre_frequency: 50726574 (= 5072.6574 MHz) Centre_frequency: 7a696e20 (= 7a69.6e20 MHz) Centre_frequency: 77656765 (= 7765.6765 MHz) Centre_frequency: 6e20566f (= 6e20.566f MHz) Centre_frequency: 6c6b7376 (= 6c6b.7376 MHz) Centre_frequency: 65726865 (= 6572.6865 MHz) Centre_frequency: 747a756e (= 747a.756e MHz) Centre_frequency: 678a2a20 (= 678a.2a20 MHz) Centre_frequency: 22576972 (= 2257.6972 MHz) Centre_frequency: 2066fc72 (= 2066.fc72 MHz) Centre_frequency: 20536b6f (= 2053.6b6f MHz) Centre_frequency: 6d697363 (= 6d69.7363 MHz) Centre_frequency: 6820696e (= 6820.696e MHz) Centre_frequency: 20646965 (= 2064.6965 MHz) Centre_frequency: 73657220 (= 7365.7220 MHz) Centre_frequency: 46616d69 (= 4661.6d69 MHz) Centre_frequency: 6c69656e (= 6c69.656e MHz) Centre_frequency: 6b6f6df6 (= 6b6f.6df6 MHz) Centre_frequency: 64696520 (= 6469.6520 MHz) Centre_frequency: fc626572 (= fc62.6572 MHz) Centre_frequency: 2065696e (= 2065.696e MHz) Centre_frequency: 656e204d (= 656e.204d MHz) DVB-DescriptorTag: 97 (0x61) [= short_smoothing_buffer_descriptor] Descriptor_length: 110 (0x6e) sb_size: 1 (0x01) [= 1536 Bytes] sb_leak_rate: 27 (0x1b) [= 6.0 Mbit/s] reserved: : 2c 20 64 65 72 20 73 69 63 68 20 69 6e 20 65 69 , der sich in ei 0010: 6e 65 6e 20 48 75 6e 64 20 76 65 72 77 61 6e 64 nen Hund verwand 0020: 65 6c 74 2c 20 6e 61 63 68 64 65 6d 20 65 72 20 elt, nachdem er 0030: 76 6f 6e 20 65 69 6e 65 6d 20 73 65 6c 74 73 61 von einem seltsa 0040: 6d 65 6e 20 4b f6 74 65 72 20 67 65 62 69 73 73 men K.ter gebiss 0050: 65 6e 20 77 69 72 64 2e 20 5a 75 66 e4 6c 6c 69 en wird. Zuf.lli 0060: 67 20 73 74 f6 df 74 20 65 72 20 61 75g st..t er au DVB-DescriptorTag: 102 (0x66) [= data_broadcast_id_descriptor] Descriptor_length: 32 (0x20) Data_broadcast_ID: 25701 (0x6465) [= >>ERROR: not (yet) defined... Report!<<] ID_selector_bytes: : 6e 20 68 65 69 6d 74 fc 63 6b 69 73 63 68 65 6e n heimt.ckischen 0010: 20 50 6c 61 6e 20 65 69 6e 65 73 20 62 f6 Plan eines b. DVB-DescriptorTag: 115 (0x73) [= default_authority_descriptor] Descriptor_length: 101 (0x65)
Re: [linux-dvb] AGC settings for dtt761x, removal of lgh06xf driver
Trent Piepho wrote:
> On Mon, 26 Feb 2007, Michael Krufky wrote:
>> Trent Piepho wrote:
>>> I think the problem is not with firmware for the tuner, but firmware for
>>> the bridge. For instance, all the other dvb-pll tuners used in cxusb.c
>>> have NULL specified for the i2c adapter.
>> That is just a correlation. Those that you are thinking of are mt352 and /
>> or
>> zl10353-based frontends, which have the tuners behind the demod in the i2c
>> path.
>> This is a non-issue for the LG H06xF -- I promise you that. I tested your
>> changes with the cxusb driver and it works just fine.
>
> I remember someone on IRC having a problem with some device, I don't
> remember which one, where the dvb-pll probe would fail the first time the
> drivers were loaded after a cold boot, but if the module was re-loaded it
> would work the second time. The problem was the the tuner wasn't reachable
> over I2C until after some more initialization was done. Not like an Mt352,
> where the tuner is never reachable.
That was the Avermedia A180, using the nxt2004 demod, which needs to have its
firmware loaded before attempting to communicate with the tuner via i2c.
I repeat: this is not an issue for the LG TDVS H06xF
>>> I thought about that, but there are a dozen other drivers that use DVB_PLL,
>>> and all of them select it unconditionally. The DVB_PLL entry is a "hidden"
>>> one with no name that won't show up it the config menu. Of course, there
>>> is no reason a separate patch can't add the ability to turn DVB_PLL on or
>>> off from the DVB_FE_CUSTOMISE menu.
>> That's a good point... but the detail that you are missing is the fact that
>> those other drivers have static calls to dvb_pll_configure() ... Due to that
>> fact, those drivers _require_ dvb-pll (until they get cleaned up /
>> refactored)
>>
>> The changes that you are making here only introduce usage of dvb-pll using
>> dvb_attach() , so the presence of dvb-pll is optional.
>
> Unfortunately, that doesn't work. For example, b2c2-flexcop.ko only uses
> dvb_pll in this one line in flexcop-fe-tuner.c:
>dvb_attach(dvb_pll_attach, fc->fe, 0x61, NULL,
> &dvb_pll_samsung_tbmv);
>
> But try compiling without dvb-pll: (* see note)
> WARNING: "dvb_pll_samsung_tbmv"
> [/home/xyzzy/v4l-dvb-quick/v4l/b2c2-flexcop.ko] undefined!
>
> And loading the module:
> b2c2_flexcop: Unknown symbol dvb_pll_samsung_tbmv
>
> Only the first parameter of dvb_attach() is a dynamic or weak reference,
> the rest are normal.
>
> In order to make dvb-pll dynamically loaded like the front-end modules,
> something needs to be done to get rid of the static references to the pll
> descriptions.
You're right There's no sense in breaking the pll descriptions up into separate
files simply for the sake of making dvb-pll optional. It is more valuable,
IMHO,
to have all of the descriptions stored in a central location so that they can be
shared amongst multiple card-level drivers.
> The v4l tuner module gives each PLL description a numeric ID. That way
> they can be referred to without using any symbols from the tuner module.
>
> Another way would be to refer to the description by name,
> "dvb_pll_samsung_tbmv", and then have the dvb_pll_attach() function use
> symbol_get() to turn the name into an address.
>
> Or do the same thing, but somehow have dvb_attach(), or some variant of it,
> be the one to call symbol_get(). e.g. dvb_attach_pll(dvb_pll_samsung_tbmv,
> fc->fe, 0x61, NULL) which will use &dvb_pll_samsung_tbmv or
> symbol_get("dvb_pll_samsung_tbmv") depending on whether dynamic attachment
> is on or off, the same way dvb_attach() works.
I'm not so against either of these options, but let's save it for a separate
change later on. This is the sort of thing that would need an RFC on the
linux-dvb list before moving forward. For now, let's move on with dvb-pll
statically linked in.
> Or put the PLL descriptions inside the card drivers that uses them. The
> could go in the card drivers' code, or in a common header file (like
> dvb-pll.h). I think if they are static with __attribute__((unused)), then
> gcc won't actually put them into the object file, or emit a warning, if
> they aren't used.
I'm against this option. (see above)
> * note about modpost undefined symbol warnings
> In order for these to work, you must edit your kernel's Module.symvers file
> and delete all the v4l/dvb symbols. Otherwise modpost will think it's ok
> for dvb-pll symbols to be undefined in the v4l-dvb Hg compile, since it
> will find those symbols from your kernel compile. You should also delete
> v4l/Module.symvers. make clean and make distclean don't delete it like
> they should. So if you had dvb-pll enabled on a previous compile, the
> dvb-pll symbols will still be in v4l/Module.symvers after you disable
> dvb-pll.
Cheers,
Mike
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinf
Re: [linux-dvb] AGC settings for dtt761x, removal of lgh06xf driver
On Mon, 26 Feb 2007, Michael Krufky wrote:
> Trent Piepho wrote:
> > I think the problem is not with firmware for the tuner, but firmware for
> > the bridge. For instance, all the other dvb-pll tuners used in cxusb.c
> > have NULL specified for the i2c adapter.
>
> That is just a correlation. Those that you are thinking of are mt352 and / or
> zl10353-based frontends, which have the tuners behind the demod in the i2c
> path.
> This is a non-issue for the LG H06xF -- I promise you that. I tested your
> changes with the cxusb driver and it works just fine.
I remember someone on IRC having a problem with some device, I don't
remember which one, where the dvb-pll probe would fail the first time the
drivers were loaded after a cold boot, but if the module was re-loaded it
would work the second time. The problem was the the tuner wasn't reachable
over I2C until after some more initialization was done. Not like an Mt352,
where the tuner is never reachable.
> > I thought about that, but there are a dozen other drivers that use DVB_PLL,
> > and all of them select it unconditionally. The DVB_PLL entry is a "hidden"
> > one with no name that won't show up it the config menu. Of course, there
> > is no reason a separate patch can't add the ability to turn DVB_PLL on or
> > off from the DVB_FE_CUSTOMISE menu.
>
> That's a good point... but the detail that you are missing is the fact that
> those other drivers have static calls to dvb_pll_configure() ... Due to that
> fact, those drivers _require_ dvb-pll (until they get cleaned up / refactored)
>
> The changes that you are making here only introduce usage of dvb-pll using
> dvb_attach() , so the presence of dvb-pll is optional.
Unfortunately, that doesn't work. For example, b2c2-flexcop.ko only uses
dvb_pll in this one line in flexcop-fe-tuner.c:
dvb_attach(dvb_pll_attach, fc->fe, 0x61, NULL,
&dvb_pll_samsung_tbmv);
But try compiling without dvb-pll: (* see note)
WARNING: "dvb_pll_samsung_tbmv" [/home/xyzzy/v4l-dvb-quick/v4l/b2c2-flexcop.ko]
undefined!
And loading the module:
b2c2_flexcop: Unknown symbol dvb_pll_samsung_tbmv
Only the first parameter of dvb_attach() is a dynamic or weak reference,
the rest are normal.
In order to make dvb-pll dynamically loaded like the front-end modules,
something needs to be done to get rid of the static references to the pll
descriptions.
The v4l tuner module gives each PLL description a numeric ID. That way
they can be referred to without using any symbols from the tuner module.
Another way would be to refer to the description by name,
"dvb_pll_samsung_tbmv", and then have the dvb_pll_attach() function use
symbol_get() to turn the name into an address.
Or do the same thing, but somehow have dvb_attach(), or some variant of it,
be the one to call symbol_get(). e.g. dvb_attach_pll(dvb_pll_samsung_tbmv,
fc->fe, 0x61, NULL) which will use &dvb_pll_samsung_tbmv or
symbol_get("dvb_pll_samsung_tbmv") depending on whether dynamic attachment
is on or off, the same way dvb_attach() works.
Or put the PLL descriptions inside the card drivers that uses them. The
could go in the card drivers' code, or in a common header file (like
dvb-pll.h). I think if they are static with __attribute__((unused)), then
gcc won't actually put them into the object file, or emit a warning, if
they aren't used.
* note about modpost undefined symbol warnings
In order for these to work, you must edit your kernel's Module.symvers file
and delete all the v4l/dvb symbols. Otherwise modpost will think it's ok
for dvb-pll symbols to be undefined in the v4l-dvb Hg compile, since it
will find those symbols from your kernel compile. You should also delete
v4l/Module.symvers. make clean and make distclean don't delete it like
they should. So if you had dvb-pll enabled on a previous compile, the
dvb-pll symbols will still be in v4l/Module.symvers after you disable
dvb-pll.
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] dvbstream pat pmt dosen't work, wrong dvbstream version?
Ali H.M. Hoseini wrote: could I have your patch for scan, that adds correct pmt_pid? uhm, dvb-apps from hg still doesn't dump the pmt_pid in channels.conf, thus scan it still broken. I wonder why none of the developers cares enough to fix it. Patch is here; hopefully it still applies http://www.linuxtv.org/pipermail/linux-dvb/2005-December/007257.html -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Crea il tuo sito web dinamico con PHP e MySQL - VideoCorso professionale direttamente nel tuo computer. Trucchi e segreti Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=5142&d=27-2 ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
