Hi,
Just wondering whether anyone else has had any experience trying to get the
WinFast DTV1800 H card to work? Or has any advice on how to do so?
I'm happy to have a go at implementing support for this card (hopefully in
some ways it is fairly similar to the DTV1000, although it has analogue
Hi,
Just wondering whether anyone else has had any experience trying to get
the WinFast DTV1800 H card to work? Or has any advice on how to do so?
I'm happy to have a go at implementing support for this card (hopefully in
some ways it is fairly similar to the DTV1000, although it has analogue
On Sat, 2007-05-19 at 23:45 +0200, e9hack wrote:
Thanks, I need only the dump with the running application and with the
i2c-address 0xc (tda10021). I forgot, that exists
some more devices on the i2c-bus. The windows driver uses a small buffer
(188kB), in odd/even buffer mode. The line
On Wed, 2007-05-02 at 02:32 +0200, Oliver Endriss wrote:
Jon Burgess wrote:
Sorry for the delay. I wanted to track down the DMA sync bug before I
came back to look at this again.
I have added saa7146_vmalloc_destroy_pgtable() which frees the resources
Shouldn't it better be called
-API.txt.
Jon
Signed-off-by: Jon Burgess [EMAIL PROTECTED]
diff -r e3779e21a314 linux/drivers/media/common/saa7146_core.c
--- a/linux/drivers/media/common/saa7146_core.c Tue May 01 10:48:09 2007 -0300
+++ b/linux/drivers/media/common/saa7146_core.c Tue May 01 21:54:19 2007 +0100
@@ -136,28
On Tue, 2007-05-01 at 11:41 +0200, Gregoire Favre wrote:
Hello again,
just forgot this :
ksymoops 2.4.11 on x86_64 2.6.21. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.6.21/ (default)
-m
On Wed, 2007-05-02 at 01:08 +0200, Oliver Endriss wrote:
e9hack wrote:
Oliver Endriss wrote:
Jon Burgess wrote:
It appears the problem is that the driver is using streamed PCI and
needs to explicitly sync the data otherwise it breaks when the SWIOTLB
is in use. A call
On Mon, 2007-04-30 at 18:52 +0200, Gregoire Favre wrote:
On Sat, Apr 28, 2007 at 09:14:37PM +0100, Jon Burgess wrote:
While the above patch works, it seems the underlying causes is that
vmalloc_32() is providing memory above 4Gb on x86-64 which is not what
the driver expects. This same
On Fri, 2007-04-27 at 18:06 -0400, Lee Revell wrote:
On 4/27/07, Jon Burgess [EMAIL PROTECTED] wrote:
Interesting - I see similar symptoms after upgrading my PC:
* old PC was AMD Athlon 64 3000 w/ 2GB of RAM which had no issues
* new PC is a Intel Core 2 Duo w/ 4GB of RAM and fails
On Sat, 2007-04-28 at 18:17 +0100, Jon Burgess wrote:
On Fri, 2007-04-27 at 18:06 -0400, Lee Revell wrote:
On 4/27/07, Jon Burgess [EMAIL PROTECTED] wrote:
Interesting - I see similar symptoms after upgrading my PC:
* old PC was AMD Athlon 64 3000 w/ 2GB of RAM which had no issues
On Fri, 2007-04-27 at 22:46 +0200, Markus Rechberger wrote:
just for the completeness, what does dmesg show up?
You forgot to mention what device you have too...
Markus
On 4/27/07, Gregoire Favre [EMAIL PROTECTED] wrote:
Hello,
I have a computer (mother Asus Commando) with 4x1Gb Ram.
On Fri, 2007-04-27 at 18:06 -0400, Lee Revell wrote:
On 4/27/07, Jon Burgess [EMAIL PROTECTED] wrote:
Interesting - I see similar symptoms after upgrading my PC:
* old PC was AMD Athlon 64 3000 w/ 2GB of RAM which had no issues
* new PC is a Intel Core 2 Duo w/ 4GB of RAM and fails
I've been looking at the sa7146 page table code and it looks like the
saa7146_pgtable_free function is used incorrectly in the error cases:
from budget-core.c:
ttpci_budget_init()
{
...
budget-grabbing = saa7146_vmalloc_build_pgtable(dev-pci,
budget-buffer_size, budget-pt))
...
err:
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
On Thu, 2007-02-01 at 08:22 -0800, Joe R wrote:
Hello -
I'm trying to get a Lifeview LR535 card working. It's in a minicard slot in
an
HEL-80 laptop, and I'm a little confused. If I lspci I don't see it there; if
I lsusb I see 10fd:0535 Anubus Electronics Ltd. -- which implies it's a usb
On Sat, 2007-01-06 at 23:49 +0200, Lokrain wrote:
Hello all,
I am trying to install VLC 0.8.5-1 na FC6. I checked that VLC for FC
after version 4 doesn't exist.
It is available in the livna or freshrpms repos.
http://rpm.livna.org/ or http://zod.freshrpms.net
# yum list vlc\*
...
Available
On Sun, 2006-10-29 at 20:18 +, Torgeir Veimo wrote:
On 29 Oct 2006, at 16:09, Patrick Boettcher wrote:
Hi Torgeir,
On Sat, 28 Oct 2006, Torgeir Veimo wrote:
On 28 Oct 2006, at 00:35, Torgeir Veimo wrote:
Am not sure where to start looking. I've included my dmesg output
On Sun, 2006-10-29 at 20:47 +, Torgeir Veimo wrote:
On 29 Oct 2006, at 16:09, Patrick Boettcher wrote:
Hi Torgeir,
On Sat, 28 Oct 2006, Torgeir Veimo wrote:
On 28 Oct 2006, at 00:35, Torgeir Veimo wrote:
Am not sure where to start looking. I've included my dmesg output
On Wed, 2006-10-18 at 23:34 +0100, Steve Brokenshire wrote:
Hi,
(Before I start, I'm running linuxtv-dvb-apps 1.1.1 with Linux kernel
2.6.17.11 on Debian 3.1, using a Freecom DVB-T USB stick and a Hauppauge
PVR-350 card with VDR 1.3.41. I've done a quick skim on the linux-dvb mailing
up
Tim Hoad wrote:
Hi all,
I am having problems getting my VisionPlus DVB-t card to play nice with my SATA
HDD - video breaks up when disk is accessed. I am using a motherboard with
on-board SiI3112 SATA controller (ABIT NF7-s).
Are you using Linux-2.6 with VDR and a ext2/3 filesystem for the
Rene Bartsch wrote:
I'm having artefacts in the picture (VDR). The HDD (SATA) performs with
58 MB/s, so I assume it's related to the PCI-bus (on an i865PE board).
My setup has an i865G running with 4 x Nova-T PCI cards and I don't see
any problems so I suspect the PCI bus is not the cause.
Andreas Share wrote:
Hi,
I have around 1600-1800 interrupts per second, with the ss2 as secondary
device during epgscan.
OK, That is not excessive - an idle 2.6 machine has 1000 from the timer
interrupt alone.
One other thing: The Dbox2 related Tuxbox Project share the Api3 and the
most of
Christian Schuld wrote:
Normally ERROR: video data stream broken indicates, that VDR doesn't get any
data out of the DVB-card. The reason might be a tuning failiure or this
mysterios bug, which happens only with VDR in a multi card setups. I suppose
none of the driver developers actually use
Torbjörn Jansson wrote:
Maybe fedora have included some other kernel patches that breaks the osd? Or
maybe the dvb drivers in kernel 2.6.5 is broken?
The 4G-4G feature of the FC2 kernels will break any incorrect direct
access to userspace data.
There is another example here
Scott White wrote:
I was wondering what solutions people are using for more than one card.
Can you get a digital capable amp/splitter for example?
I have 4 DVB-T cards and just use an regular 4 output TV amplifier from
a highstreet electronics store. This works fine for me at home.
I once
Franck Arnaud wrote:
Ah, OK! I wondered why it had not been added earlier, and
I did not think about looking at this module (my card has no
CI, although I can imagine a CI version of same exists).
Thanks.
My card has no CI either, but I use the CI driver because it also
includes support for
Johannes Stezenbach wrote:
IIRC the outcome of this discussion was use BTN_x instead of
KEY_x if you don't want your remote control to generate
keyboard events.
2.6 has an exclusive access feature which can suck up these extra KEY
events from your remote preventing them from appearing as
Q wrote:
Hi can anyone on this list tell me if there is a working Linux driver
for Wintv Nova-T?
Yes the linux-dvb driver code, see http://www.linuxtv.org/
Also what is the fron't end in Linux I should use to replace the WinTV
Windows based front end?
I would like to continue to be able to
Holger Waechtler wrote:
Alternatively it can extracted from the install cab files but this w
to be done in windows as I don't know of a linux version of extract.ex
Try http://www.kyz.uklinux.net/cabextract.php
I haven't used it myself, but I have seen it referenced elsewhere.
Jon
--
*Michal Dobrzynski wrote:
* I'm not sure I understood. Do you mean:
..
And why it be bad to do it this way:
...
I'm not sure what is the difference between the two you mention. There
is nothing particularly wrong with adding any extra cable, it is just
that the longer it is, the more distorted
Emil wrote:
I mean between red and ground, green and ground, blue and ground.
I haven't tried wiring up this RGB lead myself but I've done a fair bit
of work with ananogue transmission line theory which explains why this
termination is required to get a good signal.
I believe the answer is a
Olaf Titz wrote:
[1] mplayer (segfault)
I tried some HDTV sample files and found that mplayer would get an X11
error and segfault if I tried -vo xv, but -vo x11 worked ok, albeit
slowly. It appears that the XV support for my graphics card can not
handle the full 1920x1080 picture.
Jon
Emard wrote:
2.6 a more work is needed (can someone help me there
for the inspiration) to secure budgets on 2.6 because the
budget-core is loaded separately and MOD_INC_USE_COUNT
gets bound to budget-core and not to actual budget driver
...
Emard
You could get some inspiration from a patch
Steve Wakelin wrote:
./vdr -Pstreamdev -Pdxr3
vdr: dxr3abstractiondevice.c:77: cDxr3AbsDevice::cDxr3AbsDevice():
Assertion `m_fdVideo = 0' failed. Aborted
That error is reported when the code can not open the device
/dev/em8300_mv, have you created these device nodes?
xine and mplayer
Nick Manser wrote:
Firstly, is it possible to combine a DVB card with a harware MPEG-2 decoder
card and use them both to watch a digital TV stream? If so, how would I go
about doing this?
Yes you can do this. I have a similar setup with two Hauppauge DVB-T
cards and a Creative DXR3 card (which
Steffen Beyer wrote:
based cards? I can't do real testing because the DXR3 driver has no 2.6.0
support yet.
2.6 support is not yet in the main dxr3 codebase, but there are patches
available. There is a copy of the patch which I use at
Adam Lounds wrote:
whenever I run scan or dvbtune it doesn't work, but removing
FE_CAN_INVERSION_AUTO from the .caps fixes it.
Very new to this, but how does it work for anyone else?
I ran into the same problem as well when I ran scan recently. I didn't
notice the problem for a while because
Werner wrote:
Hmmm ... at least I've tried the last patch of Jon (AFAIK it is now
part of the current driver)
Yes, the changes have been merged into both DVB and dvb-kernel
the bitstreamout plugin of VDR has seen a lot of duped TS frames.
OK the plugin does not check about duped TS frames
[EMAIL PROTECTED] wrote:
Neun Live, DSF, HOT, N24, VIVA. The recording with VDR gets lot of cTS2PES
errors and the recording is unusable. The systems with the rev 1.6 cards
records the same recordings at the same time without any problems. I think
that has something to do with the DVB driver
John Pullan wrote:
I went with Petri's solution (delete compat.h) for now and it seems to
work. I'll do the job properly once I've got access to a fat pipe.
(Can't face downloading the kernel source over a modem)
You can get the pristine kernel.org source by installing the
kernel-version.src.rpm
Johannes Stezenbach wrote:
Recent scan uses INVERSION_OFF if the frontend driver says it
cannot do INVERSION_AUTO. It does not yet emulate AUTO by trying
both OFF and ON.
Ubfortunately the tda1004x driver says it can do auto inversion, but
rejects it when it is requested. If it didn't claim to
The patch attached adds a couple of debug lines to say:
- What module has been registered for locking
- Each time the module gets locked and unlocked.
This works fine for me on linux-2.6.0-test5. I'm fairly sure it worked a
couple of days ago when I tested it on 2.4 as well.
Here is a log from
The scan application doesn't want to work for me on Linux-2.6.0-test5.
When I run the dvb-kernel drivers on linux-2.4 it works OK.
I think i've tracked the problem down to the CRC check which occurs when
DMX_CHECK_CRC is selected by scan. Removing the flag in the scan code
makes it work OK.
I
Johannes Stezenbach wrote:
I just gave it a try with 2.4 and it didn't work. I was able
to unload dvb-ttpci while szap was running, resulting in an
Oops when I interrupted szap.
I did testing on both 2.4 and 2.6 with two budget Nova-T cards. I'm sure
I tried doing the same thing with tzap and
The patch attached (for dvb-kernel only) causes the module use count to
be automatically incremented when any of the frontend, demux, etc
devices are openned.
When the device is closed the count decremented so the module can be
safely removed. I have only done a patch for the dvb-kernel
When tuning to a new channel the first couple of packets are often junk,
but most of the following 64kB of data in the DMA ring is actually OK.
The patch attached moves a check for the 0x47 TS packet sync byte from
the vpeirq DMA receive code into the lower demux layer (so it makes the
decision
Robert Schlabbach wrote:
The hardware does not generate any VSYNC signals, and thus no frame
signals. To utilize the odd/even field DMA mechanism, you have to program
the SAA7146A to force the toggling of the field. See the DD1_INIT register
settings for details.
OK, I was under the impression
Robert Schlabbach wrote:
the SAA7146A to force the toggling of the field. See the DD1_INIT register
Thanks for that, it looks like none of the current code enables either
of the FIDESA/B interrupt signals.
Jon
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe
While looking through the code which sets up the DD1_INIT register in
the dvb-kernel driver I noticed that one of the settings looks
inconsistent with the rest:
[ttpci]$ grep -r DD1_INIT *
av7110.c: saa7146_write(dev, DD1_INIT, 0x0200);
av7110.c: saa7146_write(dev, DD1_INIT,
Last night I tried another approach to fixing the DMA issues. Instead of
dealing with the awkward transition between the odd and even fields in
the middle of the buffer, I just avoid the problem by using the whole
buffer for both fields. This works fine for me on both the DVB
dvb-kernel
Michael Loose wrote:
Can you push my dumb bonehead a bit further into the documents
direction? Seems i can't find anything about firmware for the tda1004x
Try DVB/driver/frontends/README.tda1004x
Jon
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as
Stefan Betermieux wrote:
I will investigate the IRQ issue this evening. I am pretty sure that your
patch is executed half of time, because I inserted a syslog message inside
your if statement and in a newly created else statement another message. They
alternated in the log most of the time, I
Holger Waechtler wrote:
why do you want to do PID filtering on the RPS? it's done in software in
the current Nova driver anyway...
I thought Robert was hinting that you could get the device to DMA the
data straight into an output buffer which then gets returned to
usermode, without needing to
Robert Schlabbach wrote:
The odd/even trick makes the SAA7146A automatically switch between two
buffers. The ugly side of this is that you have to busy-wait for it to
really switch buffers and then _copy_ the data out of the DMA buffer.
Yep, I tried doing a busy wait before I came up with the
Robert Schlabbach wrote:
I think the odd/even buffer are used to overcome a sensitive timing issue -
keep in mind that there is no such thing as a vertical blanking in a DVB
data stream. The only breathing time between two MPEG-2 transport packets
are those 16 bytes Reed-Solomon redundancy. Now
Michael Loose wrote:
Linux video capture interface: v1.00
DVB: registering new adapter (TT-Budget/WinTV-NOVA-T PCI).
PCI: Enabling device 02:0c.0 (0004 - 0006)
PCI: Assigned IRQ 9 for device 02:0c.0
tda1004x: Detected Philips TDA10045H.
tda1004x: Detected Philips TDM1316L tuner.
DVB: registering
Ed Wildgoose wrote:
Unfortunately just like with the DVB driver patch, I can't seem to get
it to detect several keys such as the red key, and the bottom left
prev track key. Nothing comes back, and some basic hacking of the
driver tends to suggest that some of these keys must be being
Stefan Betermieux wrote:
Hi,
unfortunatly, the patch doesn't do the trick for me, I still have to use
another PCI burst mode. I have taken a look at your patch and I have noticed
that your workaround is executed every second call of vpeirq() on my system.
Is this a normal behaviour?
I don't
Edward Wildgoose wrote:
Sorry, wasn't deliberate. To be clear. It completely fixes the problem for
me with the dvb_kernel branch. However, with the DVB branch, it is vastly
better, but there is still severe corruption (ie no way tolerable).
I took a look at the DVB code and it looks like it
Several people have sent me emails over the last few days which they've
intended to send to the list.
All the other mailing lists I receive add a reply-to: [EMAIL PROTECTED]
header to all emails they send out, thereby making the default replies
go to the list autopmatically.
Does anyone else
Andreas Vierengel wrote:
Am So, 2003-08-31 um 18.28 schrieb Jon Burgess:
the vga-chip seems to be on bus 0. only onboard ethernet is on bus 1
together with all external pci-cards. here is a lspci output. I don't
know very much about today's motherboard internals, but are these 2
busses
Here is a patch which completely fixes all the stream distortion
problems i've been seeing on my P4 system. This works without needing to
apply any of the proposed PCI tweaks.
After many hours of debugging last night, it looks like the corruption
is caused by a hardware bug in the DMA engine
I think it is becoming very clear that the choice of PCI burst used by the
budget driver is inappropriate for many chipsets, including common stuff
like the i845, many via boards, and also the i865 (my Asus P4P800)
I think the problem is a hardware bug in the DMA engine, see the other
email I
Julian Tibble wrote:
As far as I can tell, av7110_ir.c is part of the driver for fully featured
cards, and budget-ci.c is for cards with a common interface connection for
pay-per-view. Neither of these apply to me (as far as I know), so can
I use the remote control?
The budget-ci is actually for
Lauri Tischler wrote:
Where do you apply that to DVB cvs ?
I haven't tried the DVB driver. Try the patch attached, it is completely
untested, but it looks like the code in the DVB driver is similar enough
for it to work the same.
Jon
diff -Nurw DVB/driver/av7110/av7110.c
Ed Wildgoose wrote:
However, curiously enough I already had loaded the driver:
dvb-ttpci-budget-ci
Your card must be one of the ones already supported by the driver then,
the patch would do nothing new for you.
And this does in fact seem to be picking up my remote and there is a
Julian Tibble wrote:
Btw, I've heard of people using some program called evtest, I don't
evtest.c can be got from the linuxconsole SF project CVS at the link below:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/linuxconsole/ruby/utils/evtest.c?rev=HEADcontent-type=text/plain
Jon
Edward Wildgoose wrote:
io_ctl: SET_FRONTEND: invalid parameter
I had this at one time with my budget card.
It was caused by the channels.config having INVERSION_AUTO set, but
the frontend on the card doesn't supprt the auto inversion. Hence it
returns the error. Try changing this to
[EMAIL PROTECTED] wrote:
1) Has anyone built a VDR using RedHat 9?
To make VDR work on RH9 you need to follow the instructions regarding
NPTL as per the VDR INSTALL file. You need to set LD_ASSUME_KERNEL
variable to disable NPTL otherwise it breaks the VDR thread code.
Jon
--
Info:
To
I don't have any experience with DVB packets, but if it looks anything
like an multicast Ethernet frame then it should be:
DA Mac address SA Mac address Ethertype IP headers
MAC addresses are 6 bytes (48 bits)
For an IP multicast packet the multicast DA should be
01 00 5e xx xx xx
Where xx xx
bigg wrote:
insmod), then I tried to run the scan utility, it would fail to find any
channels. However, if I first ran vdr and selected a channel on the
terrestrial card, then killed vdr (presumably simply tuning to a frequency
would also have worked), that the scan app could quite happily find
Phil Space wrote:
There's definitely nothing wrong with the card (a
Hauppauge WinTV Nova-T) or aerial setup - it works
...
dvb-ttpci.o: init_module: No such device
The Nova-T card requires the dvb-ttpci-budget.o module
instead of the dvb-ttpci one.
Jon
--
Info:
To unsubscribe send a mail to
Robert Schlabbach wrote:
While we're at it, does anyone know what the TMS320AV7200 is? I found
The TMS320 range is a very large series of chip based around a DSP core.
I think this is the number one line of CPU's made by TI.
The AV is presumably some variant which includes some audio/video
This would really depend whether USB bandwidth is per direction or per total
of both. Not sure which it is, but I suspect total.
I'm fairly sure that USB is inherently half duplex at the hardware
level. There are 4 pins on the connector, 2 for power/gnd and a
differential pair for data.
I
Nico wrote:
Feedback and suggestions are welcome.
I had to make a few tweaks to make it work for me. A patch is attached.
- Changes the frontend detection code to use the returned fe_info.type,
not the ioctl() return.
- When reading a terrestial channels.conf file it wasn't initialising
David Mittelstädt wrote:
Thanks thats great, because i now have a stable picture but i wasnt able
to figure out how to switch between channels. Great work you did.
Try h k
Jon
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as
subject.
Holger Waechtler wrote:
synchronized, I'll fix that. Can you please update your CVS and then
take the new grundig_29504-401.c as reference?
OK, I've been trying this out over the weekend and found that the chip
power control doesn't behave quite as you would expect. When the chip is
powered
While inserting an removing the dvb-ttpci-budget module I noticed that
the module use count always stays at 0, even when the device is in use
by VDR. If I then try to remove the module then there is an oops when
what looks like the next IRQ is delivered from the hardware.
Surely the module use
Holger Waechtler wrote:
Hi Jon,
that's illegal -- it would overwrite an attached EEPROM if we write
registers before we're sure that it's really a L64781. I just realized
OK, in understand. The trouble with this test is that the L64781 will
reponds after it is initialised. In fact the test a
You could try booting Windows first then doing a warm restart into Linux.
Some of the kernel options which effect the PCI bus, for example try
adding pci=nobios to the kernel commandline
Alternatively, try using a kernel with ACPI enabled, this has its own
mechanisms for interacting with
Holger Waechtler wrote:
Don't know if we should force the application to autoprobe the inversion
setting instead of implementing this in all drivers, in the ves1820 and
stv0299 driver there was a definite need to do it because there are
frontends out there with swapped I/Q pins where we simply
I noticed that if I remove and re-insert the grundig tuner and
dvb-ttpci-budget modules then the tuner module doesn't recognise the
hardware.
I tracked this down to two of the initialisation sanity checks failing
during the re-insertion. I have disabled these using the patch attached
and it
I have attached two small patches to the scan application, the first
(scan-check-fe.diff) adds a check to report an error if there was a
problem setting the frontend parameters.
The second patch (scan-fallback.diff) queries the frontend capabilities
before trying to use INVERSION_AUTO. I agree
- The grundig_29504-401 apply_frontend_param() aborts and returns
-EINVAL if the application tries to set INVERSION_AUTO, but the
ioctl code which calls this function just ignores the return code.
A single line change fixes this.
Jon
Index: grundig_29504-401.c
Andreas Oberritter wrote:
I think every application should check the capabilites (that's what they
are good for, aren't they?). But you should then - in case of no lock -
retry with inversion on.
I agree, but what we should try to avoid is that similar code ends up in
three different places: the
This patch fixes support for the various _AUTO frontend parameters to
the scan VDR output format. VDR uses 999 to indicate the automatic
mode for each parameter.
Please note that the INVERSION_AUTO (set by default in the recent scan
code) breaks my DVB-T grundig-401 tuner, which will be the
86 matches
Mail list logo
