Re: [linux-dvb] Most stable DVB-S2 PCI Card?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Manu Abraham wrote:
> LOL, As stable as CX88, you must be joking. As far as the number of
> developers on the card, if you are as capable of reading what you claim,
> you can see that from the changelogs, in the main tree itself.
>
> You mean the SAA7146 driver is young ? Hmm.. pretty ignorant comments,
> you seem to make. The 7146 is one of the oldest driver that exists.
> Exception is bttv which is still older.
>   
Indeed "LOL", as you say. I do not wish to torment you any longer. :) It
is always sad to see people switch to personal insults, when they run
out of arguments. This wasn't my intention and therefore I'm withdrawing
from this thread with my apologies for making you angry.

Some last replies: I wasn't talking about the number of developers on
cx88, was I? I was talking about your driver and you being its sole
developer; cx88 has the advantage of being proven by time as stable (in
contrast to your *new* TT-1600 support, where things like number of
developers has objective informational value). You also seem to confuse
chips (i.e. the building blocks) and complete products. Is it not true
that your first attempt at S2-1600 support was submited on April 23rd,
2009? You see for me, this is *new*.

>> Also considering the fact that none of these
>> drivers even report signal stats properly. Then, of course, there's my
>> recent experience with your SkyStar HD2 driver. :)
>>     
> Which card are you talking about ? Your experience with the Skystar HD
> driver == USER Error, that's what some people would think.
>
>   
Well, that is what *you* think, because you weren't able to explain why
it didn't work properly. There were some driver difficulties, but what
did you expect when there are at least three different branches of the
driver, all devel:

http://jusst.de/hg/mantis
http://mercurial.intuxication.org//hg//s2-liplianin
http://jusst.de/hg/mantis-v4l

I used the last driver a few hours after it was uploaded (and suggested
on the list), so don't make this a USER issue.

> The mantis driver is a driver which is very much in development. You
> should've read it on the ML's itself. It's really sad that you are pretty much
> ignorant. A driver which is in development, you expect all sorts of issues.
> That's why it is in an external tree.
>   
Oh, but I've read the list before buying the card, just like I've done
for over 10 years for all HW for my Linux setups. Plus the reference
information on the linuxtv.org says the driver is in development for
over 3 years. When you see people discussing just lame & minor details
on the lists and when there's a 3yr old driver, you usually expect no
problems (not many anyway). But this is not my issue - please understand
that I'm not complaining at all, this is just a reply to your previous
statement. It is OT in this argument.

> Now, you managed to get hold of the wrong tree, burned your demodulator,
> inspite of me warning users on the ML's many times. So you are still
> ignorant on that. You decided to do, what it pleased you. Not my fault.
>   
As I wrote above, s2-liplianin was the latest tree available for general
public at the time. My only other option was multiproto. I used
mantis-v4l tree even before it was completely uploaded.

As soon as the new S2API mantis tree was mentioned on the list, I used
it. But most importantly, your only explanation that it still doesn't
work, because I burned my demodulator using the current s2-liplianin
tree is *absolutely* ridiculous. You might work it out with Liplianin
himself, but if you had read my followup, you would know that I
exchanged the card for new samples, had those samples *verified* by
TechniSat (your second and last explanation was that my HW is fake, LOL)
and I used *only* your latest driver. Of course it demonstrated the same
exact issues as previous "burned" (haha) cards.


> I guess, you don't understand the term "Development", "Stable" etc either.
>   
I did not expect everything rosy, I have my share of Linux HW
experiences. I've also written a complete Linux driver for a device I
had, which wasn't supported - that driver is now part of the kernel. So
believe me, not only I know how open source development works, I even
know how kernel driver development works. What I did not expect was
almost total ignorance of my issues by the driver author himself. One
would expect at least some cooperation, I know how hard it is to find
testers of one's code. You offered two explanations why your devel
driver didn't work: the HW is broken or fake. Nice!

In the end, I didn't return the cards because of the driver. I could
live without PWR, SNR monitoring and unstable locks. I gave up, because
even when everything worked, there were two major HW problems (caused by
driver):
1) Card's HW emitted high pitched noise (like old TV's, but louder) as
soon as I got DVB-S2 lock (mantis-v4l)
2) All DVB-S/S2 channels were corrupted, the picture looked as if there
was a weak signal (STB reports 95%!). Intolerable.

Yet, cx88 card on the exact same setup works with no issues rock solid.
The issues were not HW-related after all, when I returned the cards, the
shop had them tested (on Windows I guess) and they worked perfectly. If
you asked me to help you debug or test it, you might fix a big fuck up
in your driver. Could be a newer card revision or whatever.

Well, what do I care, my HTPC is finished and flawless. :)


> The TT S2-1600 support is much different, support for it exist in the mainline
> tree, which is verified. The SAA7146 bridge which the S2-1600 is based on,
> is the most mature PCI multimedia bridge that exists under Linux.
>   
Again the chipset & complete product mixup. Your initial S2-1600 patch
from April 23rd, 2009:
http://www.mail-archive.com/linuxtv-commits@xxxxxxxxxxx/msg03924.html

Don't forget we are still talking about recommendation for the most
stable card requested by the OP. This whole discussion happened, because
you were unable to accept that one cannot compare support this young
with what cx88 offers.

> I don't work for Technotrend, neither have i till now. My opinions are my own.
> I don't care about your completely non-technical or trolling posts. Whether
> Technotrend is having a new ownership/management is as well nothing of
> concern to me.
>   
1) I honestly don't know who you work for and I promise I do not care
2) We are not talking about a change of ownership like in the past, but
a complete company liquidation
3) The first trolling in this thread was your latest email. If we are
talking about technical discussions, don't forget that it was you who
brought up personal stuff. All my contributions were directly related to
OP's question, S2-1600 technical specs and driver stability issues.

> There seems to be people buying the"dead product" that you claim and hence the
> support for it is in.
> It's not a card manufacturer that do make the chip specifications.
> You can look at the STV0903 specification, or the announcement that i
> made earlier on the list about the same.
>   
Of course people buy stuff that is on the market; however, that doesn't
mean it is being actively developed or manufactured. In this case, it
isn't and it's presence on the market is limited to the number of cards
produced before the collapse of TechnoTrend.

> From the Cut 2.0 chips onwards, The STV0900/903 demodulators do support
> 45 MSPS officially and unofficially 60 MSPS with 8PSK modulation. Anything
> predating Cut 2.0 you don't find on any PC related products.
>
> http://linuxtv.org/hg/v4l-dvb/rev/4882c97b0540
>   
This is true, but do you know how the chips are integrated in TT-1600.
Final consumer product using certain chipsets usually does miss some
features or parameter ranges of the integrated chips (especially SoC
chips). Have you ever seen a PC motherboard? Well, now that you know how
I meant what I said, it is perhaps time to acknowledge that the *card*
manufacturer usually knows what their product is capable of. You know,
they being the people who actually design all the circuitry on the
PCB... I doubt TT would specify worse parameters that its product is
capable of. Especially if, as you say, they are the result of a new
technology, which would give them the edge over all the competitors. So,
TT-1600 was apparently designed to support 30 MS/s 8PSK without
stability issues or damage to the HW.


Regards,

-- 
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux