TBS 6909x lot of CC

[joring]

I have 2x6908 and 1x6909x on same server, 6909x get lot of CC errors on multistream channles on 5W, same frequency working without problem with 6908. Driver is latest, convertor is QUAD, mode=0.

Oct 31 18:07:35[Rete4 HD i/1] Bitrate:6086Kbit/s CC:3 Oct 31 18:07:35[Canale5 HD i/1] Bitrate:5858Kbit/s CC:2 Oct 31 18:07:35[Italia1 HD i/1] Bitrate:5607Kbit/s CC:2 Oct 31 18:07:35[20 Mediaset HD i/1] Bitrate:5024Kbit/s CC:2 Oct 31 18:07:41[Rete4 HD i/1] Bitrate:6446Kbit/s CC:3 Oct 31 18:07:41[Canale5 HD i/1] Bitrate:6318Kbit/s CC:2 Oct 31 18:07:41[Italia1 HD i/1] Bitrate:5313Kbit/s CC:2 Oct 31 18:07:41[20 Mediaset HD i/1] Bitrate:4494Kbit/s CC:2 Oct 31 18:07:52[Rete4 HD i/1] Bitrate:7561Kbit/s CC:2 Oct 31 18:07:52[Canale5 HD i/1] Bitrate:5402Kbit/s CC:3 Oct 31 18:07:52[Italia1 HD i/1] Bitrate:3931Kbit/s CC:1 Oct 31 18:07:52[20 Mediaset HD i/1] Bitrate:5724Kbit/s CC:1 Oct 31 18:08:27[Rete4 HD i/1] Bitrate:7588Kbit/s CC:2 Oct 31 18:08:27[Canale5 HD i/1] Bitrate:5511Kbit/s CC:2 Oct 31 18:08:27[Italia1 HD i/1] Bitrate:4646Kbit/s CC:2 Oct 31 18:08:27[20 Mediaset HD i/1] Bitrate:4972Kbit/s CC:1 Oct 31 18:08:29[Rete4 HD i/1] Bitrate:6443Kbit/s CC:1 Oct 31 18:08:29[Canale5 HD i/1] Bitrate:3969Kbit/s CC:1 Oct 31 18:08:29[Italia1 HD i/1] Bitrate:7201Kbit/s CC:1 Oct 31 18:08:29[20 Mediaset HD i/1] Bitrate:4976Kbit/s CC:1 Oct 31 18:09:04[Rete4 HD i/1] Bitrate:4758Kbit/s CC:2 Oct 31 18:09:04[Canale5 HD i/1] Bitrate:6350Kbit/s CC:3 Oct 31 18:09:04[Italia1 HD i/1] Bitrate:7654Kbit/s CC:3 Oct 31 18:09:04[20 Mediaset HD i/1] Bitrate:3842Kbit/s CC:1

[crazycat69]

Need remote access to your server. I can't receive 5W, far eastern europe :)

[joring]

Ok no problem, here or on other contact form you want access?

On Thu, Oct 31, 2019, 20:31 CrazyCat notifications@github.com wrote:

Need remote access to your server. I can't receive 5W, far eastern europe :)

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/tbsdtv/linux_media/issues/179?email_source=notifications&email_token=ABBLX5QVR3SM4YDTDLF26X3QRMP6XA5CNFSM4JHMXLFKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECYZWRY#issuecomment-548510535, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABBLX5UYUSYD2NZOKXLYQZLQRMP6XANCNFSM4JHMXLFA .

[crazycat69]

crazycat69@narod,ru skype: crazycat_69

[tvhdeeptho]

I can receive these channels and have a tbs6909x card. Driver is fairly recent, but not the latest. git version of media_build: 91dc8972d37e

Channels like RETE4 work fine in tvheadend right now, except when tvheadend starts epg search on multiple tuners simultaneously. Those problems are not specific to multistream, and they could also be due to tvheadend. They could also be due to a lack of hardware pid filtering. I have not had the time to debug this.

Specifically I have activated some debugging code in the driver to report CC errors, and I only see CC errors at the start of tuning a channel (which is normal). CC errors are rare at other times (except in bad weather)

One thing I have noticed is that the card sometimes starts to show CC errors after
it has been used a long time without a reboot (e.g., several days of running TVHeadend and watching tv for a few hours per day). In that case a cold boot (power computer off, wait a minute; power back on) fixes the problem.

I also have a suspicion that the card remembers some tuning data from previous tunes, so that problems can also depend on which muxes were tuned previously.

With older drivers, I have even seen cases where some tuners fail completely (nothing can be tuned). Such a problem could only be fixed by a cold reboot (a simple reboot is not enough; power to the card must be removed)

So next time the problem happens, could you try a cold boot and report if the problem goes away?

[joring]

That card is big sh*t. On same transponders no have any problems with tbs 6908.

On Sat, Nov 16, 2019, 20:51 tvhdeeptho notifications@github.com wrote:

I can receive these channels and have a tbs6909x card. Driver is fairly recent, but not the latest. git version of media_build: 91dc8972d37e

Channels like RETE4 work fine in tvheadend right now, except when tvheadend starts epg search on multiple tuners simultaneously. Those problems are not specific to multistream, and they could also be due to tvheadend. They could also be due to a lack of hardware pid filtering. I have not had the time to debug this.

Specifically I have activated some debugging code in the driver to report CC errors, and I only see CC errors at the start of tuning a channel (which is normal). CC errors are rare at other times (except in bad weather)

One thing I have noticed is that the card sometimes starts to show CC errors after it has been used a long time without a reboot (e.g., several days of running TVHeadend and watching tv for a few hours per day). In that case a cold boot (power computer off, wait a minute; power back on) fixes the problem.

I also have a suspicion that the card remembers some tuning data from previous tunes, so that problems can also depend on which muxes were tuned previously.

With older drivers, I have even seen cases where some tuners fail completely (nothing can be tuned). Such a problem could only be fixed by a cold reboot (a simple reboot is not enough; power to the card must be removed)

So next time the problem happens, could you try a cold boot and report if the problem goes away?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/tbsdtv/linux_media/issues/179?email_source=notifications&email_token=ABBLX5WMCQOUFE6UFGII3ELQUA6LJA5CNFSM4JHMXLFKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEHYAJA#issuecomment-554663972, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABBLX5TPGCALYI5INICDDJLQUA6LJANCNFSM4JHMXLFA .

[crazycat69]

6903/5/9 use dual STV0910 demods.

[crazycat69]

@tvhdeeptho - set TVH adapter oiptions - skip first 1880 bytes and signal statistic interval 4000ms

[tvhdeeptho]

@crazycat69 skipping 1880 bytes is not needed because the CC error reportting is in the driver. CC's at startup is not a real problem.

I will test the signal statistics setting

[tvhdeeptho]

This is an analysis of a few hours of watching rete 4 (12522V). Part of it is watching in timeshift mode (skipping over commercials and jumping backward a few times) with rete 4 also being also recorded to file.

Tuner used is adapter2. No other tuners in use. no background epg scanning. SNR=12.3 dB. Status period was set to 4000 on all tuners.

uptime is 2 days, so epg scan has been run at night twice using all tuners (but not during the experiment). Like I said earlier: I have the impression that packet loss occurs not at all or less after the system has been freshly cold booted.

Viewing should be perfect (good signal, light load, lots of memory...), but from time tot time CC errors occur. This shows as visible distortion in the picture. The kernel reports CC errors. I have removed the CC errors just after channel tuning in the report below.

Nov 17 13:39:23 streacom kernel: [176394.152923] dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x1ed3 expected 0x1 got 0xa Nov 17 13:48:04 streacom kernel: [176915.187272] dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x5b4 expected 0x1 got 0x2 Nov 17 14:11:22 streacom kernel: [178313.773045] dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x5e6 expected 0xd got 0xe Nov 17 14:12:47 streacom kernel: [178398.893149] dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x5dc expected 0x5 got 0x6 Nov 17 14:27:43 streacom kernel: [179294.463291] dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x5e6 expected 0xe got 0xf Nov 17 14:37:27 streacom kernel: [179878.732328] dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x1e79 expected 0xa got 0xb Nov 17 14:44:52 streacom kernel: [180323.723089] dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x5e6 expected 0x1 got 0x2 Nov 17 14:45:24 streacom kernel: [180355.537718] dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x5f0 expected 0x6 got 0x7

[tvhdeeptho]

I just did an experiment on tf1 series films. 12648V 13.2dB. signal level good: 13.2 dB This is the channel on which I notice the most CC errors among the multistreams on 5.0W, so it is a good one to use in tests.

The experiment is as follows: -watch this channel for 49 minutes with tvheadend. to kodi; status period set to 4000, but after a while I changed it to 8000. -Then power off the system -watch this channel again for 49 minutes with tvheadend. to kodi; status period set to 8000.

I then analyse the kernel log and check for CC errors. These errors always come in bursts (lots of them at the same time).

Here are the results:

Before the poweroff and reboot:

error bursts occur on average every 1.29 minutes the average number of CC errors per minute is 7.3 very visible distortion in picture. Sometimes kodi starts to rebuffer

After the poweroff and reboot

error bursts occur on average every 3.2 minutes the average number of CC errors per minute is 0.6 little visible distortion

So 10 times fewer errors after a power off/power on cycle, but still not a perfect result. For me, this points to an error with the card or (less likely) the driver.

Also: professional cards can be expected to be used for a long time without power cycling. So the fact that the number of errors increases over time is a major problem for professional applications.

Hopefully TBS can look into this problem.

The errors do NOT correlate with status requests by tvheadend: Some of them occur in between status checks.

Log files

x.log y.log x1.log y1.log

x.log: tvheadend trace/debug for linuxdvb before reboot y.log: kernel log before the reboot

x1.log: tvheadend trace/debug for linuxdvb after reboot y1.log: kernel log after the reboot

How to analyze

The bursts can be counted like this grep -o '(.*)streacom kernel' y.log|sort|uniq|wc -l

Alternatively, the total number of CC errors can be counted like this: first count the error lines. Then add the number of suppressed callbacks grep -o 'dvb_dmx_swfilter_packet: TS packet counter mismatch.' y.log|wc -l grep 'callbacks suppress' y.log

[Davin622]

