BeMax Wrote:What type on LNB do you have ? I have a Quad output LNB and the isolation between the different "ports" is not good enough. If you have one receiver using one port, the other ports will get some "glitches" if you change polarization/LO etc...
Hi BeMax
Thanks for responding. I have a eight-output LNB. I changed this over the weekend for another (different) 8-output LNB and it's too early to tell if it's made any difference yet, but I should know in the next few weeks.
I saw that post before I posted my original post but I don't have any Continuity errors listed in the logs, but the picture of the artefact is VERY similar to what I'm experiencing !
I had a further email reply from Constantine at TBS - here it is.......
Constantine (TBS) Wrote:hi David,
there is no way to check 6985 temperature - there is no sensor about that on the card, but i doubt it's related to overheating of 6985 - i haven't had case of 6985 overheating and we have users using several 6985 cards installed next to each other in the same system to build IPTV servers. so, if there are problems with 6985 overheating putting several cards next to each other would definitely make such problem very obvious, but that's not the case.
there are 2 ways that come to mind for monitoring the data throughput:
a) lock the signal with 'szap-s2' (that has advantage that you get statistics like BER, etc in real time) and then keeping 'szap-s2' working run 'dvbtraffic' - it gives real-time statistics of the data-rate and PIDs in the stream - if there is some data corruption, then data-rate will go down compared to the expected one. however, if the data corruption is low it's hard to spot it on 'dvbtraffic' output, i mean notice the total is not as much as it should be, but in case of significant corruption it's obvious on such test. actually, for this test, please, read remark *)
b) use 'dvblast' - if you setup stream one channel from a transponder with 'dvblast' it performs real-time analysis of the TS stream and outputs as debug messages there is corruption in the stream. that's good way to confirm the corruption and see how often it occurs
*) something else that you can try is lower the demand on PCIe bus the card puts - assuming something changes in your system that compromised the normal PCIe bus performance. so, if you run 'dvbtraffic' with default driver, even when there is no signal lock, you will see that the output is:
1fff 42877 p/s 7871 kb/s 64487 kbit
2000 66039 p/s 12124 kb/s 99323 kbit
that's because the card is doing padding to about 100Mbps with Null (empty) TS data packet. you can disable that with replacing in the drivers the attached 2 files and then rebuild and reinstall them. so, after doing that, running 'dvbtraffic' without signal lock must give empty output, because there is no longer TS generator active on the card and all data pass to the PCIe are the one that are received from the transponder, i.e. padding to fixed data-rate is disabled. that can be useful for test like a) too.
in any way, considering the history of your case, i.e. that 6985 was working good for you, i doubt any of the above will give solution - it more can give some idea what else broke in your setup. in cases like yours at least my usual suspect is the LNB.
best regards,
constantine
i forgot to add on *) that after you build and install the modified driver to disable the TS generator you need to create text file in "/etc/modprobe.d/" called for example "tbs.conf" and it with following content:
cat /etc/modprobe.d/tbs.conf
options saa716x_tbs-dvb int_type=1
options saa716x_tbs-dvb enable_gts=0
I tried the int_type setting (on its own) (without rebuilding the driver) but the result of that was inconclusive and the new LNB arrived, so I took Constantine's thoughts and replaced that as the first priority.
If I still get artefacts, I will be trying his modprobe suggestions.
I'm not convinced the LNB was at fault, as my Humax box has no issues at all. My gut is telling me it is a driver issue or some sort of motherboard pcie bandwidth restriction as it seems to only be a problem with HD recordings, although I did have 1 issue once with a SD recording, but that could have been because an HD recording was happening at the same time !? With HD, it's reliably unreliable
But the LNB sounds like a quick (and cheap) thing to rule out, so I'm doing that first, then it'll be modprobe settings.
A driver issue or PCIE bandwidth issue feels like where the problem is (to me). And the fact that others have managed to run the TBS6985 fine under windows, but using the same hardware have had no problems under windows, backs this up.
If I can get too sick, I'll sell the TBS card and try another make. But, to be fair, the TBS people have been great and very helpful, so I'm keen to stick with TBS if I can.
dp