Johannes Stezenbach writes:
What Jean writes only applies if you have a struct i2c_client
and i2c_driver to work with. the you can do lokcing in the
i2c_driver.
But we don't, IIRC because of problems with bus probing
done yb the i2c-core.
Not having an i2c_client is also the reason
Bernhard Rosenkraenzer writes:
On Saturday, 24. February 2007 22:33, Bernhard Rosenkraenzer wrote:
Tuning works, so does recording stuff through DMX_SET_PES_FILTER (input =
DMX_IN_FRONTEND, output = DMX_OUT_TS_TAP, flags = DMX_IMMEDIATE_START).
Actual DVB-S2 channels don't seem to
Mauro Carvalho Chehab writes:
manufactured by a plethora of vendors (Technotrend, Hauppauge, Galaxis
and many others ) making it very popular. These cards are popularly
knowns as the AV7110 based Full Fledged (FF) cards.
If the mpeg implementation on DVB API is generic enough to
Klaus Schmidinger writes:
I'm wondering how an application is supposed to handle
devices with multiple frontends.
Let's assume a device that provides
dvb/adapter0/frontend0DVB-S
dvb/adapter0/frontend1DVB-T
so that it can receive both DVB-S and DVB-T. Does
Klaus Schmidinger writes:
Benny Amorsen wrote:
KS == Klaus Schmidinger [EMAIL PROTECTED] writes:
KS The whole HDTV thing is of no interest to me until there is a DVB
KS card that can actually replay HDTV in hardware.
Why would it have to be the DVB card doing it? That seems
Klaus Schmidinger writes:
matthieu castet wrote:
matthieu castet wrote:
Hi,
Does somebody know why scan dvb-util or vdr failed to parse video
pid of hdtv stream ?
Why a patch like the attached one couldn't be added ?
After some reflexion, a new category (video hd)
Steven Toth writes:
The simple thing about a solution like this is that:
a. a/t/szap -a fenum worked with zero changes.
b. The recent cx88 bus arbitration patches ensured that only one of
adapter0/fe0 or adapter1/fe could be opened at any one time. (As expected).
I don't see solution
Robert Schlabbach writes:
From: [EMAIL PROTECTED]
just a head's up that there is a new DVB-T PCI device from Lifeview
which is out and on store shelves in Australia.
Interesting. Lifeview has had several different DVB-T PCI cards on their
website for a while, but I never heard of
Kenneth Aafløy writes:
On Wednesday 21 July 2004 00:34, Ralph Metzler wrote:
[snip]
Alternative: get the i2c_adapter pointer via sub_device,
lock it, (in case of linuxtv driver, change i2c adapter name),
scan it for already present clients, init them,
How
Gerd Knorr writes:
Alternative: get the i2c_adapter pointer via sub_device,
lock it, (in case of linuxtv driver, change i2c adapter name),
scan it for already present clients, init them,
How the initialization is done?
Via i2c client command calls. FE_REGISTER
Gerd Knorr writes:
The sub-drivers get passed a pointer to struct bttv_core which should
have everything you need. There are a few helper functions for gpio
access which accept bttv_core to identify the correct card. There is a
pointer to the pci_dev, so you can look for the matching .1
Gerd Knorr writes:
The only place where this happens is in the attach_inform
function of the bttv driver. Currently, only the analog tuners and audio
controllers are initialized there. So, that's the natural place to
also initialize DVB frontends. Of course the dvb_adapter pointer
Kenneth Aafløy writes:
On Sun, Jul 18, 2004 at 01:04:02AM +0200, Kenneth Aafløy wrote:
On Sunday 18 July 2004 00:09, Ralph Metzler wrote:
No, I also considered this before implementing the FE_(UN)REGISTER
stuff but adapters with more than one I2C bus/frontend will not work
Johannes Stezenbach writes:
from their attach_adapter() function. However, if the frontend driver
is loaded after the i2c adapter driver, but before the DVB driver,
registration would fail. To solve this I would need a second list
to keep track of known-but-not-yet-registered frontends.
Kenneth Aafløy writes:
It was expected, as the bt878 driver has not been updated yet. Anyways, I have
had a look at the bttv driver and there's really no clean way of using the
FE_REGISTER/FE_UNREGISTER i2c client commands. As I see it, ideally the
frontends should not have to know
Kenneth Aafløy writes:
On Sunday 18 July 2004 00:09, Ralph Metzler wrote:
No, I also considered this before implementing the FE_(UN)REGISTER
stuff but adapters with more than one I2C bus/frontend will not work like
this. It also makes the frontend driver and dvbdev depend on I2C
Johannes Stezenbach writes:
Jeremy Jones wrote:
Is it possible to read/write directly to the av7110 registers or does
it require an interface from the firmware ?
No/Yes.
I want to use the 1/4th
decimation mode of the av7110 to shrink the video window. The
docuemntation
Uli Luckas writes:
Am Montag, 21. Juni 2004 01:08 schrieb Kenneth Aafløy:
On Sunday 20 June 2004 19:45, Uli Luckas wrote:
This seems to be caused by the kernel I2C tarnsition recently done.
Frontends like stv0299 expect to find the exact card name in ((struct
i2c_adapter *)
Brad Campbell writes:
Måns Rullgård wrote:
204, it's got something to do with error correction.
I wrote that bit of the driver :p) (All 5 lines of it, Jamie did the heavy lifting)
iirc they forget to tell the tuner module to strip the ecc bytes from the back of
the TS
Andrew de Quincey writes:
Is that like the CI interface on a full featured TT card? I _think_ those have
a CiMAX chip on 'em. If it is there are docs on it here.
http://www.atmel.com/dyn/products/product_card.asp?part_id=2356
(The Atmel T90FJR seems to be derived from the CiMAX)
Hi,
Jeff [EMAIL PROTECTED] (by way of Manu Abraham [EMAIL PROTECTED]) writes:
Hi,
This is the message that i received from Twinhan. I had been asking them for
quite some time to publish the documentation/src for their drivers. They were
very reluctant to do so, saying that their
Alasdair FARMER writes:
2) With regard to playback of recordings I am unclear how this will work in the
new model... If a recorded stream were being written to a demux then which
instance (given that the handle is actually to a filter rather than a demux
itself). I am not convinced
Andrew de Quincey writes:
Sure, thats what I was intending to do. However, I need to finish it first in
line with these new ideas (I've kept the old code though, but that does not
work as I was still debugging it).
I'd like to hear Ralph's or Marcus's opinion, as they originally
Kenneth =?iso-8859-1?q?Aafl=F8y?= writes:
On Saturday 20 March 2004 02:04, Ralph Metzler wrote:
Kenneth Aafløy writes:
A problem with your mail client Ralph?
Maybe Ralph has some insight into wether it breaks the original KNC1
card?
I am the wrong person to ask. We
Andrew de Quincey writes:
If you look in dvb_frontend_thread(), there is a main loop with the following call:
timeout = wait_event_interruptible_timeout(fe-wait_queue,0 !=
dvb_frontend_is_exiting (fe), delay);
This sleeps for a delay of 3*HZ (initially), or until the frontend thread
I get more errors when running setiathome while using czap but this
is on a computer that has lots of errors in windows as well.
It's strange that signal quality is affected by cpu usage (for better or
worse), I mean isn't everything done in hardware when I use the tvout from
Robert Schlabbach writes:
KNC released the specs (no begging and/or disassembling necessary ...)
but the code we wrote is currently bound to a commercial project. It
works since almost a year (at least with the modules without hardware
problems).
One question: Does the KNC CI
Christian Gmeiner writes:
Sorry, no idea if the linuxtv drivers support this card.
You can try the 2.6.x drivers from the last snapshot on our page.
(copy DVB/dvb-kernel directory to your kernel source and select KNC card)
Ok i have tried it, but with 2 warnings:
WARNING:
Oliver Endriss writes:
Also: are there any
budget cards already that have drivers that support CAMs? I have to admit that
I don't know that.
AFAIK there is _no_ budget card driver with CI support under linux.
No public and GPLed ones.
There are drivers for KNC and Twinhan cards.
Robert Schlabbach writes:
AFAIK there is _no_ budget card driver with CI support under linux.
Not yet, although Andrew and I have pretty much figured out how the
hardware works. However, I am out of it for the foreseeable time, because
the only type of CAM I can afford for development
Robert Schlabbach writes:
Aha, that's interesting! My symptoms are a bit different, though: Access to
the attribute memory and to the COR is fine, and the CAM _does_ correctly
That also works fine for me.
map its I/O registers when I write the configuration value to it (0x0F).
CAM reset
Andrew de Quincey writes:
And, unless there is a hardware or firmware CSA descrambler on the
card, you will never be able to decrypt pay-tv in a legal way.
IANAL, but I don't think that anyone can write a CSA descrambler under
GPL.
That's incorrect. You don't
Oliver Endriss writes:
These are two different things. Remember that some receivers only come with
a smart card slot, i.e. they have a builtin CAM. In those, the firmware
implements the algorithm which generates the key pairs (64 bits = 8 bytes),
with which the MPEG-2 transport stream
Kenneth =?iso-8859-1?q?Aafl=F8y?= writes:
I've seen a handfull of posts about this card, but not a real confirmation on
whether it works or not. I'm considering this card as a secondary card for my
MythTV backend, but I have no idea whether it will work or not.
Christian Gmeiner writes:
Oh as you see, i am also using an dxr3 device and an ir-module.
Now i am not sure what combination of teh saa7146 modules i should take. I
have an CI interface on the card, but i am not using it.
It would be great, if somebody could help me.
Maybe one of the
Andrew de Quincey writes:
I can't have this quite right; the AV7110 CA driver in the metzler tree says
it is a CA_CI_LINK, yet it takes transport layer EN50221 packets from my
thinking (which is likely wrong) this should really have another type
CA_CI_TRANSPORT.
The capabilities
Andrew de Quincey writes:
I just spent a while trying to figure out how I would go about using the 2.6
request_firmware() calls for the tda1004x driver. As far as I can see, its
impossible right now.
The problem is you have to pass a struct device* into request_firmware() to
tell
Andrew de Quincey writes:
I am doing it using the normal kernel I2C driver.
Every I2C frontend automatically calls the I2C driver attach callback
where the card driver can configure it accordingly.
The frontend driver does not really need to know anything about higher
level
Andrew de Quincey writes:
Shouldn't a frontend driver (or rather each I2C driver) even get its own
struct driver? I'll do some digging in the 2.6.x code.
Not in the linuxtv dvb kernel tree; it doesn't use i2c-core, so the DVB i2c
drivers only reference a struct dvb_adapter.. hmm..
Johannes Stezenbach writes:
But the latter is probably the better interpretation of the API
intention and on the long term the only way I see to cleanly load
firmwares into MPEG decoders or DSPs in STBs without PCI or USB or i2c
bus (or any other bus with a predefined subsystem
Andrew de Quincey writes:
CENELEC EN50221 implies that you can't write data to the CAM if it has data
waiting to be read by the host. What have other people's implementations done
if a user app attempts to write() data when it is not possible?
I could cache the data to be written... I
Holger Waechtler writes:
Holger Waechtler wrote:
Andrew de Quincey wrote:
Hi, Robert and I are getting on really well with the Nova-CI... we can
talk to the attribute memory of a CAM module now.
We're wondering if anyone has any information on PCMCIA devices; we're
Luca Abeni writes:
Hi all,
On Tue, 2004-01-20 at 13:24, Carlo E. Prelz wrote:
Subject: [linux-dvb] Re: Nova-CI: why does opening /dev/dvb/adapter0/ca0
return no such device?
Date: mar, gen 20, 2004 at 02:01:55 +0100
Quoting Johannes Stezenbach ([EMAIL PROTECTED]):
Holger Waechtler writes:
Tomi Ollila wrote:
Monday Jan 12 16:30:03 +0100 2004 Holger Waechtler [EMAIL PROTECTED] wrote:
Marcus Metzler wrote:
Holger Waechtler writes:
In any case you can get a cheap Nova-T for less than 100EUR as reference
you should be able to easily
Egon Single writes:
IMHO it's ok to have firmware in dedicated processors on extension
hardware, as long as you have access to the necessary specifications for
the communication protocol with other parts of the system (which is
lacking for the av7110 firmware I admit)
This means
Emard writes:
'full featured dvb-s card' is simply mis-named because it is not FULL
featured at all!
The feature FULL TS BANDWIDTH, important for large bandwidth downloads
and proper network functioning is simply missing in 'full featured dvb-s cards'
and is only available on
Augusto Cardoso writes:
I may have miss the point here, however, I have run the skystar2 cards at 38Mbps IP
payload speeds without dropping any packets for more than 24 hours. With the
FCII/FCIIB the maximum speed that I got is about 41Mbps. With FCIII I have tested
it at 78Mbps and
Emard writes:
The old code is broken in boundary conditions, dropping some sections
that should have been otherwise correctly received.
Details?
If e.g. one byte of new section starts at the last byte of TS packet,
this section will not be received because the old driver
Michal Dobrzynski writes:
I haven't been able to really do anything butt try and read about it
(because my rev1.5 card has not arrived yet) but I really care about
WSS support via the RGB out (or SVideo for that matter) of the card.
It seems that this would have to be done by setting
[EMAIL PROTECTED] writes:
joint patch), However dvb-s still has some freeze issue, is not
very stable at replaying mpeg, or in general is unstable in large
bi-directional traffic between PC and dvb-s card.
The workqueue strategy seems not to fix all the stability in 2.4
What is this
[EMAIL PROTECTED] writes:
Ralph Metzler writes:
[EMAIL PROTECTED] writes:
joint patch), However dvb-s still has some freeze issue, is not
very stable at replaying mpeg, or in general is unstable in large
bi-directional traffic between PC and dvb-s card.
The workqueue
Steffen Barszus writes:
For me the crashes are gone, but you can sure forget to try dvb/ip over
a nexus. I get data rates of 3-4 kB over the nexus and 120 over a
skystar2. If this could be fixed it would sure be nice, but from
current discussions i read that the card is not designed to
Alexandre CONRAD writes:
For me the crashes are gone, but you can sure forget to try dvb/ip over
a nexus. I get data rates of 3-4 kB over the nexus and 120 over a
skystar2. If this could be fixed it would sure be nice, but from
current discussions i read that the card is not
Alexandre CONRAD writes:
Humm... Would the Skystar2 work ?
Yes.
Does it have an mpeg2 decoder chip ?
No.
I saw there was that TT-PCline Premium-S. Has anyone tested it ? What
That would be the card produced by Technotrend (TT) card which
Hauppauge sells under
[EMAIL PROTECTED] writes:
Alas, it's still a big problem, even the tv out is good, even the cam is
working (only with dvr): there is no vdr teletext subtitles support for
canal+ and canalsatellite set of channels.
And it's a shame !
Thanks very mutch to everyone for the work he's
Roberto Ragusa writes:
[...]
At that point dvrY is totally useless and it could be theorically
removed (but it's better to not break existing apps, of course).
I'm open to suggestions on the matter.
I could try to hack the code myself, but maybe someone else
with more knowledge
Johannes Stezenbach writes:
Emard,
Emard wrote:
So average_network_user wouldn't have to care which PID is there,
and as he szap's also restart network apps to change the dvb0_0
for dvb0_1, but instead just register dvbnet -p 8192 and have one
and only dvb0_0 for all
Holger Waechtler writes:
the dst_frontend driver (and the dec2000_frontend driver too) are
pseudo-i2c device drivers. This makes no sense for these cards since the
driver is working only in conjunction with the dst.o and ttusb_dec.o
driver. As the implement the general attach/detach and
Roberto Ragusa writes:
Every accepted packet is tested twice.
Discarded packets are tested once (and very early).
So we gain here and loose there.
In relation to one of the first checks, do you think that the swfilter
code is fast enough to let us just open_whole_bandwith when we're
[EMAIL PROTECTED] writes:
I planned to support dynamically alloc'ed buffer for purpose
of on-demand stretch or shrinnk buffer as section data creep in.
This is heading toward to allow network all pids reception by dvbnet -p
8192, which is now non-functional because for 8192 we would have
Emard writes:
builds some larger chunks
without PUSI, to still avoid loosing some section data.
(in few tests so far I haven't seen building them over 4096 but..)
If that really happens (doubt it) they are sending a broken stream.
Your truncate_copy prevents access to
Emard writes:
Wise desision, i will test it further, also I'd like to put to_right_place
the #define MAX_SECBUFP 4096 or 16384, instead of having
secbuf_real[4096 or 16384]
+u8 *secbuf;
+u8 secbuf_real[16384];
directy in the struct. Although we know the
Emard writes:
After I read the specs, and I understood what was the functional
purpose of the old code (gosh, what a messy coding) I rewrote
Sorry, I promise I will not publish any code which might be
too messy anymore.
Ralph
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED]
Edward Wildgoose writes:
299 EUR isn't really the price someone would pay for such a card. More
common are prices around 200 EUR. I have asked at such a store and was
told that they sell one in a half year.
Even this is more than twice the price you have to pay for a modern
Hi,
Holger Waechtler writes:
btw: Klaus, you know that the code responsible for synchronisation
issues in the firmware is at least as complex as the code doing the same
in ffplay.c. So everybody who believes he can fix those problems in the
firmware if he had only the source is as
Johannes Stezenbach writes:
Klaus Schmidinger wrote:
Well, AFAICS this old hardware is very widely used, and the main
platform VDR is designed for. And judging from the download volume
every new version of the linvdr distribution causes (according to
Mirko Dölle) VDR must be
Johannes Stezenbach writes:
Pekka Virtanen wrote:
[...]
Can you print that in hex to see if there is just one bit flipped?
Does not look like this is the case here.
The av7110 destroys the adaptation fields if you record and watch
at the same time (record with DMX_PES_OTHER to
Johannes Stezenbach writes:
Ralph Metzler wrote:
Johannes Stezenbach writes:
The av7110 destroys the adaptation fields if you record and watch
at the same time (record with DMX_PES_OTHER to prevent this). However,
the DMX_GET_STC should give you correct values. Also, AFAIK
Emard writes:
While testing some more on network packet loss,
here I must review my statement about TS and PID bandwidth!
I think that so called 'section' code in dvb_demux.c is
not working 100% correctly and must be reviewed.
How exactly do you measure the packet loss?
Can you
Emard writes:
See my previous posts where I posted the actual snapshots and indicated
the exact points of loss. Just count the dots between two missing ones
and convert it to percentage. Each dot represents a packet of nearly 1500
bytes
Yes, sorry, I remember your posts.
While they prove
Emard writes:
If I took the TS of something predictable and outputting result, I could
binary search in the TS and find it or at least locate neighbouring packets
that are before and after the missing one, so in the TS the missing one
should be located inbetween them most
Robert Schlabbach writes:
From: Emard [EMAIL PROTECTED]
Some issues seem more like a bug than graceful recovery,
particularly the fact that the SAA7146A will sometimes not _finish_
DMA transfers. With burst and FIFO threshold set to 4 Dwords, the
chip _randomly_ does not DMA
Asier Aguirre writes:
[1 text/plain; us-ascii (7bit)]
Hi there, I've found a flaw in dvb_demux.c. The value of 'count' in line
269 (see patch) is not granted to be a positive value, yielding in a
kernel segfault in the memcopy of line 292, and then hanging the system.
[...]
+++
Claas Hilbrecht writes:
A Flyvideo DVB-S with SU1278/SHA is working fine for me.
I think there were some register settings to be changed but I do not
remember the specifics right now. I'll have to look it up.
Of course I do not know if these settings would also work with the
Torsten Duwe writes:
The board has B2S1100, Rev.1.0 and TT2002.9 written on it. The parts
are the regular SAA7146A and the new SU1278/SHA tuner frontend (note the last
A !), which in turn holds the expected stv0299, in a B revision, a TDA
8060TS, an A5059 and a 4.000 xtal, in case any of
Robert Schlabbach writes:
From: Ralph Metzler [EMAIL PROTECTED]
A Flyvideo DVB-S with SU1278/SHA is working fine for me.
I think there were some register settings to be changed but I do not
remember the specifics right now. I'll have to look it up.
Of course I do not know
Michael Hunold writes:
Therefore they don't know what a PID is. So why should the
A/V PIDs be given to the mpeg decoder device? The Transport Demux has to
know them, so it can deliver the demultiplexed data to the decoder.
The more advanced hardware I know has a design like this:
-
Holger Waechtler writes:
I'm not aware of any chipset without a dedicated demultiplexer unit, are
you?
(just to get the convention clear: The Demultiplexer seperates a
multiplexed - a concatenated stream of packets with different packet IDs
- and routes the packets to the destination
[EMAIL PROTECTED] writes:
How should we treat the DVB_DMX_START and DVB_DMX_STOP ioctls for an fd
that has many PID filters associated with it? Should these ioctls START
and STOP all filters attached to the fd simultaneously, or would it be
better to single out specific filters to START
Robert Martin - inmedia writes:
1. Has anyone had success using the DVB driver with a budget type KNC1
card?
2. Does anyone know what the problem is with the module installation
hanging?
3. Does anyone know the position the kernel drivers are in to support KNC1,
especially the
Robert Schlabbach writes:
From: Ralph Metzler [EMAIL PROTECTED]
The problem is with frontend sleeping not a general standby. GPIO 2
only works with the full feature cards and would also put the AV7110
into reset.
FWIW, this does not match my observations. On all my three
Nathan Whittacre writes:
Thank you for your response. Are there any plans to implement the CI
protocol in the budget cards? If not, for what reasons? Also, what
For KNC cards we have written binary only drivers which are only used
in complete PC based STBs right now. They might be
Johannes Stezenbach writes:
LINUXTV DEV wrote:
#define CA_CI 1 /* CI high level interface */
#define CA_CI_LINK 2 /* CI link layer level interface */
#define CA_CI_PHYS 4 /* CI physical layer level interface */
#define CA_SC 128 /* simple smart card interface */
CA_CI_PHYS
Oliver Endriss writes:
On Friday 26 September 2003 14:52, Bruno Hellstern wrote:
...
here ist the output of both cards, 1st without subsystem:
00:0d.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
Flags: bus master, medium devsel, latency 64, IRQ 10
Hi,
I always thought this no return from standby problem only occurs on
cards with SU1278/SHA. On KNC and Hauppauge cards (at least on mine)
this problem was not so bad.
Robert Schlabbach writes:
From: Oliver Endriss [EMAIL PROTECTED]
Update:
| Sep 26 00:52:01 orion kernel:
[EMAIL PROTECTED] writes:
Both, one section filter for several PIDs and several filters on one
PID, would be useful to have on one file descriptor in some special
cases. But both make the demuxer more complicated and only move
complexity from user space into the kernel. It is not too
[EMAIL PROTECTED] writes:
I beg to differ on this. If you have a look at dvb_demux.c there is the
function dvb_dmx_swfilter_section_feed that gets called when we have some
section data available from the h/w. In this function we have a pointer to
a dvb_demux_filter that is set from
FilterParameters:
Filter:
46 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Mask:
ff 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
iFilterHandle:5 PId:11 TId:46 Mask:ff
42 f1 e1 7 f8 df 0 0 0 2 ff 12 60 fd 90 4c 48 10 1 5 42 53 6b 79 42 8 53 6b
79 20 4e 65 77 73 49 7 ff 47
Thomas Haase writes:
(Filter Parameters:
Filter 1:
42 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Filter 2:
46 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Mask all to 0
)
[...]
This happens even if I'm using the filters in Hardware or Software mode.
Where is my
=?ISO-8859-1?Q?R=E9gis_Bossut?= writes:
A long time ago, there was an API named GetDecoderStatus for requesting
information about the MPEG decoder state registers from the AV7110. The
REQCOM enum still shows AudioState and VideoState[1-3]. Is there (has
there always been) still valuable
Max Kiva writes:
Hi Oliver
The manufacturer is VVmer in Taiwan. Card is called [EMAIL PROTECTED]
dump follows:
This is not a DVB card but a hardware MPEG2 encoder card and probably
not supported by any Linux driver yet.
What are the names of the other chips on the card?
The DVB cards
Klaus Schmidinger writes:
Anyway, we could do the following:
- set a flag before tuning
- in dvb_frontend_thread(): call FE_RESET ony if the flag is set
- reset the flag when we get FE_HAS_LOCK
- FE_RESET will not be called if FE_HAS_LOCK drops out for short
periods on an
Rene Bartsch writes:
obviously nobody is responsible for the functions setting the
PCI-latency to 64 in DVB-driver (maybe that functions just dropped in
while flying from venus to mars ... ;o) ).
According to CVS logs it was introduced in revision 1.12 of the file.
(Of course this could
Matthew Davis writes:
I have been searching the list on information about driver CI support with
different cards. The extent of driver support is still somewhat unclear. As
I understand it, the Hauppauge Nexus CI can be used, while the Nova cannot.
I have seen references indicating
Johan van Sterkenburg writes:
I'm trying to use my DVB-s/CAM-module to tune to NED1/NED2/NED3/TMF/...other
dutch channels.
I use:
Software:
(from the metzler brothers)
-DVB driver version 1.1.7
-libdvb 0.4.1
-tuxzap_programs 0.4.1 - RTuxZap
Michael Glaum writes:
Johannes Stezenbach writes:
The current DVB drivers from CVS try to get the MAC from the eeprom
on the card and use it as default. I don't know if the code which
reads the epprom is correct.
Ralph Metzler writes:
Only for TT based cards and only
Johannes Stezenbach writes:
Since the Filiago-Proxy is proprietary (binary-only), I don't know what
it does. I guess it joins one or more multicast-groups. It's possible
that the code which sets the DVB filters according to the multicast
addresses has bugs.
As far as I have
Robert Schlabbach writes:
FWIW, I found the IICSTA bug with a Siemens DVB-Cable card, which had an
SAA7146A with a manufacturing date in 2000 on it (if I understand the
markings on the chip correctly). Maybe Philips has fixed the bug in an
updated revision of the chip...?
As to the
Robert Schlabbach writes:
But, take a look at http://forum.digitalfernsehen.de - I just found the
following post there (in German, sorry to the non-German speakers here):
Ursprünglich sollte DVB-T in NRW bereits am 1.1.2004 im Raum Köln/Bonn in
den Regelbetrieb gehen. Allerdings wurde
Robert Schlabbach writes:
From: Ralph Metzler [EMAIL PROTECTED]
Robert Schlabbach writes:
The problem is that noone has a card with the TDA10046H yet
(well, actually I have one, but it is SAA7134-based...)
Why is that a problem? The PCI bridge does not really matter
1 - 100 of 343 matches
Mail list logo
