Matthias Dahl wrote:
Hi everyone.
Just wanted to ask if there is any progress on that front? Haven't heard or
seen any movement for quite some time now and I was wondering if that patch
will make it into the tree or not.
The patch was only for testing. I don't know, why your dvb card gets
Hi everyone.
Just wanted to ask if there is any progress on that front? Haven't heard or
seen any movement for quite some time now and I was wondering if that patch
will make it into the tree or not.
Thanks for your help in advance...
Best regards,
Matthias Dahl
On Friday 01 June 2007 21:44:40 Oliver Endriss wrote:
Strange - I wonder why it makes a difference whether you use the A/B or
the VPE interrupt?
If there is something I can do to help figure this out, just let me know.
Either way, without this patch, the current tree is unusuable for me. :(
Matthias Dahl wrote:
Hi Hartmut.
it seems that newer windows drivers for the KNC ONE/Satelco
EasyWatch/Terratec Cinergy do not longer use the VPE interrupt to transfer
data. They use the the PORT A/B interrupt. Can you please try the attached
patch (with and without the CI/CAM)? The
Hi Hartmut.
it seems that newer windows drivers for the KNC ONE/Satelco
EasyWatch/Terratec Cinergy do not longer use the VPE interrupt to transfer
data. They use the the PORT A/B interrupt. Can you please try the attached
patch (with and without the CI/CAM)? The patch uses also the PORT A/B
Matthias Dahl wrote:
Like always, if you need anything, please let me know.
Hi,
it seems that newer windows drivers for the KNC ONE/Satelco EasyWatch/Terratec
Cinergy do not longer use the VPE
interrupt to transfer data. They use the the PORT A/B interrupt. Can you please
try the attached
On Saturday 19 May 2007 23:45:12 e9hack wrote:
Did you switch to a FTA channel or did you also remove the CI physical from
the card?
Tried both (with and without CI attached to the knc one)... the result was the
same.
Than you have another problem. If you get such a warning with a buffer of
Hi Hartmut.
Sorry for my -very- late reply but I was sick and thus not really able to get
most of my things done. (and still working my way through a lot of things for
university)
check if you get the same problems with FTA channels?
Same problems apply to FTA channels.
The transfer mode
Matthias Dahl wrote:
check if you get the same problems with FTA channels?
Same problems apply to FTA channels.
Did you switch to a FTA channel or did you also remove the CI physical from the
card?
1)
Reducing the buffer size to 658kb solves the problem partially.
In this case, the
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
Hi.
A few days ago I upgraded to 2.6.21-rc7-git8 and along that way also to a
recent checkout of the v4l-dvb hg tree. After that most of the DVB-C streams
I receive are corrupt. (lot of a/v artefacts)
After some digging around, I was able to spot the above mentioned patch as the
culprit.
Matthias Dahl wrote:
Hi.
A few days ago I upgraded to 2.6.21-rc7-git8 and along that way also to a
recent checkout of the v4l-dvb hg tree. After that most of the DVB-C streams
I receive are corrupt. (lot of a/v artefacts)
After some digging around, I was able to spot the above mentioned
On Sunday 29 April 2007 15:41:48 e9hack wrote:
Maybe, you are the first one, who uses the driver with a DVB-C card and
with a CAM. Can you remove the Cineview module from the card and check if
you get the same problems with FTA channels?
I'll give that a try sometime tomorrow or tuesday
13 matches
Mail list logo
