-
Notifications
You must be signed in to change notification settings - Fork 83
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TBS6903X problems with DVB-S2 MIS/PLS #316
Comments
The lost packets problem is probably not a bug: I just tested this mux, with tbs6909x, which has exactly the same Are you sure your disk is fast enough? Try capturing to /tmp (which is on ramdisk). When running neumodvb or the "neumo-tune" program, capturing can be done with and analysis with (part of tsduck) |
Thanks both, I haven't made any mod to the card, but I will get chance tomorrow to take it out of the machine and take a picture. I will post that on here. The disk should be fast enough - but to be certain, I've just tried recording to /tmp/rai.ts as described above - the file is still corrupt. Transedit in Windows shows the missing packets, and you can see the corruption in the video streams when playing the file back in VLC - Oddly, tsanalyze doesn't show any corrupt packets for either of the recorded files, so I guess the packets in question must actually be completely missing.
I've just also re-tested the French MIS transponder (12732V 29500), and I'm actually getting the packet dropping problem on there too. Again, the signal level is OK - 13.5dB C/N (greater than the just under 11dB required for 8PSK 8/9). |
Stream corruption does not detect corrupt packets, but missing packets. You should check for continuity errors Do you have any settings in /etc/modprobe.d/tbsecp3.conf or /etc/modprobe.d/stid135.conf? |
There's nothing for tbsecp3.conf but stid135.conf has the following -
I was having general locking problems (timeout) specifically with TVHeadend using the deeptho drivers, so I moved back to this branch which works OK (other than MIS still of course). I will try again and run those continuity tests though. I may have had some settings wrong to be causing that additional problem, the TBS6903X seems to generally be causing me headache for some reason! |
media: dvb-frontends/stid135: Optimized ts_nosync option. mis option removed, forced TS FIFO Minimum latence mode only when ts_nosync=1 (especial for Eumetcast users) P.S. try ts_nosync=1, maybe this help |
Thanks, I changed the option to I still have the same problem of the card refusing to lock any other "plain" DVB-S2 after locking MIS/PLS. TVHeadend seems to be able to successfully lock the French channels on 5°W 12732 MIS1/4/6 without any dropped or corrupt packets - so that doesn't seem to be a problem. However, the Italian muxes e.g. 11179V have continuity errors and dropped packets in TVHeadend (like with tsduck as tried earlier). This is the case both when using ROOT+16416 or GOLD+131070 PLS values, there is always lots of corruption in the stream. The signal level is around 11dB C/N, so well above the threshold for perfect reception. Reloading the TBSECP3 driver is still the only way to make plain DVB-S2 work again after tuning MIS/PLS. |
look like stid135 driver issue, fixed |
About RAI TS corruption - maybe wrong max LLR auto-setup in get_current_llr()
|
Thanks, I can confirm that the stid135 driver fix solves the problem of not being able to lock DVB-S2 after locking PLS - plain DVB-S2 now successfully locks after tuning PLS without a driver reload. The switch is a little slow, for example with a few seconds wait between leaving 12732 V 29500 MIS 1 PLS and tuning 11461 H 5780 (plain DVB-S2), but the service does then start to play successfully after this. The Rai mux glitching still persists, and switch from MIS -> MIS seems slow and a little glitchy, it sometimes takes two attempts (this may be related to the bug with the Rai muxes as I'm testing switching Rai to French mux and vice versa). Here's the kernel log -
The stid135 error was the first time on tuning Rai. The very high MLLR values do seem to occur when the Rai mux is tuned -
The French MIS transponder has consistently low values in contrast, with no glitches. |
The long wait time MIS -> MIS does seem to be related to the problem with the Italian MIS transponders. Switching from French MIS to another French MIS is fairly quick and works fine - both the separate streams on the same transponder (e.g. 12732V MIS1 -> 12732V MIS6) and also between the two transponders (e.g. 12732V MIS1 -> 12648V MIS2). |
Thanks @crazycat69 , sorry for the delay - I will try this. I haven't had the time recently. I will report back. |
I can confirm the latest changes to LLR calculation seem to fix Rai multistream on 5°W. Thanks! MIS -> DVB-S2 switching and vice versa now seems to work well. I now seem to have the opposite problem though, trying to lock plain DVB-S seems to crash the driver in a way that causes TVHeadend to totally crash! This isn't so much of a problem as not much that I want to tune is left in DVB-S. This issue like the DVB-S2 issue only seems to happen if MIS has been tuned beforehand. The second tuner on the card is connected to a 19.2°E LNB which doesn't ever need to tune MIS/PLS (as there is none!), and DVB-S works OK on that one. Thanks again for your help |
check kernel log after switch from DVB-S2 MIS/PLS transponder to DVB-S |
The same problem occurs even if I scan the data transponder. For example, Eutelsat 16A, freq. 12507 H. Subsequently, nothing can be scanned from DVB-S2 transponders. Only a driver reset will help. There is no problem with DVB-S. |
For the DVB-S issue it seems to be muxes with lower symbol rates that just don't lock. Here I tried the following on 30°W - 11329 H 9141 DVB-S2 PLS GOLD+174526 single stream - locked OK, shown in the kernel log Then I moved the dish to 7°E and tried - 10722 V 27500 DVB-S - locked OK, nothing shown in kernel log.
Switching Italian MIS -> French MIS on 5°W does now seem to work OK, not perfectly but to a usable level. After tuning an Italian MIS mux, trying to tune one of the French ones fails at first but then locks successfully when TVHeadend automatically retries. Kernel log for this, it seems like it does tune on the first attempt but TVHeadend doesn't receive any data until the second attempt (at 16:03:37) -
|
Still some DVB-S issues with TVHeadend. 30°W is the test case I can always replicate it with. TVHeadend fails to tune both 11644 V 4000 DVB-S and 12519 V 1481 DVB-S. If I disable the tuner and use tune-s2, this then also fails (timeout with no signal lock after several seconds). If I then run When the driver has been reloaded, there's no signal problem as you can see -
|
Thanks @crazycat69 , that seems to work much better. DVB-S consistently locks now. |
I recently bought a TBS6903X, and I'm having a strange issue with it using the tbsdtv drivers. System is Ubuntu 22.04 LTS with latest linux_media/media_build, but the same problem happened with Ubuntu 20.04 LTS.
After tuning to a transponder using multistream (MIS) with PLS, it becomes impossible to tune 'plain' DVB-S2 until reloading the tbsecp3 driver or rebooting the machine. I have been testing using the Italian and French multistream transponders on Eutelsat 5°W, as detailed in this thread on the official TBSDTV forum, from post #6 onwards - https://www.tbsdtv.com/forum/viewtopic.php?f=181&t=25844
There is also an additional problem, in that the Italian Rai MIS/PLS transponders such as e.g. 5°W 11013 V 35300 PLS ROOT+16416 / GOLD + 131070 ISI 3 lock but the data stream is then corrupt with missing packets (also detailed in that thread). Oddly, the French transponder 12732V 29500 PLS GOLD + 50416 MIS1/4/6 works OK with no corrupt packets.
I have since tried the deeptho branch of these drivers - https://github.com/deeptho/linux_media/ This seems to fix the issue of DVB-S2 not locking after locking MIS/PLS. Transponders now all lock successfully without having to reboot/reload the drivers. However, the problem with the Italian Rai multistream is still present, with dropped TS packets -
Comparing the amount of corrupt/dropped packets with the same test performed with the tbsdtv drivers (screenshot in the TBSDTV thread linked above), I would say that the deeptho drivers improve the situation but there is still some problem as you can see in the above screenshot - the amount of dropped packets is less but still more than 0 (with image/sound glitching).
The signal level is adequate for perfect lock (~10dB C/N with modulation: 8PSK and FEC: 2/3), and my older TBS6905 card has no issues with locking these transmissions when connected to the same satellite dish.
I thought this may be a faulty hardware problem, but I've since had it confirmed by a contact who also owns a TBS6903X device and uses the deeptho drivers that they also get glitching on this Italian Rai transponder on 5°W.
So in summary there seem to be two bugs - the first is the problem with locking plain DVB-S2 after locking PLS/MIS which seems to exist in this version of the drivers but not the deeptho fork. The second bug is the dropped packets on some PLS/MIS transponders - specifically Rai on 5°W 11013 V 35300. This bug is present in both this version and the deeptho fork, but possibly worse in this version.
Any help would be greatly appreciated!
Many thanks,
Adam
The text was updated successfully, but these errors were encountered: