Topics

experiences and lessons learned with a fresh Eumetcast install for WIndows and Linux

Markus Kempf
 

I have used Eumetcast since 2005 and did a few posts to this group a long time ago. My receiving system started on a Pentium system that was up to date in 2005 running Windows XP. I later migrated to Win7 on a new hardware (2014) and finally to Win10 about three years ago. The old Tellicast sw installation just worked and I never touched it. For other reasons, I had to make a completely new fresh installation of Win10. I decided to finally update my old setup and downloaded/replicated the Eumetsat directory at:

ftp://ftp.eumetsat.int/pub/OPS/out/user/EUMETCast_Support/

After a short read of the documentation I downloaded the latest TBS Win10 drivers for my 5925 and Crazycats BDADataEx because I need Diseqc switching, something TVB's IP tool does not provide. I knew that already, but for a newbie it should be mentioned in the Eumetcast documentation.

https://www.tbsdtv.com/download/

After about 15min of downloading, installing and configuring, the system was up and running, receiving my usual data (actually much more because I did not edit the channels configuration :-). I believe that almost everybody could do this in a reasonable amount of time with the docs available and given the fact that the stuff simply works.

Then I got the idea that the Eumetcast reception could be done with my new NAS server system, replacing the old PC and saving some electrical energy and money because the NAS runs 24/7 anyway. I had the same idea a few years ago, but the old NAS server was ARM based and the proprietary Tellicast client is not available. The new system is Intel based, so it seemed perfectly fit for the purpose. I was quite confident that this would work in a short amount of time, given my 35 years of experience working as an engineer in the IT industry and beeing a Unix native... Unfortunately, that was a fallacy. The current state of the software and documentation provided by Eumetsat makes it very unlikely that a normal user will succeed. My biggest mistake was not to search in the archive of this group, because most problems have been addressed already by Christian Peters and Ernst Lobsiger.
My NAS server uses Debian 10, with a backport kernel 5.4. Unlike Ernst/Christian, I like to use systemd, so I'm not a real Unix greybeard...

1) DVB device driver
Even after so many years, the installation of the device drivers for a TBS5925 is still a mess, because they are not part of the slipstream process and have to be compiled by the user and for every new kernel version. That's a real pain for every system not totally dedicated to Eumetcast reception and nothing else. I have used the install scripts at:

https://github.com/tbsdtv/linux_media/wiki

The drivers work, the device gets recognized. Unfortunately the procedure taints the signed kernel and some debian provided modules will no longer work (eg.my USB soundcard).
In the Eumetsat documentation you could eiher use the 2014 or 2016 drivers or the above method depending on which document you read, no consistency at all.

2) EKU software
The crypto dongle, unfortunately still needed, that I use, is the original Aladin dongle ID 0529:0514 Aladdin Knowledge Systems eToken Pro v4.2.5.4. After following the advice in EUMETCast_Support/tellicast-client-pre-release/linux/README_Safenet_EKU_linux.txt, the dongle was not recognized by the system, the lsusb command showed nothing. The troubleshooting guide gives a hint, but has outdated info. On a modern Debian 10 system, the file /lib/udev/rules.d/90-hid-eToken.rules must be changed to include idProduct 514. This can also be found in the archives of this group.
SUBSYSTEM=="block" , ATTRS{idVendor}=="0529", ATTRS{idProduct}=="0514|0602|3002|3004|3005|3006|3007", MODE="0777"
SUBSYSTEM=="usb" , ATTRS{idVendor}=="0529", ATTRS{idProduct}=="0514|0602|3002|3004|3005|3006|3007", MODE="0777"
SUBSYSTEM=="usbmisc" , ATTRS{idVendor}=="0529", ATTRS{idProduct}=="0514|0602|3002|3004|3005|3006|3007", MODE="0777"
SUBSYSTEM=="hid" , ATTRS{idVendor}=="0529", ATTRS{idProduct}=="0514|0602|3002|3004|3005|3006|3007", MODE="0777"
SUBSYSTEM=="hidraw" , ATTRS{idVendor}=="0529", ATTRS{idProduct}=="0514|0602|3002|3004|3005|3006|3007", MODE="0777"
I'm really astonished, given the many old dongles, that they break the compatibility with the old devices and do not mention this in the documentation. A normal user will already fail at this point.
The dongle now showed up with "lsusb" but still did not work with tc-cast-client -k. After many hours of research, I found the problem. The library libcrypto must be present in /lib or /usr/lib. This is an error in the DEB control file of the Safenet Authentication client core library and should not happen. Again, a normal user would most likely fail again at this point. The archives of this group give another solution, but this simple symbolic link is good enough.

ln -s /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 /lib/libcrypto.so

3) Diseqc switching
I have a setup with two dishes and four LNBs, so there is the need to switch to the right LNB. Unfortunately, the documentation again does not really mention it. You can find a hint in the config file /etc/channels.conf in a comment #name:frequency:PolarisationDVBStdModcod:diseqSatNr:Symbolrate:::
szap-s2 can switch, but you have to change the entries to your used number. In my case: E1B:11263:hS1:3:33000:::
Again, this would stop normal users and could be clearly explained in a Linux setup guide.

4) smcrouted
Now my DVB device worked, the EKU worked and I created the necessary network devices with EUMETCast_Support/EUMETCast_Licence_cd/Linux/DVB_devices/Common_Apps/dvb-eumetcast-setup.sh. Unfortunately I still could not receive data... A check with service tellicast-client status showed that smcrouted failed, because another one is already running. So at least on a Debian 10 system, the distribution provided smcrouted service must be disabled.
systemctl disable smcroute
systemctl disable smcroute-helper

5) SUCCESS
After many hours of work, the system finally works...

6) some quirks
the reception is worse compared to the Win10 setup. The count of missed packets is much higher.
I still have missing key errors sometimes in my log file
I need to adapt the metrics and stats scripts for my system

Hopefully this long article will help somebody to setup an Eumetcast system under Linux.

Markus

Christian Peters
 

Markus,

thank you for that long article!
That's really interesting and it's good to know there are some other users trying to setup TC on Linux.
Yes, it was really a challenge I never would get the system up without the help of Ernst.
My system runs Debian Stretch and it only runs the TelliCast client software with some basic xrit2pic scripts.
My sytem uses two TBS 5925 to get the data from two transponders. Ernst wrote a special version of dvb-eumetcast and split the the three services on three dummy devices.
Yes, the USB problem, the eToken link and the compiling of the kernel driver for the TBS is really a problem so I didn't touch the system since it runs (now for 214 days without reboot....the last reboot was a power interruption caused by a thunderstorm).

I would love to see an updated script for installing a TC receiver system with a TBS USB device, a TBS PCIe card and a Novra S300N receiver and for one or two Linux distributions like Ubuntu and Debian/Devuan to animate some other people to try Linux as platform. If it runs it runs rock solid! Regarding the reception quality I can't compare but I even get some key errors.

But at my Win10 processor I have to look every day whether the system does a reboot after installing updates in the night...which stops all processing software I have to restart then... :-P
I'm not sure if I would be able to get a Win10 system to not reboot....except disconnecting from the internet... :-D
Maybe all will be much easier if the Linux receiver would use a NOVRA300 hardware....but as the MTG mission will start next year, a third transponder will be set up and I think three of them would be to expensive for me and it would maybe not be possible to use three TBS USB devices like the 5925 on a Win10 or Linux system...!?
I don't know how this challenge could be managed in a easy way....and as the Linux drivers/firmware available for the new TBS PCIe cards is not really working with EUMETCAST....maybe setting up a Linux receiver would be impossible except for really experts in this future!? :-(

But most user know that setting up something in Linux is a challenge and even fun to get it working, but it would be really great if you and Ernst could contact EUMETSAT and could help to update the setup instruction script to lower the bar regarding setting up a Linux TC receiver.

But nevertheless I'm happy with my Linux TC receiver as it runs...but setting it up again I think I would need an updated script and again much help form Ernst and you...! ;-)

Regards,

Christian



Am 10.02.20 um 18:51 schrieb Markus Kempf:

I have used Eumetcast since 2005 and did a few posts to this group a long time ago. My receiving system started on a Pentium system that was up to date in 2005 running Windows XP. I later migrated to Win7 on a new hardware (2014) and finally to Win10 about three years ago. The old Tellicast sw installation just worked and I never touched it. For other reasons, I had to make a completely new fresh installation of Win10. I decided to finally update my old setup and downloaded/replicated the Eumetsat directory at:

ftp://ftp.eumetsat.int/pub/OPS/out/user/EUMETCast_Support/

After a short read of the documentation I downloaded the latest TBS Win10 drivers for my 5925 and Crazycats BDADataEx because I need Diseqc switching, something TVB's IP tool does not provide. I knew that already, but for a newbie it should be mentioned in the Eumetcast documentation.

https://www.tbsdtv.com/download/

After about 15min of downloading, installing and configuring, the system was up and running, receiving my usual data (actually much more because I did not edit the channels configuration :-). I believe that almost everybody could do this in a reasonable amount of time with the docs available and given the fact that the stuff simply works.

Then I got the idea that the Eumetcast reception could be done with my new NAS server system, replacing the old PC and saving some electrical energy and money because the NAS runs 24/7 anyway. I had the same idea a few years ago, but the old NAS server was ARM based and the proprietary Tellicast client is not available. The new system is Intel based, so it seemed perfectly fit for the purpose. I was quite confident that this would work in a short amount of time, given my 35 years of experience working as an engineer in the IT industry and beeing a Unix native... Unfortunately, that was a fallacy. The current state of the software and documentation provided by Eumetsat makes it very unlikely that a normal user will succeed. My biggest mistake was not to search in the archive of this group, because most problems have been addressed already by Christian Peters and Ernst Lobsiger.
My NAS server uses Debian 10, with a backport kernel 5.4. Unlike Ernst/Christian, I like to use systemd, so I'm not a real Unix greybeard...

1) DVB device driver
Even after so many years, the installation of the device drivers for a TBS5925 is still a mess, because they are not part of the slipstream process and have to be compiled by the user and for every new kernel version. That's a real pain for every system not totally dedicated to Eumetcast reception and nothing else. I have used the install scripts at:

https://github.com/tbsdtv/linux_media/wiki

The drivers work, the device gets recognized. Unfortunately the procedure taints the signed kernel and some debian provided modules will no longer work (eg.my USB soundcard).
In the Eumetsat documentation you could eiher use the 2014 or 2016 drivers or the above method depending on which document you read, no consistency at all.

2) EKU software
The crypto dongle, unfortunately still needed, that I use, is the original Aladin dongle ID 0529:0514 Aladdin Knowledge Systems eToken Pro v4.2.5.4. After following the advice in EUMETCast_Support/tellicast-client-pre-release/linux/README_Safenet_EKU_linux.txt, the dongle was not recognized by the system, the lsusb command showed nothing. The troubleshooting guide gives a hint, but has outdated info. On a modern Debian 10 system, the file /lib/udev/rules.d/90-hid-eToken.rules must be changed to include idProduct 514. This can also be found in the archives of this group.
SUBSYSTEM=="block" , ATTRS{idVendor}=="0529", ATTRS{idProduct}=="0514|0602|3002|3004|3005|3006|3007", MODE="0777"
SUBSYSTEM=="usb" , ATTRS{idVendor}=="0529", ATTRS{idProduct}=="0514|0602|3002|3004|3005|3006|3007", MODE="0777"
SUBSYSTEM=="usbmisc" , ATTRS{idVendor}=="0529", ATTRS{idProduct}=="0514|0602|3002|3004|3005|3006|3007", MODE="0777"
SUBSYSTEM=="hid" , ATTRS{idVendor}=="0529", ATTRS{idProduct}=="0514|0602|3002|3004|3005|3006|3007", MODE="0777"
SUBSYSTEM=="hidraw" , ATTRS{idVendor}=="0529", ATTRS{idProduct}=="0514|0602|3002|3004|3005|3006|3007", MODE="0777"
I'm really astonished, given the many old dongles, that they break the compatibility with the old devices and do not mention this in the documentation. A normal user will already fail at this point.
The dongle now showed up with "lsusb" but still did not work with tc-cast-client -k. After many hours of research, I found the problem. The library libcrypto must be present in /lib or /usr/lib. This is an error in the DEB control file of the Safenet Authentication client core library and should not happen. Again, a normal user would most likely fail again at this point. The archives of this group give another solution, but this simple symbolic link is good enough.
ln -s /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 /lib/libcrypto.so