Hi Could you test the 6909x alone , unplug the 6908 card? Just the multistream frequencies have those problem? or all the frequencyes have the same problem? and Could you give me the SSH? We can check it on your server.

[Davin622]

Hi tvhdeeptho, maybe there is something wrong with "fe_stid135_manage_matype_info" function(stid135_drv.c)? This is the TS control setting.We can debug it. Could you give me the SSH by email.(Davin@tbsdtv.com). Best Regards

[tvhdeeptho]

@Davin622

ssh access is not possible but I can run some tests for you if you have suggestions.

Small things I already tested, for channel tf1 series fim ( Demod=3 matype=0xda ) are below. No result yet. I am just playing around, trying to understand this part of the driver

The lines below refer to stid135_drv.c:

line 4711:

error |= ChipSetField(pParams->handle_demod, FLD_FC8CODEW_DVBSX_HWARE_TSCFG0_TSFIFO_BITSPEED(Demod), 0);

=> changing 0 to 2 has no effect on the problem, but perhaps this is only for bitrate reporting and has no effect on the actual stream?

---

line 4714

error |= ChipSetField(pParams->handle_demod, FLD_FC8CODEW_DVBSX_HWARE_TSPCRPID1_SOFFIFO_PCRADJ(Demod), 1);

Commenting this out has no effect on the problem. This should turn on pcr adjustment (but there is no PCR programmed anyway? So logical that it has no effect)

--

line 4723

    error |= ChipSetField(pParams->handle_demod, FLD_FC8CODEW_DVBSX_HWARE_TSSTATE1_TSOUT_NOSYNC(Demod), 0);

Changing vale to 1 instead of 0 has no effect on the problem

[Davin622]

@tvhdeeptho Could you try disable(line 4737~4743) if((fld_value == 0) || (fld_value == 1) || (mis)) { error |= ChipSetField(pParams->handle_demod, FLD_FC8CODEW_DVBSX_HWARE_TSCFG0_TSFIFO_BITSPEED(Demod), 0); } else { / sliced mode / error |= ChipSetField(pParams->handle_demod, FLD_FC8CODEW_DVBSX_HWARE_TSCFG0_TSFIFO_BITSPEED(Demod), 1); error |= ChipSetOneRegister(pParams->handle_demod, (u16)REG_RC8CODEW_DVBSX_HWARE_TSBITRATE1(Demod), 0x80); error |= ChipSetOneRegister(pParams->handle_demod, (u16)REG_RC8CODEW_DVBSX_HWARE_TSBITRATE0(Demod), 0x00); }

Is there some thing changed of the status?

[Davin622]

@tvhdeeptho Could you tell me the information of frequency (12648V). We have not lock it. maybe the pls code is wrong.

[tvhdeeptho]

About the frequency: see https://en.kingofsat.net/pos-5.0W.php This beam is aimed at France, but reception reports in a large part of europe are good according to king of sat 12648.00 | V | KA4 | Super | DVB-S2PLS: Gold+121212 | 8PSK ACM/VCM Stream 1 | 29500 8/9 | F, 24.9 Mb/s

I will test the code suggestions

[tvhdeeptho]

Here is the result of the test in which I compare the original code with "Could you try disable(line 4737~4743)"

1. still with the old driver (but perhaps some small register change because I still used the modified driver of yesterday; yesterday this was definitely not as bad as today)

test on tf1 series from 20:02 to 20:55 37 "dvb_dmx_swfilter_packet: TS packet counter mismatch.'" per minute So this is really bad. There was also frequent picture distortion and some "short pausing" of the video

2. After the code change, the result is much better (but this could also be due to reloading the driver) but not perfect. Picture distortion and small video pause (rebuffering?) is much less from 20:58 to 21:23 2.2 "dvb_dmx_swfilter_packet: TS packet counter mismatch.'" per minute

3. I then changed the code back to what it was (not disabling the lines). test between 21:40 and 21:57 2.35 "dvb_dmx_swfilter_packet: TS packet counter mismatch.'" per minute

In all cases the only tuned channel is tf1 series

Conclusion:

1. perhaps the driver reload fixed something temporarily?
2. In any case there are always about 2 CC errors/minute (a CC error can correspond to more than 1 lost packet)
3. Note that this error level (2/minute) still much less than after cold boot (but I did not try cold boot this time)

[Davin622]

@tvhdeeptho Thanks for your test report. it show that modify this function(fe_stid135_manage_matype_info),the problem can be improved. Because the datasheet have not more detail of those registers. so just try it one by one.

[tvhdeeptho]

After an epg scan last night and still with the code commented out: I get 94 dvb_dmx_swfilter_packet: TS packet counter mismatch lines in 20 minutes. So still 5 errors per minute.

For my next test (starting now), I simply restart the driver to see what happens sudo systemctl stop tvheadend sudo modprobe -r tbsecp3 ;sudo modprobe -r stid135 sudo modprobe stid135; sudo modprobe tbsecp3; sudo systemctl start tvheadend So this is to test the influence of driver initialisation

Bow I get 44 errors in 21 minutes: 2 per minute. Slightly better, but I still see serious picture distortion just now. Not a solution!

@Davin622 the stid135 chip was developed in France, so ST should be able to give you some advice on the parameter settings.

