On Tue, Oct 14, 2003 at 12:16:54PM +1000, Brian McKerr wrote:
> G'day all,
>
> I've just purchased a Nebula DVB-t PCI card, works a treat under windows but I'm
> having some difficulty getting it working
> under linux. I'm using slackware 9.1 which has a 2.4.22 kernel, and have followed
> th
G'day all,
I've just purchased a Nebula DVB-t PCI card, works a treat under windows but I'm
having some difficulty getting it working
under linux. I'm using slackware 9.1 which has a 2.4.22 kernel, and have followed the
HOWTO here;
http://www.linuxtv.org/mailinglists/linux-dvb/2003/07-2003/
Hi Johannes,
did you modified the CRC check so that you will only check packets with
section syntax indicator=1? Doing so in general would be a bad idea i
think, I would rather add a new DMX_CHECK_CRC_SSI suggest this semantic:
DMX_CHECK_CRC not set - always pass packets
DMX_CHECK_CRC
Gerd Knorr wrote:
There are a number of buttons where are no good KEY_* defines for yet
(color/contrast/hue, bass/trable/balance, ...) btw.
Can you please prepare a list of required keys for Vojtech, I'm sure he
will add them then to the API include files?
The device type may be identified using
Received
First check the signal by running apps/szap/femon along with vdr.
tvt1:/opt/vdr/DVB/apps/szap# ./femon
using '/dev/dvb/adapter0/frontend0'
FE: STV0299/TSA5059/SL1935 based (SAT)
status 1f | signal a9f2 | snr e142 | ber ff00 | unc |
FE_HAS_LOCK
status 1f | signal a9c9 | snr e
Michael Hunold wrote:
Hello Holger,
Different demux devices with included filter capabilities suggest to
the user that there's hardware behind it. This is currently not the
case for any hardware out there.
It is. Whenever we implemented multiple demux devices for an adapter
each of them stand
Michael Hunold wrote:
Hello Holger,
I'd really like to know what stuff is not covered by my approach and
why you think it's too high level.
It makes abstractions that don't match any hardware I know. I don't
know any hardware that has real stream filters in the decoder units.
But some hardwa
On Monday 13 October 2003 14:33, Gerd Knorr wrote:
> Vojtech Pavlik <[EMAIL PROTECTED]> writes:
>
> > > It should be possible to read the current keymap from the device.
> > > This way one could write something like a keymap editor, or
> > > add another remote control to a loaded keymap.
> >
> >
Hi Johannes,
> Michael, could you please update and test angain with hw_sections=0
> so we can find out whether this change actually fixes the
> dvb_net problem?
I checked the new CVS driver, but it still looses a lot of packets (I think
it was around 7%). With hw_sections=1 this driver works
On Monday 13 October 2003 12:07, Vojtech Pavlik wrote:
> On Mon, Oct 13, 2003 at 05:41:12AM +0200, Oliver Endriss wrote:
>
> > Basically we need 2 pass-through ioctls:
> > - set low level configuration
> > - get low level configuration
>
> I'm not really keen on passing ioctl()s to drivers, but i
On Monday 13 October 2003 11:00, Holger Waechtler wrote:
> Oliver Endriss wrote:
> > I'm not sure whether a 'get protocol types' ioctl is really useful.
> > For example, the full-featured DVB-S cards support RC5 and RCMM, but
> > most optical receivers shipped with these cards cannot receive RCMM.
Michael Hunold wrote:
>
> I don't want to get rid of the "demux" devices, I just think that the
> filters shouldn't be a part of them. Again: if the user has multiple
> demuxes and can set multiple PID filters, he might think that these
> filters are part of the demux. And this isn't the case f
First check the signal by running apps/szap/femon along with vdr.
Since I've never used this tools before what output can I expect from a
good/bad signal?
If recording works on some channels it is unlikely that it is
a DMA issue, it's more likely that the signal is weak or that
there is interfere
[EMAIL PROTECTED] wrote:
>
> If have two identical systems (P4, 2.6 GHz, 1 GB RAM) where only the dvb-s
> card differ. One system uses two rev 1.6 card while the other uses two
> nova-s budget cards. On the budget card system I can't record several
> channels including Sat1, Pro7, Pro7 Oesterre
Vojtech Pavlik <[EMAIL PROTECTED]> writes:
> > It should be possible to read the current keymap from the device.
> > This way one could write something like a keymap editor, or
> > add another remote control to a loaded keymap.
>
> Well, it is currently possible to read a keymap from a keyboard v
Hello Holger,
Different demux devices with included filter capabilities suggest to
the user that there's hardware behind it. This is currently not the
case for any hardware out there.
It is. Whenever we implemented multiple demux devices for an adapter
each of them stands for an independent de
Hello Holger,
I'd really like to know what stuff is not covered by my approach and
why you think it's too high level.
It makes abstractions that don't match any hardware I know. I don't know
any hardware that has real stream filters in the decoder units.
But some hardware has specialized filter
On Mon, Oct 13, 2003 at 05:41:12AM +0200, Oliver Endriss wrote:
> Basically we need 2 pass-through ioctls:
> - set low level configuration
> - get low level configuration
I'm not really keen on passing ioctl()s to drivers, but if there is no
other way around, then well ...
> Each of these ioctls
Oliver Endriss wrote:
On Sunday 12 October 2003 16:30, Holger Waechtler wrote:
Oliver Endriss wrote:
On Sunday 12 October 2003 10:35, Holger Waechtler wrote:
Oliver Endriss wrote:
The current implementation has a number of restrictions:
- Permissions of /proc/av7110_ir cannot be changed witho
19 matches
Mail list logo