3) Diseqc switching
I have a setup with two dishes and four LNBs, so there is the need to switch to the right LNB. Unfortunately, the documentation again does not really mention it. You can find a hint in the config file /etc/channels.conf in a comment #name:frequency:PolarisationDVBStdModcod:diseqSatNr:Symbolrate:::
szap-s2 can switch, but you have to change the entries to your used number. In my case: E1B:11263:hS1:3:33000:::
Again, this would stop normal users and could be clearly explained in a Linux setup guide.

4) smcrouted
Now my DVB device worked, the EKU worked and I created the necessary network devices with EUMETCast_Support/EUMETCast_Licence_cd/Linux/DVB_devices/Common_Apps/dvb-eumetcast-setup.sh. Unfortunately I still could not receive data... A check with service tellicast-client status showed that smcrouted failed, because another one is already running. So at least on a Debian 10 system, the distribution provided smcrouted service must be disabled.
systemctl disable smcroute
systemctl disable smcroute-helper

5) SUCCESS
After many hours of work, the system finally works...

6) some quirks
the reception is worse compared to the Win10 setup. The count of missed packets is much higher.
I still have missing key errors sometimes in my log file
I need to adapt the metrics and stats scripts for my system

Hopefully this long article will help somebody to setup an Eumetcast system under Linux.

Markus




Ernst Lobsiger
 

Markus

The real problem of GNU/Linux is twofold:

- Linuxers want their "own" distro and their "very special" EUMETCast system
- There is no central EUMETCast knowledge base like Davids site for Windows

The hint for the link you made above is found in my README.amd64.gz in message #28250.

My receivers work rock solid on 11 years old hardware with Intel Duo processors taking
BAS + HVS-1 + HVS-2 with a single cable and doing quite a bit of image processing too.

Missed packets are often related to excessive wait states by slow HDDs. I have written
almost "scientfic papers" about that issue. I'm not sure a NAS is the way to go here.

Systemd poses another problem as the EUMETSAT scripts date from quite a while back
and even if I'm no "greybeard" I do not welcome systemd on my EUMETCast receivers.

Cheers
Ernst

P.S. Your next GNU/Linux receiver setup will be much faster :-) ...




George Sz
 

Markus,

Considering how much time I wasted on Debian before, I'm not likely going back to that distro ever again. At one point I decided to switch to Ubuntu Server and in my experience, it's a lot easier to get work done on that distro. Getting Eumetcast to run, as far as I can recall, takes for me about an hour or two, and that includes OS installation. I also perform OS/kernel updates now and then and so far my system has survived all of these adventures. In my experience, the installation process has become a lot more simple over the years. I remember I had to spend days trying to get my dongle working with that old akstre garbage.

While I agree that compiling the TBS drivers is a pain, doing a few compiles will get you the necessary experience. Regarding DiSEqC, when it comes to professional use, it just adds one more point of failure so in the end I'm not surprised about its omission in the docs.

Perhaps my biggest issue so far was the proprietary client software, namely that nasty udev bug that was eventually addressed. I just wish its disk write issue did not require these RAM disk hacks. Sidenote: I still wonder why this is happening, maybe the client is doing a forced cache flush, then perform a hash check to make sure data has been written to disk properly? I mean, the Linux disk cache system could easily take care of fast write spikes.

As for the hardware I'm running, it's an off-lease 4th gen core i5 Lenovo SFF with 8GB of RAM, with a TBS 6903 inside. The dish I'm using is a 1.8m Prodelin with a Russian feedhorn, with a single cable setup, using a splitter to feed both inputs of the card.

Regards,
George

Ernst Lobsiger
 

George,

Why do you use a splitter? Inside the tuner chip there is a matrix switch. With a single module parameter you can connect your cable directly to one input and feed both adapter chains of the TBS-6903. That's the way I receive BAS/HVS-1 + HVS-2 with a single cable. This works with the TBS-6983/03/08 cards the same way. Or have you tried that before and found the system works better with the splitter in front of the card? Or is this again a case of missing documentation?

Regards,
Ernst

Markus Kempf
 

thanks for the feedback. I believe the core of the problems is the proprietary and closed source Tellicast client and the authentication requirements. That matches well with another monolithic and proprietary system like Windows but not with the fragmented Linux (Unix) world. But nethertheless the Linux install would be unproblematic with a concise and correct documentation or simply the correction of simple errors. Deb and rpm versions cover 90% of the market already.
1) make the TBS drivers consistent with the mainstream linux kernel or create a DKMS procedure to automatically recompile with every new kernel version
2) update the Safenet Authentication client to v10, maybe the erorr in the DEB file was corrected or build a new DEB for v9 or at least document the possible problems in the README or the general documentation
3) create a quick start guide linking the spread out info

In the long run I would hope for Eumetsat making up their mind and adopting an open access policy comparable to the Copernicus/Sentinel program with p2p access to the data (not Eumetcast Terrestrial with Tellicast/EKU and limited to research networks) .
In 2005 I had a 2Mbs connection to the Internet, now I have 1Gbs. The need for the satellite transmission is diminishing at least in the civilized parts of Europe and the british islands.

Markus

Ernst Lobsiger
 

George,

 Here is the module parameter I was talking about. This is copied in part from my message #27249:

<cite>


And here comes the next trick that makes the 6903 driver shine.
If you want a single cable system that takes T1 + T2 it's easy
again. Edit a file /etc/modprobe.d/stv6120.conf with content:

options stv6120 rfsource=1

The meaning that you might want to write into the file as comment:

#  Parameter rfsource is loaded when booting (cannot be changed in /sys/module/...)
#  0  = you can attach two cables LNB0->adaper0 and LNB1->adapter1 (DEFAULT)
#  1  = connect the cable to LNB0 where you can use adapter0 + adapter1
#  2  = connect the cable to LNB1 where you can use adapter0 + adapter1

Of course 1 and 2 is only possible if T1 and T2 is in the same band and polarisation.
But this is the case for EUMETCast transponders T1 and T2.

Cheers,
Ernst

</cite>

Markus Kempf
 

Ernst,

do you have a link or a writeup of your judgement of the TBS drivers? Which one would be best for the 5925?

Markus

Ernst Lobsiger
 

Markus,

That's a long story. TBS is basically a HW manufacturer. The USB box TBS-5925
has the same first generation ST demodulator chip as the TBS-6925 and the SR1.
No way to receive 2 ACM/VCM transponders at the same time as with a TBS-6903.

Years back TBS worked with a driver programmer Konstantin Dimitrov and mostly
produced closed source blobs you had to link in. The driver of the TBS-6925 was an
Open Source exception basically programmed by Manu. Together with Konstantin I was
finally able to get it working for DVBS-2 EUMETCast on a TBS-6925. It seems they
later sacked Konstantin and wanted to go fully Open Source. There was a time TBS
still distributed Konstantins drivers without having the source (!). Some of the
EUMETSAT recommended drivers might still date back to those days and finally
stopped working with newer Linux kernels. The Open Source TBS-6903/08 driver
was loosing interrupts and also had the PCIe-Bridge buffer delay problem with
HVS-2. I was able to fix that with the help of CrazyCat. Ever since CrazyCat
seems to have maintained the Open Source tree of TBS device drivers. So my
recommandation is just to try the latest from the Open Source TBS repo.
But the TBS-5925 driver code has probably not been touched for years now.
If you have a driver problem with latest Linux kernels CrazyCat might fix that.

Here I added a MODCOD filter to this TBS-5925/6925 driver that worked well.
This is useful to stop HVS-1/BAS interaction in rainy weather conditions.
I tried the same with the TBS-6903/08 but have never got it working :-( ...

Cheers,
Ernst

George Sz
 

Ernst,

Thanks for posting the module option again, I did not know of this due to lack of documentation. Googling this option will direct you back to this forum.

Anyway, I removed the splitter and the input levels increased, SNR didn't change however. Btw, is there any way to force the 6903 drivers to return dB instead of percentage?

Regards,
George

Ernst Lobsiger
 

George,

Yes, dB is what I have used from the very beginning. Again from my first patch of the stv090x driver
up to now there has been much change. In Konstantins TBS drivers there was a module parameter
to select % or dB(m). Below is what I have used for 3 years now. As a result of this thread I wanted
to compile the latest OS drivers from TBS. No way with Devuan 2.0 or 2.1 because some modules
asked for a newer kernel. So I just installed Debian 10 amd64 and will double check my stuff again.

Meanwhile play with the bash files attached. They should still work for TBS-6983/08/03 ...

Cheers,
Ernst

Ernst Lobsiger
 

Markus, George and potential GNU/Linuxers

Concerning the first post I can add my experience of installing TelliCast on Debian 10 amd64 (Buster).
My receivers are headless command line systems managed via ssh. Keyboard and monitor is only used
during the base install. I downloaded and burnt on CD the latest 343MB debian-10.3-amd64-netinst.iso.
All the following refers to a fully 64bit receiver system including TC client and latest EKU software.

The base install on an old Fujitsu/Siemens P7935 (Intel Core2 Duo 3.33GHz, 8GB RAM) takes 1/2 hour.

1) Device driver
   TBS-6903 device drivers are the reason I had to change back to Debian with systemd. The latest
   GIT media driver tree from TBS does not compile anymore on Devuan ASCII 2.0 or 2.1 which still
   has kernel 4.9. It's a pity Devuan does not seem to have the manpower to follow other distros.
   I'am still convinced that a systemd free GNU/Linux OS is more suited for a TC receiver only PC.
   But it's probably true: UNIX is dead and Linux goes the way of a modern desktop/mobile OS where
   you constantly plug in or connect to all kinds of things that have to be handled automatically.

2) EKU software
   I had no problem to get my eToken Pro v4.2.5.4 EKU working. I did *not* add any udev eToken rule.
   I faced the problems I reported before: I had to install gtk2.0.0 as the SavenetAuthenticationClient
   has been developped and linked to graphic stuff not found on my Debian 10 CLI only receiver system.
   I had to add the missing link: ln -s /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 /lib/libcrypto.so

3) Diseqc switching
   Something I do not use. But I use my own version of szap-s2 compiled from CrazyCat sources.

4) smcroute
   This is where systemd begins to interfere. The EUMETSAT distributed SysV init scripts originate
   from the old days of DVB-S and do not fit well in a systemd handled GNU/Linux. I also had to:

   systemctl disable smcroute
   systemctl disable smcroute-helper

   There is more: systemd comes with its own ntp client service. This is normally disabled when
   you install a full featured ntpd. But when you sync your clock with TelliCast (as EUMETSAT
   proposes) you better check that your RTC is not pushed back and forth beween TC and systemd.

   I use my own versions of dvb-eumetcast and tellicast-client scripts outside of /etc/init.d

   The EUMETSAT distributed script dvb-eumetcast still relies on old ifconfig which is not there
   unless you apt-get install net-tools. Even then it failed to configure my dummy0, dummy1, dummy2
   multicast interfaces. This is new to me: In older Linux kernels with module dummy loaded you
   could just type "ifconfig dummy0 192.168.1.1 multicast" and you had your new dummy0 configured.
   in Debian 10 with kernel 4.19.0-8-amd64 I had to create my 3 dummies first with utility ip:

   ip link add dummy0 type dummy  
   ip link add dummy1 type dummy
   ip link add dummy2 type dummy

   Then I could configure them with ifconfig. I will rewrite my dvb-eumetcast script to
   only use ip instead of ancient ifconfig and probably drop EUMETSAT a note about that.

   There is more problems with smcroute. This used to be one executable in /usr/sbin.
   The version 2.4.2-4 distributed with Debian 10 is now called with smcrouted and
   smcroutectl (sounds like systemctl :-) and smcroute is actually a "compatibility
   wrapper for users with old startup scripts" in /usr/sbin. It's obvious that this
   can go wrong with the EUMETSAT distributed dvb-eumetcast script. As a new feature
   the daemon flushes "unused dynamic" multicast routes after a default delay of 60s.
   This feature deserves more study. It drops routes for channels that have not been
   active recently. When TelliCast announces data in such a channel it usually fails
   with: "WRN: ... Failed to open data channel ... address ... No data received from
   sender". Starting the daemon smcrouted with "smcroute -d -c 0" did the trick !

5) SUCCESS
   It took me 5 hours too. Next install will be with CloneZilla in 10 minutes.

6) Tune as usual
   I have very little missed packets as usual. As posted several times before I
   recommend to disable C-States in BIOS and to pin busiest interrupts to cores.

Bottom line: Yes, installing a GNU/Linux TC receiver is not for the faint of heart.
But if you are willing to google, read posts and man pages it can easily be done.
A couple of people on this list have done it before in different ways and are willing
to help. Please keep in mind that EUMETSAT pushed routers from the very beginning
of DVB-S2 transmission and that they do not have the manpower to keep up with
all that's going on around PCIe DVB-S2 cards and the many GNU/Linux distros.


Best regards,
Ernst

Markus Kempf
 

Hi Ernst,

has your EKU ProdID 514 like mine? I had to change the udev rule.
I have changed the /etc/init.d/dvb-eutmetcast script on my system yesterday evening, mainly because I noticed that the status did not work right.
1) changed smcroute -d to smcrouted
2) added a smcroute -k before the new start because for unknown reasons the smcroute -k in the stop procedure does not always work reliably
3) changed the grep MTU to grep mtu because the output of ifconfig is now lowercase
4) changed the multicast route inquiry to smcroutectl route
5) changed the mtu size of the dummy interface to 4096 = mtu size of the dvb0 interfaces

I still have lots of missed packets. Will try your C-states tip.
If I can find some time, I will write a real systemd dvb-eumetcast service description.

Markus

Ernst Lobsiger
 

Hi Markus,

lsusb shows
...
Bus 003 Device 002: ID 0529:0514 Aladdin Knowledge Systems eToken Pro v4.2.5.4
...
I have had my own multitransponder capable dvb-eumetcast script long before different
people at EUMETSAT began to touch what Anthony Patchett originally wrote in 2008.

Ernst

Markus Kempf
 

ok, strange, btw. the creation of the dvb0_* and dummy0 devices worked for me. I use the backport 5.4 kernel.

The smcrouted -c 0 option drastically reduced the number of errors/warnings in the log (0 for the last 30min) . Looks much better now!!!

Markus

Markus Kempf
 

I was too optimistic, still the old behaviour, sometimes it works flawlessly for up to 30min and then it starts loosing packets and throwing errors/warnings for a few minutes, gets calm again and the pattern repeats.

Markus

Christian Peters
 

Markus,

as Ernst wrote: did you look at the Bios and the C-States?! It's solves the problems here with my two 5925 USB devices under Linux.

Regards,

Christian

Am 13.02.20 um 17:18 schrieb Markus Kempf:

I was too optimistic, still the old behaviour, sometimes it works flawlessly for up to 30min and then it starts loosing packets and throwing errors/warnings for a few minutes, gets calm again and the pattern repeats.

Markus

Ernst Lobsiger
 

Markus,

After disabling C-States in the BIOS completely (if possible) you
have to know whether this is a driver or a TelliCast problem. You
should have Manu Abrahams famous demodulator driver module stv090x
with CrazyCat's special trick parameter ts_nosync (on) loaded.

You can check for continuity and TEI errors in module dvb_core

# echo 1 > /sys/module/dvb_core/parameters/dvb_demux_tscheck

should report these errors in the kernel log. After some
normal initial errors there should be none. Go back with

# echo 0 > /sys/module/dvb_core/parameters/dvb_demux_tscheck

The second culprit might be your hdd. If this is a NAS you
should not listen music and watch movies from the same hdd.
If possible use a dedicated fast SATA data hdd for TelliCast.
This disk should not fall asleep if TelliCast has some pause.
Tmp directories + channel data must be on the same partition.


Ernst

P.S. I'v never had a NAS and cannot comment on your hardware.

Markus Kempf
 

Hi Ernst, Christian,
had the chance late last evening to reboot and change the BIOS settings (disabled Intel Speedstep, disabled all C-States, btw. the NAS is a standard PC based on an ASROCK J4105 MB, with 8GB RAM, in a special NAS case with 1 SSD and 4 harddisks). Unfortunately same results (1-3% packet loss, missing files, missing keys, etc.)
A bit frustrated I plugged the TBS5925 and EKU back into my desktop PC (running WIN10 v1909) to check the HW again.
After 1000000 received packets I had 13 missed packets, 13 recovered packets and no error/warning messages and no missing files, keys). This works beautifully.
I rebooted my desktop PC (I have a dual boot config) into Ubuntu 19.09 and followed my own and Ernst's advice installing the DVB, EKU and Tellicast sw. This time, the change of the udev rule file was not necessary, the EKU was recognized with lsusb immediately. I used the dvb-eumetsat-setup script and configured everything.
To my agony, the exact same behavior can be observed (1-3% packet loss, missing files, missing keys, etc.)
The problem is not related to the HW used but a Linux SW problem.
What I have tried already:
- changed CPU governor to powersave, ondemand, performance -> no change observed
- raised the priority (renice) of szap-s2 and tc-client -> no change observed
- disabled most other services (NFS, SMB, etc.) -> no change observed
- unplugged all other USB devices -> no change observed
- changed data/tmp directories from SSD to a harddisk -> no change observed

- tried the echo 1 > /sys/module/dvb_core/parameters/dvb_demux_tscheck option
I get many errors in bursts every few seconds!!!
openmediavault kernel: [51564.517475] dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x1f4 expected 0x2 got 0xc
Maybe I will try the v2016 version of the DVB TBS drivers this evening.

Markus

Markus Kempf
 

btw, this is the output of dvb-fe-tools --femon. I have not observed such unstable behaviour looking at the BDADataEx display.

Lock (0x1f) Signal= -41,00dBm C/N= 9,70dB postBER= 0
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 0
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 0
Lock (0x1f) Signal= -41,00dBm C/N= 9,70dB postBER= 0
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 0
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 0
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 0
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 0
Carrier(0x03) Signal= -41,00dBm
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 0
Lock (0x1f) Signal= -41,00dBm C/N= 9,70dB postBER= 0
Lock (0x1f) Signal= -41,00dBm C/N= 9,70dB postBER= 0
Carrier(0x03) Signal= -41,00dBm
Carrier(0x03) Signal= -41,00dBm
Lock (0x1f) Signal= -41,00dBm C/N= 9,70dB postBER= 0
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 163x10^-21
Carrier(0x03) Signal= -41,00dBm
Lock (0x1f) Signal= -41,00dBm C/N= 9,70dB postBER= 0
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 0
Lock (0x1f) Signal= -41,00dBm C/N= 9,70dB postBER= 0
Lock (0x1f) Signal= -41,00dBm C/N= 9,70dB postBER= 0
Lock (0x1f) Signal= -41,00dBm C/N= 9,70dB postBER= 15,6x10^15
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 3,97x10^-3
Lock (0x1f) Signal= -41,00dBm C/N= 9,70dB postBER= 0
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 14,8x10^-3
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 0
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 0
Lock (0x1f) Signal= -41,00dBm C/N= 9,70dB postBER= 4,14x10^-3
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 0
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 0
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 8,98x10^-3
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 150x10^-3
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 48,5x10^15
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 0
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 146x10^-3
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 0
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 0
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 1,00
Lock (0x1f) Signal= -41,00dBm C/N= 9,70dB postBER= 133x10^15
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 325x10^-21
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 0
Lock (0x1f) Signal= -41,00dBm C/N= 9,70dB postBER= 163x10^-21
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 0
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 0
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 0
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 0
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 0
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 0
Carrier(0x03) Signal= -41,00dBm
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 651x10^-21
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 0
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 0
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 0
Carrier(0x03) Signal= -41,00dBm
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 0
Lock (0x1f) Signal= -41,00dBm C/N= 9,70dB postBER= 0
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 0
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 0
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 1,00
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 329x10^15
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 0
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 0
Lock (0x1f) Signal= -41,00dBm C/N= 9,70dB postBER= 0
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 0
Lock (0x1f) Signal= -41,00dBm C/N= 9,70dB postBER= 186x10^15
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 0
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 0
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 0
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 976x10^-21
Carrier(0x03) Signal= -41,00dBm
Carrier(0x03) Signal= -41,00dBm
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 1,00
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 1,08x10^-3
Viterbi(0x07) Signal= -41,00dBm
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 1,00
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 1,00
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 0
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 0
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 0
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 0
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 0
Carrier(0x03) Signal= -41,00dBm
Carrier(0x03) Signal= -41,00dBm
Carrier(0x03) Signal= -41,00dBm
Carrier(0x03) Signal= -41,00dBm
Carrier(0x03) Signal= -41,00dBm
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 0
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 6,28x10^-3
Carrier(0x03) Signal= -41,00dBm
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 1,36x10^-18
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 150x10^-3
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 6,02x10^15
Lock (0x1f) Signal= -41,00dBm C/N= 9,60dB postBER= 0
Lock (0x1f) Signal= -41,00dBm C/N= 9,50dB postBER= 0