As the errors come in bursts it is possible that it is affected by the TSDLYSET registers. The driver programs: 0x312b00 If I do not make a mistake, this means: SOFFIFO_OFFSET=00 automatic => Could try to change it to 01? Short latency? So 0x712b00?

Hysteresis_threshold=3 FIFO minimal (for test or simulation) => "for test or simulation" sounds like it is not supposed to be used normally Perhaps replace it wih 0? So 0x012b00?

SOFFIFO_SYMBOFFS = 0x12b00 = 76544

I think 0x012b00 would be the first thing to test. The datasheet is very unclear, but it might mean that fewer but larger bursts of data will be sent.

[tvhdeeptho]

Result for TSDLYSET=0x012b00 2.7/minute and picture distortion from time to time

[crazycat69]

try play with TSSTATE1_TSOUT_NOSYNC https://github.com/tbsdtv/linux_media/blob/latest/drivers/media/dvb-frontends/stid135/stid135_drv.c#L4722 This conditional case from me for Eumetcast 10E VCM without ISSYI, maybe need force TSSTATE1_TSOUT_NOSYNC = 1 in your case, or 0:)

[tvhdeeptho]

@crazycat69 Thanks for the suggestion. I will have a look.

For future reference: Here are some results from yesterday and of last night, still with TSDLYSET=0x012b00. Run 1: 13:14 - 18:54 4.5 messages per minute dvb_dmx_swfilter_packet: TS packet counter mismatch. Run 2: 23:07 - 02:45 3.9 messages per minute dvb_dmx_swfilter_packet: TS packet counter mismatch.

[tvhdeeptho]

@crazycat69

try play with TSSTATE1_TSOUT_NOSYNC https://github.com/tbsdtv/linux_media/blob/latest/drivers/media/dvb-frontends/stid135/stid135_drv.c#L4722 This conditional case from me for Eumetcast 10E VCM without ISSYI, maybe need force >TSSTATE1_TSOUT_NOSYNC = 1 in your case, or 0:)

It seems I already tried setting this to 1. There was no effect. See also earlier messages in this thread.

[tvhdeeptho]

I think the real problem is not with some register that needs an another value. How can it be explained that the problem becomes much less after a cold boot?

• It is almost as if some internal clock in the card gradually gets out of sync with some clock in the PC,
• or some "bad things" are remembered from an epg tune (epg scanning at night).

Just to exclude all possibilities I have not powered off the machine and connected the card to another pciexpress slot. At the same time I set the pci express speed to 3 (it was 2; I experimented with this before). All of this is to create some hardware changes (but I do not think I have a hardware problem!)

After the reboot, as usual the number of errors is much less

The first 14 minutes into the test I have not seen a single error. 16:28: start 16:42: 7 error messages 16:45: 7 error messages 16:57: no more errors yet (I stop looking now) There is no unusual activity by other programs at the error times. TVHeadend reports the CC errors of course (like the kernel does)

Is there a way to really power off the card without actually powering off the PC? Something stronger than "modprobe -r tbsecp3; modprobe -r stid135; modprobe stid135; modprobe stid135"?

I have also analyzed the log messages produced during the nightly epg scan by annotating fe_stid135_manage_matype_info (line numbers are approximate). The results show which matypes are encountered and such.

Perhaps I can find a channel that causes the problem to start

unique.txt

[crazycat69]

Try set max LLR rate per demod as 129 instead 260 https://github.com/tbsdtv/linux_media/blob/latest/drivers/media/dvb-frontends/stid135/stid135-fe.c#L170

[crazycat69]

for driver reload

rmmod tbsecp3 stid135
modprobe tbsecp3

[tvhdeeptho]

Try set max LLR rate per demod as 129 instead 260

Testing right now. I already see errors (and pixellation) after a few minutes of testing but not too many: 23:58 start 00:02 error burst (one error on each pid) 00:04: another burst 00:10: another burst

[tvhdeeptho]

Try set max LLR rate per demod as 129 instead 260 Conclusion after more testing: does not help

[tvhdeeptho]

Something else that does not work (stid135_init.c): Initialize DVBSX_DEMOD_HDEBITCFG to different value for 4 main demodulators:

{0x941,    0x0,/*was 0x10,*/    STCHIP_REGSIZE_8},  /* REG_RC8CODEW_DVBSX_DEMOD_HDEBITCFG1(1) */
{0x941,    0x0,/*was 0x10,*/    STCHIP_REGSIZE_8},  /* REG_RC8CODEW_DVBSX_DEMOD_HDEBITCFG1(2) */
{0x941,    0x0,/*was 0x10,*/    STCHIP_REGSIZE_8},  /* REG_RC8CODEW_DVBSX_DEMOD_HDEBITCFG1(3) */
{0x941,    0x0,/*was 0x10,*/    STCHIP_REGSIZE_8},  /* REG_RC8CODEW_DVBSX_DEMOD_HDEBITCFG1(4) */

Reasoning was that this might allow more freedom to remove metadata for unwanted slices internally/ I suspect that some slices are dropped from time to time.

[tvhdeeptho]

I am starting to suspect that this problem is specific to ACM/VCM transponders.

[tvhdeeptho]

I am currently experimenting with setting CFR2CFR1 to 0x23 instead of 0x25 in all code lines. This seems to have a positive effect (longer time between errors in short initial test), but not a complete solution + it is too soon to tell if the positive effect is real: start: 20:08 first error burst: 20:28:54 next: 20:29:08 end: 20:38 Not sure why this would work, there are other values to try, and it might have negative effects. In any case this needs more testing.

[tvhdeeptho]

The following test shows that the problem is worsened when two channels on different tuners are active simulateanously: -watch a channel on 23.5E on on tuner (regular dvb-s2; not multistream) -record tf1 series films (multistream, acm/vcm)

The live channel is fine, but the recording is full of pixellation. 11.6 dvb_dmx_swfilter_packet: TS packet counter mismatch messages per second

After the recording stops and I start watching tf1 series the number of errors drops to low level (but the errors are still there): 4-10 minutes between error bursts as opposed to 11 per minute. This is still with CFR2CFR1 set to 0x23 (perhaps relevant, perhaps not)

So this points to either a problem in the card internals, or in the dma system: full transport streams are passed to the kernel because no hardware pid filtering is applied. So the system is stressed but should still be able to handle it.

[tvhdeeptho]

For comparison, I did a quick test -watch the same channel on 23.5E on on tuner (regular dvb-s2; not multistream) -record tf1 on5.0W (also multistream but CCM).

Note that tf1 is a competely different channel than "tf1 series films". It is also on a different transponder. Both transponders are multistream and both are 25 Mbit/s. However, one is ACM/VCM and the other is CCM

This test works without errors in the first few minutes (10 minutes of testing).

So the conclusion might be that the problem is ACM related, but also load related.

I also verified that in the linux kernel there have not been buffer overflows in any of the tests and that linux is never more than 1 dma buffer behind in reading (even though 16 are available)

So this means that the problem is probably NOT in how linux handles the data.

It must be some problem in the card or the way it is configured.

[tvhdeeptho]

Another test: tf1 series film. I added the following code to fe_stid135_get_signal_quality

        u32 packets_error_count1;
        u32 packets_error_count2;
        error |= FE_STiD135_GetErrorCount(pParams->handle_demod, FE_STiD_COUNTER1, demod, &packets_error_count1);
        error |= FE_STiD135_GetErrorCount(pParams->handle_demod, FE_STiD_COUNTER2, demod, &packets_error_count2);
        packets_error_count1 &= 0x7FFFFF;
        packets_error_count2 &= 0x7FFFFF;

        dprintk("Demod=%d PER=%d+%d mc_auto=%d err=%d\n", demod, packets_error_count1, packets_error_count2,    mc_auto, error);

and noticed the following behaviour in the logs:

30 20:08:31 streacom kernel: [ 5882.770497] fe_stid135_get_signal_quality:2973 Demod=7 PER=0+104 mc_auto=1 err=0
Nov 30 20:08:32 streacom kernel: [ 5883.693956] dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0xdc expected 0xf got 0x6 listcount=7
Nov 30 20:08:32 streacom kernel: [ 5883.693962] dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x1a4 expected 0x8 got 0x2 listcount=7
Nov 30 20:08:32 streacom kernel: [ 5883.693964] dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x78 expected 0xd got 0x3 listcount=7
Nov 30 20:08:32 streacom kernel: [ 5883.693968] dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x140 expected 0x8 got 0xe listcount=7
Nov 30 20:08:32 streacom kernel: [ 5883.693971] dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x208 expected 0xa got 0x0 listcount=7
Nov 30 20:08:32 streacom kernel: [ 5883.795583] dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x190 expected 0x7 got 0x8 listcount=7
Nov 30 20:08:32 streacom kernel: [ 5883.924552] fe_stid135_get_signal_quality:2973 Demod=7 PER=1245+105 mc_auto=1 err=0
Nov 30 20:08:33 streacom kernel: [ 5885.073690] fe_stid135_get_signal_quality:2973 Demod=7 PER=122+105 mc_auto=1 err=0
Nov 30 20:08:34 streacom kernel: [ 5885.678523] fe_stid135_get_signal_quality:2973 Demod=7 PER=36+105 mc_auto=1 err=0
Nov 30 20:08:34 streacom kernel: [ 5886.225349] fe_stid135_get_signal_quality:2973 Demod=7 PER=12+105 mc_auto=1 err=0
Nov 30 20:08:35 streacom kernel: [ 5887.380455] fe_stid135_get_signal_quality:2973 Demod=7 PER=1+105 mc_auto=1 err=0
Nov 30 20:08:37 streacom kernel: [ 5888.530314] fe_stid135_get_signal_quality:2973 Demod=7 PER=0+105 mc_auto=1 err=0
Nov 30 20:08:38 streacom kernel: [ 5889.681554] fe_stid135_get_signal_quality:2973 Demod=7 PER=0+105 mc_auto=1 err=0

This shows that the chip itself detects the errors. Most often the second counter (packet errors) increases by 1 when the error occurs, but sometimes it does not increase. The bit error counter always incrases.

This test was performed with maxllrate set to 180 (90 is too low for some transponders which have a symbolrate > 30 Msamples/second, changing its value has little effect on the problem anyway). Also I used my biggest dish. The signal is very strong: SNR=14.9dB

The main conclusion is that the dma system can be excluded as the source of the problem.

[tvhdeeptho]

Variant of the previous test, but now with all FSPYCFG registers set to 0xac. This should give errors about "Debug, Viterbi decoder 1 output"

This counter increases similarly.

This brings little new information.

[tvhdeeptho]

Using FE_STiD135_GetStatus followed by
fe_stid135_reset_obs_registers() and still on tf1 series film.

log.txt I notice the following behaviour which accompanies continuity counter errors: bbfcrcko=1 => baseband frame errors ; upcrcko=1 or 2 => not sure what this means

On the other hand pktdelin_delock always remains 0 (good), demod_delock also remians 0 (good) and of course error counters increase.

Advice on what to test next is welcome

[JianSun1]

Have you tried to change circular buffer sizes (increase them)? try to search "dvb_ringbuffer_init" function (look for the files in dvb_core folder : dmxdev.c or maybe others i think) and increase the sizes.

Another suggestion: try to forcely set cold lock, warm lock, blind search mode respectively by changing the related register value (AEP).

Another one, "Reset the packet delineator" (ALGOSWRST) by setting the related register value 1 and 0 without putting a delay between register sets. You may do it every 4 or 8 seconds, maybe you can put it on signal_status request function. Seems like not smart solution but just try to get idea.

[Delitants]

6909x is indeed a garbage card. Never buy it. CC are reported every minute for no reason during playback, while on 6909 no such problems. Also has a "clogging" problem, when few tuners are locked, and another tuner is used for scaning at the same time, it hangs up

mpegts: too much queued table input data (over 2MB) for TurboSight TBS 6909x (Octa DVB-S/S2/S2X) #11 : DVB-S #3, discarding new
mpegts: too much queued table input data (over 2MB) for TurboSight TBS 6909x (Octa DVB-S/S2/S2X) #11 : DVB-S #3, discarding new

[tbsiptv]

6909x is indeed a garbage card. Never buy it. CC are reported every minute for no reason during playback, while on 6909 no such problems. Also has a "clogging" problem, when few tuners are locked, and another tuner is used for scaning at the same time, it hangs up

mpegts: too much queued table input data (over 2MB) for TurboSight TBS 6909x (Octa DVB-S/S2/S2X) #11 : DVB-S #3, discarding new
mpegts: too much queued table input data (over 2MB) for TurboSight TBS 6909x (Octa DVB-S/S2/S2X) #11 : DVB-S #3, discarding new

Hi Neolo

Sorry for the inconvenience ,please send email to our support@tbsdtv.com

Thanks

Kind Regards

[Delitants]

Thank you, already getting a replacement.

On May 21, 2020, at 11:15 PM, tbsiptv notifications@github.com wrote:

6909x is indeed a garbage card. Never buy it. CC are reported every minute for no reason during playback, while on 6909 no such problems. Also has a "clogging" problem, when few tuners are locked, and another tuner is used for scaning at the same time, it hangs up

mpegts: too much queued table input data (over 2MB) for TurboSight TBS 6909x (Octa DVB-S/S2/S2X) #11 : DVB-S #3, discarding new mpegts: too much queued table input data (over 2MB) for TurboSight TBS 6909x (Octa DVB-S/S2/S2X) #11 : DVB-S #3, discarding new Hi Neolo

Sorry for the inconvenience ,please send email to our support@tbsdtv.com mailto:support@tbsdtv.com we will help you replace the 6909x with new hardware version 6909x v2 which fixed this issue .

Thanks

Kind Regards

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/tbsdtv/linux_media/issues/179#issuecomment-632588600, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAVUSNVLUKCXQADJBKRI35DRSY7BRANCNFSM4JHMXLFA.

[Delitants]

Well, after so much struggle, V2 of 6909x did not make any difference, board looks exactly the same as original V1 and I'm unable to tune more than 2 tuners, it's all in CC errors and losing lock. Thinking to give up on 6909x (old 6909 has no issues tuning the same transponders, all 8 tuners at a time). This is the biggest failure ever of this TBS company, period.

---

---

Watch for the board layout. Don't buy if it looks like on the left two, only the one on the right is working OK. If they ever released that kind at all. Green color numbers are LSPCI device ID, they are all 6909X. V1 on the left, V2 in the middle and V2 unnamed prototype on the right.

[Davin622]

Hi sir, We have test them on our side, they are work fine with the TVH and astro, hope you can give us the SSH, let us check drivers print and the chip status. like your said , V2 can work fine with the astro ,i think it also work fine with the TVH, it maybe just the setting problem. they are call the same drivers interface.

[Delitants]

V2 prototype is the only one I said works. The official V2 you have released is terrible. I can give SSH, please respond to an email conversation I have with you.

On Sep 4, 2020, at 11:55 PM, Davin622 notifications@github.com wrote:

 Hi sir, We have test them on our side, they are work fine with the TVH and astro, hope you can give us the SSH, let us check drivers print and the chip status. like your said , V2 can work fine with the astro ,i think it also work fine with the TVH, it maybe just the setting problem. they are call the same drivers interface.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[ovidiu31]

@Neolo There are couple of very important bios settings to tune especially on pcie slots . Very important also which settings you are choosing UEFI or Legacy for pcie management. We've had similar issues and till we tinkered properly the bios on pcie side especially , but once you've setting up correctly your bios on pcie side everything works perfect. V2 actually fixes cc errors and fe no lock errors in astra cesbo. Kindly please post here pastebin or cpaste DMESG log

[Delitants]

@Neolo There are couple of very important bios settings to tune especially on pcie slots . Very important also which settings you are choosing UEFI or Legacy for pcie management. We've had similar issues and till we tinkered properly the bios on pcie side especially , but once you've setting up correctly your bios on pcie side everything works perfect. V2 actually fixes cc errors and fe no lock errors in astra cesbo. Kindly please post here pastebin or cpaste DMESG log

Look, it's been 6 month I'm dealing with this, I even bought a new PC with different motherboard. Do you really think I didn't dig a bios? UEFI or not it does not matter. I own 2x6909X V1, they sent me two replacements, one is working fine (but only in Astra, TVHeadend simply not locking on it), which is on the picture on the right. The second replacement looks exactly the same as my old card, and it has the same symptoms as an old card, distorted picture, lock losing. It can work only if I don't tune more than 1-2 (hardly) transponders at a time. Have you tested your "perfect" in Unicable II mode? Well i bet you didn't, because this is the way my dish is set up.

---

Watch the video: Screen Recording 2020-09-04 at 9.29.56 PM.mov.zip

DMESG is covered with these messages

[26111.657929] fe_stid135_set_maxllr_rate rate 180 [26127.803153] fe_stid135_set_maxllr_rate rate 180 [26144.913904] fe_stid135_set_maxllr_rate rate 180 [26162.567837] fe_stid135_set_maxllr_rate rate 180 [26198.340556] fe_stid135_set_maxllr_rate rate 180 [26213.865097] fe_stid135_set_maxllr_rate rate 180 [26229.714197] fe_stid135_set_maxllr_rate rate 180 [26264.836387] fe_stid135_set_maxllr_rate rate 180 [26333.845712] fe_stid135_set_maxllr_rate rate 180 [26349.822506] fe_stid135_set_maxllr_rate rate 180 [26369.557673] fe_stid135_set_maxllr_rate rate 180 [26388.468071] fe_stid135_set_maxllr_rate rate 180 [26408.484799] fe_stid135_set_maxllr_rate rate 180 [26427.530345] fe_stid135_set_maxllr_rate rate 180 [26446.294469] fe_stid135_set_maxllr_rate rate 180 [26465.368063] fe_stid135_set_maxllr_rate rate 180 [26540.261209] fe_stid135_set_maxllr_rate rate 180

[ovidiu31]

@Neolo

1.)UEFI or not it does not matter. Very very wrong way of thinking , BIOS settings matter a lot more than you thinking especially on setting up properly IRQ's and offer the proper pcie resources to the DVB card for example in LEGACY Bios mode.

2) Based on the movie you sent i could say or guess you have a three or something that constantly is interacting with signal of the dish and disturbing it , so no offense but sending zipped movie = with ZERO (its not very professional way to debug and fix tech issues)

3) Please check below an example of proper dmesg log (how to send) root@microcms:~# dmesg | cpaste Successfully pastebined to: https://paste.centos.org/view/5fe439ea https://paste.centos.org/view/5fe439ea ---> this is the right way of sending dmesg log to be able to see what is going on. Also i would highly suggest providing kernel version uname -a command output

4) I took the liberty to check your other raised issues and as far i understand your hardware platform is based on x99 chipset with some 10-12 cores Xeon socket 2011 v3 Had almost identical issues with x99 Asus + E5-2630 v3 and EVGA x99 + E5-2620 v3 . Using x99 chipset (instead of xeon dedicated C612 chipset) alongside with E5 Xeon CPU's triggers a nasty PCIE bug where IRQ's are constantly messed up in UEFI bios mode , even if you manage to setting and assign them manually in LEGACY bios mode they will still mess. This x99 pcie bug will affect functionality of any pcie connected device. Now the interesting fact ... i've had a spare i7 5820k socket 2011 v3 and i replaced one of the E5 Xeon .... Guess what ? No more pcie issues , dvb or gpu connected was working just fine. Now i've moved to intel chipset z390 + i9 9900k CPU and it is totally stable and working awsome. So yes some X99+E5 Xeon v3 = big problems on pcie side

As for the "perfect" unicable II you are mentioning ... unicable II was mainly designed for home/consumer usage with multi tuner STB/Receivers

Also actually Unicable status/support is well specified on TBS6909X page Unicable Compatible (magic word here is compatible)

5) Just very friendly advise would be: doesn't matter how frustrating could be the fact that technology doesn't want to bend to our will but avoid saying or writing things like these :

Why? Multiple reasons

• Company very easy can get rid of you by refunding you and never ever sell nor support you directly
• First dig and dig and test and tinker and dig again and test again with all possible existing resources you have at your hand then throw the issue to the manufacturer
• Secondly , did you scroll/read through other people posted/reported issues? Nobody had/has such language as yours , aren't you educated?
• Thirdly , 99% of your GitHub reports/posts reflect just a bully - troll behavior which tbh fits for reporting and blocking( f..k sake man ... what are you? a kid? pull yourself together)

[Delitants]

@ovidiu31 Read this statement again, it will oppose entire of your post:

Old card 6909 works flawlessly with the SAME transponders, SAME dish, SAME Unicable 2 settings, SAME motherboard, SAME coax cables.

if you'd say that none of the TBS cards work with my config, that would be completely different conversation. There is not a single person here who confirmed this 6909X card to be a garbage. Take a look.

Now question is - why the heck we need to suffer SO MUCH with this damn 6909X comparing to old 6909, with all those accusations of bios settings, motherboard, my dish, my unicable? Answer is simple - this is a faulty product or faulty driver. TBS already admitted that 6909X initially went defective. No doubts it's still is after v2 replacement attempts. NOTE: Only ONE V2 replacement which is photographed above on a right is working with no troubles, without any extra headaches. That card is called a prototype, pre-release, which has no logo on it or serial number. It has a completely different board layout. Does this tell you anything? Or you'll just ignore this again and continue digging my settings?

So gather your sh*t together and work it out please and stop making things look like it's client's issues, despite of all evidences.

[Delitants]

BIOS settings matter a lot more than you thinking especially on setting up properly IRQ's and offer the proper pcie resources to the DVB card for example in LEGACY Bios mode.

I've already told it makes no difference. What else you want me to do? Tell exactly what else to change besides of UEFI/Legacy. Moreover, not all mobos have these settings at all. Then what?

I took the liberty to check your other raised issues and as far i understand your hardware platform is based on x99 chipset with some 10-12 cores Xeon socket 2011 v3

NO! You didn't read my previous reply, where I said that I got a brand new PC, AMD based, and the same issue. Skipping 1/3 of your post regarding x99 chipset, disregard that already, verified. New system is - read dmesg attached. https://paste.centos.org/view/d7831977#3godfPdlIdeMzmMMYLUW6eMtWcGATo8i

Based on the movie you sent i could say or guess you have a three or something that constantly is interacting with signal of the dish and disturbing it , so no offense but sending zipped movie = with ZERO (its not very professional way to debug and fix tech issues)

Did you expect me to publish it on youtube with Hollywood glittering special effects? ZIP is the way to attach it here, FYI. And no, there is nothing is interacting on those particular unicable slots I've assigned on video, simply because I tested them on 6909 card and it didn't show such a behavior. Neither helps if I change unicable freqs to something far away unallocated. Trust me, I know much more about things as you think.

unicable II was mainly designed for home/consumer usage with multi tuner STB/Receivers

So? Do I give a damn it was designed for? It works with any other tuner like 6909, but 6909X.

### Now, listen to me, I'm a proud owner of Wavefrontier T90 multifeed dish with 10 converters and 5 Unicable II Inverto and Terra switches, carefully designed and calibrated and time proved with a bunch of tuners including Dreambox and AB Cryptobox, bunch of TBS tuners and consumer TVs. The complexity of my setup is not even found in any commercial place like hotel. So you please omit your idiotic remarks, save them for someone like your gramma. Okay?

Unicable Compatible (magic word here is compatible)

So? 6909X officially declared it's support. Moreover, unicable is a pure programmatic support, not a hardware.

Company very easy can get rid of you by refunding you and never ever sell nor support you directly

Go for it and I will spoil company's reputation on every single possible forum or review. it will take me an hour or so and will take thousands or lost potential customers for company. Worth it? Give it a try.

First dig and dig and test and tinker and dig again and test again with all possible existing resources you have at your hand then throw the issue to the manufacturer

If you'd read this thread at all and paid attention to timestamps, you would know how much time is wasted on this product. I said I spent 6 month already. How dare you telling me this?

Thirdly , 99% of your GitHub reports/posts reflect just a bully - troll behavior which tbh fits for reporting and blocking( f..k sake man ... what are you? a kid? pull yourself together)

Imagine yourself robbed for $900 and then reading these "this is customer's fault" posts. How would you calm you'd be? Huh? This is a disgrace. Go ahead, block, report, whatever. Less people will buy this crap. you will not make any more damage to me with that action. Silly.

[Delitants]

I can't believe this person just ignored an obvious evidences, comparisons with older TBS products, changed workstation and just keep shitting on me with dummy screenshots, like some sales person at the front desk uses a reply templates. And after all he says I'm bully and deserve to be blocked. Really?

[ovidiu31]

For me its very obvious and clear your degree of professionalism ... Just by clicking on the link you provided https://paste.centos.org/view/d7831977#3godfPdlIdeMzmMMYLUW6eMtWcGATo8i

Look at your answers ... 10 people of 10 will agree with me. I've heard that you did not even had the decency to provide an ssh access to the development team to gather properly the issues logs.

Stop whining and fooling around and assist the TBS tech by providing them proper logs , proper ssh and remote access , Contribute to the progress ... do a constructive criticism not a destructive one

Man i have sold more than 1500 x 6909X and so far only 8 cards RMA back to me. Buried over 20000 euro in TBS Norsat Wavefrontier Centauri Invacom and Inverto equipment And i have no regret .

When something was damaged or with issues i've just sent it back

If something not working .... RMA back... plain and simple... it is the first rule of the consumer TBS6909 gone ... EOL plain and simple ... Live with this .... If you don't like 6909X RMA back IF you don't like 6909X v2 RMA back RMA BACK is the keyword