On 01/16/08 14:51, Stephen Rowles wrote:
A long time ago multiproto was said to be integrated in *near* future...
to my great disapointment it still isn't, which is certainly not a good
thing for the user at least...
Could we hope to be *near* inclusion now ?
In the meantime I am really
On 09/27/07 16:33, Christoph Pfister wrote:
Can somebody offical from vdr confirm this patch (sorry, I don't know the
who's-who there)?
Because only vdr output format is affected and I don't think people use that
format for other purposes than vdr, I don't see any reason against applying
Dominique Dumont wrote:
...
For low level CI API, i.e. Hauppauge TT cards), the CI stack is ~90%
implemented in software in the DVB application.
For high level CI (i.e Twinhan and clones), the stack is half
implemented in firmare (i.e. bugs can't be fixed) and half in software
in the
Trent Piepho wrote:
On Sun, 7 Jan 2007, Klaus Schmidinger wrote:
If I use the latest driver from
http://linuxtv.org/hg/~endriss/v4l-dvb-av7110-refactoring
there are apparently dependencies missing in some *.ko files, so my script
can't find out which additional modules to load.
For example
Manu Abraham wrote:
...
There are 2 different cases
(1) multiple frontends sharing the same TS interface
(2) multiple frontends, each having it's own TS interface.
Maybe those should be handled like one multi-protocol frontend?
Not sure if Manu's multi-proto stuff would also
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 this
mean that it can simultaneously receive
I'm using a modified version of the v4l/scripts/rmmod.pl script to
be able to state only the high level driver modules I know I need to
load, and have the script find out what other modules these depend on
and automatically load them, too, as in
rmmod.pl load dvb-ttpci budget
for a system with
Otto J. Makela wrote:
Klaus Schmidinger wrote:
There is no CAM message in your log.
There should be a line like
Nov 17 17:38:20 video vdr: [2906] CAM: AlphaCrypt, 01, 4A20, 4A20
which indicates that VDR has established communication
with the CAM.
True, not in that log, but it does appear
Otto J. Makela wrote:
I'm using the pre-packaged vdr-1.4.3-3.fc5 and vdr-subtitles-0.4.0-6.fc5 from
//fedora.redhat.com/pub/fedora/linux/extras/5/i386/
It seems this pre-packaged vdr fails to work with a full-feature Technotrend
with a CAM, it just fails with no useful data seen when it tries
Nico Sabbi wrote:
Andrea Venturi wrote:
Klaus Schmidinger wrote:
No - and it won't.
TS is for broadcasting, and PES is for recording.
is this just a personal opinion?
me, actually i can see a great move toward TS also for storing..
i think about the HDV storage cassette
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 to be the
job of the graphics card
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) should be created : dvb
apps using channel file
matthieu castet wrote:
Klaus Schmidinger wrote:
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
Nico Sabbi wrote:
Klaus Schmidinger wrote:
Hmm, I would have expected that information to be in there somewhere.
The decoder should be able to detect the encoding of the data stream
by itself, without the application having to tell it what the data
actually is.
Klaus
from an application
Nico Sabbi wrote:
Klaus Schmidinger wrote:
Well, that might be feasible for live viewing, but what
about replaying a recording? There is no PAT/PMT in a
recording.
Klaus
there is if you save the TS, rather than that funny .vdr aka pes.
Can VDR save the TS now?
No - and it won't.
TS
Michael Müllner wrote:
Klaus Schmidinger schrieb:
matthieu castet wrote:
...
PS : do you plan something for VDR ?
Sure, once the driver supports DVB-S2 ;-)
Why wait ? there are also H264 over dvb-s :)
Mike
But there is no full featured DVB card yet that can be used
to replay HDTV
Oliver Endriss wrote:
Klaus Schmidinger wrote:
I'm currently improving VDR's CAM handling, and while doing so
I came across what seems to be a bug in the AV7110 driver code.
If I do
int fd = open(/dev/dvb/adapter0/ca0, O_RDWR);
ca_slot_info_t sinfo;
sinfo.num = 0;
ioctl(fd
Klaus Schmidinger wrote:
Oliver Endriss wrote:
Klaus Schmidinger wrote:
I'm currently improving VDR's CAM handling, and while doing so
I came across what seems to be a bug in the AV7110 driver code.
If I do
int fd = open(/dev/dvb/adapter0/ca0, O_RDWR);
ca_slot_info_t sinfo
I'm currently improving VDR's CAM handling, and while doing so
I came across what seems to be a bug in the AV7110 driver code.
If I do
int fd = open(/dev/dvb/adapter0/ca0, O_RDWR);
ca_slot_info_t sinfo;
sinfo.num = 0;
ioctl(fd, CA_GET_SLOT_INFO, sinfo);
to check whether the CI adapter
Jon Forsberg wrote:
Hello!
I can't get my Budget T-1500 to find any channels. The modules seem to load
ok and I do a 'scan scan_example_file_for_my_country_and_town':
scanning scan_example_file_for_my_country_and_town
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
Does anybody know a way to turn off the +5V supply voltage
on the antenna input of the TechniSat AirStar2 DVB-T card?
The driver source file frontends/mt352.c mentions the
MT352 design manual from Zarlink, so I assume somebody
must have access to that manual. Is it publicly available?
Or could
e9hack wrote:
...
I think, you will found nothing about the antenna supply in the spec of
the demodulator (MT352) or the pll (TSA5523M). If the card has
implemented a switchable supply, they will use one of the GPIO-Pins
(GPP3 from MT352 or P0..P7 from TSA5523M). The band switch bytes for the
Klaus Schmidinger wrote:
e9hack wrote:
...
I think, you will found nothing about the antenna supply in the spec of
the demodulator (MT352) or the pll (TSA5523M). If the card has
implemented a switchable supply, they will use one of the GPIO-Pins
(GPP3 from MT352 or P0..P7 from TSA5523M
e9hack wrote:
Klaus Schmidinger wrote:
in flexcop-fe-tuner.c I should do
Well, or rather
bs = ~0x08;
to clear P3 (I guess I was off by one in my previous mail).
Exactly, I meant that in this way.
Ok, I tried that, but now tuning apparently doesn't work
any more (no TS data
The rmmod.pl script that comes with the current driver source
blindly tries to load all modules it can find. While this is
good in case one has no idea which modules to load, there's
no easy way of finding out exactly which modules need to be loaded
to support just the installed hardware (unless
Trent Piepho wrote:
On Sun, 3 Sep 2006, Klaus Schmidinger wrote:
Klaus Schmidinger wrote:
I'm trying to compile today's driver (version 7a0daff8ed2c from the Hg)
and get the following error:
CC [M] /home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.o
/home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.c
Klaus Schmidinger wrote:
I'm trying to compile today's driver (version 7a0daff8ed2c from the Hg)
and get the following error:
CC [M] /home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.o
/home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.c: In function
'snd_bt87x_create_risc':
/home/kls/vdr/v4l-dvb
Trent Piepho wrote:
On Monday 28 August 2006 12:43, Klaus Schmidinger wrote:
Trent Piepho wrote:
On Sun, 27 Aug 2006, Klaus Schmidinger wrote:
I want the AV7110 firmware to be compiled into the driver.
But I don't seem to be able to make it do that. I tried editing the
linux/drivers/media/dvb
I'm trying to compile today's driver (version 7a0daff8ed2c from the Hg)
and get the following error:
CC [M] /home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.o
/home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.c: In function
'snd_bt87x_create_risc':
/home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.c:191:
Trent Piepho wrote:
On Sun, 27 Aug 2006, Klaus Schmidinger wrote:
I want the AV7110 firmware to be compiled into the driver.
But I don't seem to be able to make it do that. I tried editing the
linux/drivers/media/dvb/ttpci/Kconfig file and changed the default value
of DVB_AV7110_FIRMWARE_FILE
Wolfgang Rohdewald wrote:
On Monday 28 August 2006 12:43, Klaus Schmidinger wrote:
Trent Piepho wrote:
On Sun, 27 Aug 2006, Klaus Schmidinger wrote:
I want the AV7110 firmware to be compiled into the driver.
But I don't seem to be able to make it do that. I tried editing the
linux/drivers
I've downloaded the latest driver source (v4l-dvb-79d6a1de784a)
from the Mercurial repository, but somehow I have a problem with it.
I want the AV7110 firmware to be compiled into the driver.
But I don't seem to be able to make it do that. I tried editing the
Hu-Emulator wrote:
Question why is vdr lagging behind the linux kernel's.
Well, because I don't install new kernels twice a day ;-)
I'm still using kernel 2.6.13.
GCC 4.1.2 has
been out for quite awhile now. Both kernel-2.6.18, in fact gcc-4.1.2 is
required on 2.6.18; and v4l-dvb hg tree
Thomas Schorpp wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thomas Schorpp wrote:
| yes,
|
| my system was just halted on this:
|
| Jul 18 16:21:38 tom1 vdr[3199]: linking channel 402 from 502 504 516 505
| 506 510 508 509 to 502 504 516 501 505 506 507 510 508 503 509
|
|
Gavin Hamill wrote:
Just a note to say that as I was looking out of the window on the train home
yesterday evening, I saw lots of trees flash by very quickly, and I did
actually think for a moment that I could see some MPEG2 artefacts on the
window probably caused by low bitrate..
Oh
Francesco wrote:
On Sun, 2004-05-09 at 21:04, Marcus Metzler wrote:
What kind of
card and driver are you using, maybe this is an indicator that there
is something wrong with the cam support in the driver.
I use dvb-kernel driver from cvs (28/04/2004), libdvb-0.5.4. I
downloaded the
[EMAIL PROTECTED] wrote:
Hi,
I try to call plugins from within a new other plugin. This works fine for those,
which are
derived from cOsdMenu, but fails for those, which are derived from cOsdObject. The
reason behind is, as I think, that it is not possible to assign a value to
Gregoire Favre wrote:
On Sun, May 02, 2004 at 03:40:31PM +0200, Juergen Sauer wrote:
Is also vdr alright ?
VDR isn't NPTL compatible, you have to run it with:
LD_ASSUME_KERNEL=2.4 vdr
I'm still waiting for somebody to send me a patch that makes
VDR 1.3.6 NPTL compatible (BTW: I was
Michal Dobrzynski wrote:
Frankly I'd be overjoyed if I only had to wait 3 seconds at channel
change :/ I timed it with a stopwatch and it takes at LEAST 5 seconds
and sometimes even 8 seconds.
I'm sure it wasn't always this slow :/ (ie when I first started
dabbling). And it sure as hell
Michal Dobrzynski wrote:
I am running VDR 1.3.6 with Update Channels set to no (if that
makes a difference).
Regards,
Michal
Well, then I guess it must be a driver issue.
Klaus
On 23/04/2004, at 5:07 PM, Klaus Schmidinger wrote:
Michal Dobrzynski wrote:
Frankly I'd be overjoyed
Andrew de Quincey wrote:
I do not know the protocol well enough, to see the problem, but I think it
has something todo with a tcid comparison in cam_set which is not
fulfilled. The second possible problem I see is that the
dvb_ca_en50221_read_data function is called 1130 times in 12
Johannes Stezenbach wrote:
On Sat, Mar 27, 2004 at 01:18:40PM +, Andrew de Quincey wrote:
On Friday 26 March 2004 15:14, Klaus Schmidinger wrote:
Strange, from what I know a TPDU can be at most 2048 byte long...
Out of interest, where does that 2048 figure come from? I can't see
Andrew de Quincey wrote:
I've had to write all this horrendously complicated buffering code in order to
support the CAM link level interface in the kernel; i.e. taking the
multiplexed packet fragments from multiple connection IDs/slots and
reassembling them into full packets. This means the
Andrew de Quincey wrote:
...
Its just it makes the driver's IO routines _really_ complex, as they have to
deal with multiple connections, multiple slots, the possibility that the CAM
can be yanked out by the user at any time, and lots of other things. There is
a LOT of complex locking
D. Ratner wrote:
In reading up on the drivers and such and I have seen
mention of a dvb firmware building tool for ttpci.
Is this tool distributed with linuxtv-dvb-1.1.0
driver?
If so what is the name of this 'tool'? If not, I
assume its on the site somewhere. CVS maybe? What is
the
Andrew de Quincey wrote:
Cool. The Root/Dpram in your 2003-11-08 DVB snapshot is the same as the
ones I extracted from dvb-ttpci-01.fw.gz currently on the website. So its
definitely not that; I just wanted to make ABSOLUTELY sure it wasn't some
build issue. I'm assuming your
Klaus Schmidinger wrote:
Andrew de Quincey wrote:
Cool. The Root/Dpram in your 2003-11-08 DVB snapshot is the same as the
ones I extracted from dvb-ttpci-01.fw.gz currently on the website. So its
definitely not that; I just wanted to make ABSOLUTELY sure it wasn't some
build
Heino Goldenstein wrote:
Hello Klaus,
Klaus Schmidinger wrote:
Andrew de Quincey wrote:
On Saturday 20 March 2004 16:42, Klaus Schmidinger wrote:
Andrew de Quincey wrote:
From the Dpram checksums I can say that the first one is the one from
2003-09-05
Heino Goldenstein wrote:
Hello Klaus,
Klaus Schmidinger wrote:
Heino Goldenstein wrote:
---8-8-8-8-8-8-8-8-8-8---
FWIW:
I reviewed your e-mails to understand your SAT-hardwaresetup. From your
descriptions I guess you have something like
Kenneth Aafløy wrote:
Hi,
I was wondering about when the DVB branch will be phased out of development?
Essentially, it's not really needed anymore, since the 1.1.0 release is out,
or are you just keeping it around for incompatability reasons?
What about just tarring up the DVB branch
Johannes Stezenbach wrote:
Andrew de Quincey wrote:
its not the firmware.
its not the frontend driver (that was a different issue).
well, pretty obvious where it has to be really; must be a card setup problem
in the OSS code. I'll have a closer check over the next few days.
Like I
Andrew de Quincey wrote:
the actual DiSEqC signal is generated fom inside the firmware.
But since the firmware hasn't changed between the latest DVB driver
and dvb-kernel (at least as far as i know) I would assume that
the actual signal the firmware generates should still be the same.
Andrew de Quincey wrote:
This change was done to avoid glitches in recordings on the primary device
in case the channel is switched.
Does it change anyting (DiSEqC wise) if you comment that line out?
No idea, sorry, I only have budget cards; I'm just suggesting things.
I tried it now,
Andrew de Quincey wrote:
Incidentally, even though the firmwares used by 1.0.0 and 1.1.0 have the same
version number, they are _not_ the same.
1.0.0 had two seperate files, Dpram and Root
1.1.0 has a combined file, dvb-ttpci-01.fw
However the file format of dvb-ttpci-01.fw is obvious:
Andrew de Quincey wrote:
On Saturday 20 March 2004 15:26, Andrew de Quincey wrote:
Incidentally, even though the firmwares used by 1.0.0 and 1.1.0 have the
same version number, they are _not_ the same.
1.0.0 had two seperate files, Dpram and Root
1.1.0 has a combined file,
Andrew de Quincey wrote:
From the Dpram checksums I can say that the first one is the one from
2003-09-05, and the second one is the one which is in the 2003-11-08
driver package in my VDR FTP archive.
So which is the one you tried in the 1.1.0 driver that had the same firmware
Andrew de Quincey wrote:
On Saturday 20 March 2004 16:42, Klaus Schmidinger wrote:
Andrew de Quincey wrote:
From the Dpram checksums I can say that the first one is the one from
2003-09-05, and the second one is the one which is in the 2003-11-08
driver package in my VDR FTP
Andrew de Quincey wrote:
Ok, so I have changed the DiSEqC setup in my VDR to
S19.2E 11700 V 9750 t v W15 [E0 10 38 F0] W15 A W15 t
S19.2E 9 V 10600 t v W15 [E0 10 38 F1] W15 A W15 T
S19.2E 11700 H 9750 t V W15 [E0 10 38 F2] W15 A W15 t
S19.2E 9 H 10600 t V W15 [E0
Holger Waechtler wrote:
On Monday 15 March 2004 00:13, Klaus Schmidinger wrote:
Holger Waechtler wrote:
The DiSEqC spec requires you to set the appropriate bus voltage before a
DiSEqC command is sent. It also requires that the old-style SEC and
DiSEqC commands are sent compatibly
Johannes Stezenbach wrote:
Klaus Schmidinger wrote:
Holger Waechtler wrote:
On Sunday 14 March 2004 23:55, Andrew de Quincey wrote:
The problem with 1.1.0 is VDR isn't doing the full DISEQC init sequence,
and so no voltage was ever being sent to the LNB.
that's
Helmut Auer wrote:
Hi,
The diseqc settings:
S19.2E 11700 V 9750 v [E0 10 38 F0] [E1 10 38 F0] [E1 10 38 F0]
is not working perfectly. Sometimes when switching from h to v or vice
versa its not working.
Then I added W15:
S19.2E 11700 V 9750 v W15 [E0 10 38 F0] [E1 10 38 F0] [E1 10
Helmut Auer wrote:
Hi,
One ( hopefully ) last point:
It often happens after startup the first channel is not displayed by
vdr, that means, I have to switch once and the everything works fine. Is
that a vdr or dvb problem ?
If DiSEqC switching doesn't work reliably I'd say it's a DVB
Andrew de Quincey wrote:
The two combinations below are working with the _unmodified_ ves1x93
code and also with my alps_bsvr2 mod.
S13E11700 V 9750 v [E0 10 38 F0]
S13E9 V 10600 v [E0 10 38 F1]
S13E11700 H 9750 v [E0 10 38 F2]
S13E9 H 10600 v [E0 10 38
Johannes Stezenbach wrote:
Klaus Schmidinger wrote:
Andrew de Quincey wrote:
I get you, its the 'v'. Previously the driver was turning voltage on when it
started up, so power was being supplied, whereas now by default leaves it
off.
So this means VDR should turn the voltage
Holger Waechtler wrote:
On Sunday 14 March 2004 23:02, Klaus Schmidinger wrote:
There are some mandatory delays before and after sending
the DiSEqC sequence. The Nokia API rolled all that in a simple
and convenient ioctl which would allow the driver to do
all the timing (so
Johannes Stezenbach wrote:
Klaus Schmidinger wrote:
Johannes Stezenbach wrote:
It doesn't make much sense to remove the power from the LNB
while sending the DiSEqC sequence, but luckily vdr doesn't
seem to do that ;-) So, I guess that 'v' is a no-op.
'v' means voltage low
Holger Waechtler wrote:
On Sunday 14 March 2004 23:35, Andrew de Quincey wrote:
If you specify a bus voltage of 13 or 18V you definitely don't mean
VOLTAGE_OFF but expect the LNBP working, everything else is a bug.
Yeah, it seemed to have changed from being set to VOLTAGE_13 in the
Johannes Stezenbach wrote:
Klaus Schmidinger wrote:
Johannes Stezenbach wrote:
Nokia specified the ioctl to run asynchronous, which causes
some headaches for implementation. The current API also
is more flexible and simpler, but forces every programmer
to scrutinize the DiSEqC
Andrew de Quincey wrote:
On Sunday 14 March 2004 22:47, Holger Waechtler wrote:
On Sunday 14 March 2004 23:46, Andrew de Quincey wrote:
On Sunday 14 March 2004 22:36, Holger Waechtler wrote:
As soon you submit the polarisation selection command (VOLTAGE_13V or
VOLTAGE_18V) you
Andreas Oberritter wrote:
Hi,
On Sun, 2004-03-14 at 23:46, Andrew de Quincey wrote:
I suppose its a matter of how tolerant we want to be of userspace programs.. I
mean, we already turn OFF the LNB power automatically, why not turn it on as
well?
I don't care much, but please don't
Helmut Auer wrote:
Hi Oliver,
diseqc.conf
S19.2E 11700 V 9750 t v W15 [E0 10 38 F0] W15 A W15 t S19.2E 9 V
...
It seems to be that switching to vertical position kills everything.
Maybe timing has changed slightly (for whatever reason).
Try to optimize your
Johannes Stezenbach wrote:
Klaus Schmidinger wrote:
Ok, so I've set up a machine with SuSE 8.2, kernel 2.4.20,
fetched the dvb-kernel driver from today's CVS and the firmware
from http://www.linuxtv.org:81/download/dvb/dvb-ttpci-01.fw.
^^
Why?
Just one
Andreas Share wrote:
Be careful. The new code _works_ with BSRU6 (stv0299) and the old BSRV2
module. Remember that DiSEqC is _always_ done by the av7110 on
full-featured cards.
That is very weird.. So the new-ves1x93 must be in some mode that is
interfering with the DISEQC being
Helmut Auer wrote:
Hi Andreas,
-0x80, 0x00, 0x31, 0xb0, 0x14, 0x00, 0xDC, 0x00,
+0x80, 0x00, 0x31, 0xb0, 0x14, 0x00, 0xDC, 0x20,
just to clarify: my ves1x93.c has the following contens:
0x80, 0x00, 0x21, 0xb0, 0x14, 0x00, 0xDC, 0x00,
^
What should I try
Andrew de Quincey wrote:
OK, this is getting far too confusing. Need to summarise this:
We're trying two types of DVB-S-fullfeatured cards: the 1.3 and the 1.6
The 1.3 works fine with the alps_bsrv2(101) driver
The 1.3 fails with the ves1x93(110) (polarisation switching)
The 1.3 fails
Andrew de Quincey wrote:
On Saturday 13 March 2004 15:00, you wrote:
Andrew de Quincey wrote:
OK, this is getting far too confusing. Need to summarise this:
We're trying two types of DVB-S-fullfeatured cards: the 1.3 and the 1.6
The 1.3 works fine with the alps_bsrv2(101)
Michael Hunold wrote:
Hello Peter,
On 03/12/04 10:22, Peter Siering wrote:
Can you please send me oops?
I am not sure, how to do that? May be just that:
[...]
Yes, thanks.
Can you give me some informations about your system?
- kernel version used
2.4.24
- kernel
Ok, so I've set up a machine with SuSE 8.2, kernel 2.4.20,
fetched the dvb-kernel driver from today's CVS and the firmware
from http://www.linuxtv.org:81/download/dvb/dvb-ttpci-01.fw.
Compiling the driver and VDR worked just fine, and it appears to
run ok.
Just one thing: apparently the firmware
Robert Schlabbach wrote:
From: Oliver Endriss [EMAIL PROTECTED]
People have invested real money into these full featured DVB cards
and just don't want to throw them away.
Plus, there just isn't any reasonable alternative
Full-featured ack. ;-)
Full-featured cards are legacy
Holger Waechtler wrote:
Johannes Stezenbach wrote:
[EMAIL PROTECTED] wrote:
i am playing around with the DVR device for playing back a TS which
was recorded from the DVR device.
...
The kernel is configured a an SMP Kernel and Preemptible feature.
That's a recipe
Holger Waechtler wrote:
Klaus Schmidinger wrote:
Holger Waechtler wrote:
...
calling the PES unpacking process a 'remuxing' is kind of flattered,
not? Forcing everybody to misuse the lowlevel-API instead of highlevel
access just because the av711x driver is broken...
Well
Johannes Stezenbach wrote:
...
Sure, it would be cool if VDR would be changed so it supports
other hardware just as good as the av7110 cards. But IMHO VDR
should use PES playback on av7110 cards, and TS playback on hardware
that support it. Doing TS-PES conversion in the driver is wrong.
Hamish Moffatt wrote:
On Wed, Mar 03, 2004 at 09:20:01AM +1100, Peter Urbanec wrote:
Hamish Moffatt wrote:
Peter, your Melbourne data is quite old.
The frequency for SBS changed 2-3 months ago from 536.5 MHz to 536.625
MHz. The PIDs for channel 9 changed about 1 month ago.
Thanks
Carlo E. Prelz wrote:
Subject: [linux-dvb] Full featured cards
Date: Thu, Feb 05, 2004 at 11:24:10PM -
Quoting Adrian P Challinor ([EMAIL PROTECTED]):
Does anyone know where you can get the full featured cards that are needed
by VDR? My understanding is that I need
Carlo E. Prelz wrote:
Subject: [linux-dvb] Re: Activation of a card via Nexus+VDR - Possible?
Date: ven, feb 06, 2004 at 04:26:40 +0100
Quoting Andreas Share ([EMAIL PROTECTED]):
this could be only a problem with you CICAM, because neither vdr or the
driver touch
Johannes Stezenbach wrote:
Manfred Petz wrote:
Sorry, if this has already been answered: Looking at EN 50221:1997, a CAM
should be able to decrypt multiple tv channels at once. I'm playing around
with this and I only manage to decrypt one single audio/video PID pair
with my Nexus-S.
Johannes Stezenbach wrote:
Gregoire Favre wrote:
for some reasons I prefer to use 2.6 kernels, BUT with 2.6 kernels I
can't edit my marks under 2.6...
I have tried to run vdr with only one card: same result...
As already discussed, for some people, it works, for some other it's
Gregoire Favre wrote:
On Tue, Feb 03, 2004 at 04:28:29PM +0100, Klaus Schmidinger wrote:
VDR 1.3 natively supports NPTL.
I am sorry but I don't understand NPTL ;-)
I got same problem with 1.2.x and 1.3.x
If there is a switch to compil without NPTL, I would happily try it!!!
I just
Johannes Stezenbach wrote:
Klaus Schmidinger wrote:
Johannes Stezenbach wrote:
LD_ASSUME_KERNEL=2.4 ./vdr
...
(LD_ASSUME_KERNEL=2.4 makes glibc use linuxthreads
even if the kernel is capable of running NPTL.)
VDR 1.3 natively supports NPTL.
What does this mean?
Well, Jon
Arne Gellhaus wrote:
Gregoire Favre wrote:
On Tue, Feb 03, 2004 at 04:23:25PM +0100, Johannes Stezenbach wrote:
What works for me is:
LD_ASSUME_KERNEL=2.4 ./vdr
Which means that this problem is unrelated to the DVB drivers,
but due to changed behaviour of the new NPTL (native
I was looking into why the driver doesn't recover after a loss
of signal (like when pulling the antenna cable for a few seconds)
and found that apparently (at least with DVB-S) it starts a
dvb_frontend_recover() sequence, but aquires a lock at a completely
different frequency, which is some 16MHz
John Murdoch wrote:
Hi,
I'm wondering if the scan developers are considering incorporating automatic
channel numbering (for applications such as VDR) in the near future for those
services that support it?
If so, I have attached a small patch (created against the CVS dvb-apps tree) to
Niklas Peinecke wrote:
...
I agree with Holger. Of course it's better to have a release suitable
for 2.6, but it will take some more time until 2.6 kernels are really
common: Most people have working vdr-boxes based on existing 2.4 kernels
and they just like to use some e-bayed cheap
Martin Holst wrote:
Hi
although I believe that this bug is well known by the dvb-developer, I'll
describe it another time:
Many people noticed, that the sound on some channel gets lost and only a
restart of the dvb driver solves that problem. In my case I'm pretty sure, that
this
Michal Dobrzynski wrote:
Under Windows I was using MultiDec to view the following channel and it
was not scrambled (I do not have a CI module or CA so there would have
been no way to descramble it):
TVSN:12478:h:S156.0E:27800:1081:1082:0:1:3008:0:0:0
This is the TV Shopping Network
Roberto Ragusa wrote:
Hi all,
this posts is about discussions started in a different thread
([linux-dvb] Re: [PATCH?] proposed rewrite of skystar2 filters,
Wed, 03 Dec 2003 20:24:42 +0100)
There are currently two ways to get data from a TS (I'm
considering DMX_TYPE_PES only):
1)
Holger Waechtler wrote:
...
At that point dvrY is totally useless and it could be theorically
removed (but it's better to not break existing apps, of course).
We should keep it in v3, in v4 it will vanish anyways. The DVR device is
still required for MultiPID-TS filters when we don't
Pedro Miguel Teixeira wrote:
It works ok with -icam firware (just tested it)
PLEASE DON`T START NEW THREADS WITH EVERY MESSAGE!!
Stay in the thread you STARTED this with!
Klaus
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as
subject.
Holger Waechtler wrote:
...
? Hm, I think you got me wrong.
If I may choose between two comparable cards,
- one card with a closed-source firmware and
- another card with a complete open-source driver
I would definitely select the second one, even if it is more expensive.
Holger Waechtler wrote:
Klaus Schmidinger wrote:
Holger Waechtler wrote:
Oliver Endriss wrote:
On Thursday 20 November 2003 15:59, Robert Schlabbach wrote:
From: Klaus Schmidinger [EMAIL PROTECTED]
Robert Schlabbach wrote:
AFAIK, the specs for the TT designs have never been
1 - 100 of 545 matches
Mail list logo
