neumoDVB

[satesco]

@deeptho,

The joy lasted only a moment with the last kernel installed(from @Llew), because although the settings in neumodvb remained the same, the cards were no longer connected.I tried another kernel version, but every time I install with the command "make allyesconfig", the resolution changes.In other words, if I have a normal resolution, devices not connected, and conversely, when your drivers are installed, the resolution is changed.
Of course it is annoying and time consuming to deal with each case individually,but please tell me how to install your drivers with your ./sh command from #214.So far I have not succeeded.
Of course I can install the drivers with the command from tbs,but then I can't use your blindscan,and so there's no point and charm in insisting.But I want to see how the cards behave in different environments,Windows and Linux.What's new in your version,say,with the 6903x card on Linux vs Windows.Can Linux better highlight the enormous hardware capabilities of stid135 that Windows cannot?The step you have now taken is just the beginning of a revitalization of this card(?) And I say it's worth a try.
Thanks

 

[Satspot]

@satesco surely you can build this project on Fedora 35 if, as you state you’re not particularly versed in the Linux environment and you wanted this as an evaluation/comparison to the Windows environment. For the time and energy you have expended so far you would already be up and running now by simply creating a small partition on your hard drive and booting at will between Ubuntu and Fedora via the Grub 2 menu.

Is there a particular reason you need to be running Ubuntu on your setup or is it just the first distro you stumbled upon. Personally I’d go with the OS that the project was developed in to get it up and running, evaluate it and if it’s up to expectation then pursue the Ubuntu route. Failing that maybe @deeptho would be agreeable to build his project in Ubuntu and use that at your starting point. Either way it’s got to be better than spending hours back and forward when there’s a ready made solution in place. Your frustrated attempts are clearly evident at this stage.

Linux distros are famous for falling over once you get into the manual build scenario. You don’t have the option of automatically removing packages and dependencies so you end up with artefacts of previous attempts all over your file system that eventually come back to bite you.

 

[Llew]

surely you can build this project on Fedora 35 if, as you state you’re not particularly versed in the Linux environment and you wanted this as an evaluation/comparison to the Windows environment. For the time and energy you have expended so far you would already be up and running now by simply creating a small partition on your hard drive and booting at will between Ubuntu and Fedora via the Grub 2 menu.

That's pretty much how I started with the project, after getting neumo-blindscan working. I used Fedora FR34 with kernel 5.13.16.200 on a USB stick.

I was just curious to get it running on a Ubuntu OS, as I was more used to that, but it meant having to chase up some of the different library naming conventions between Fedora and Ubuntu. Of course it does mean @satesco has to set all his dependencies up for the Fedora OS

 

[satesco]

You should know that I thought of installing Fedora for the reasons you mentioned. But I learned Linux on Ubuntu 16, then 18 and now I'm up to 20.04. But I use Ubuntu also because I do tests with other DVB cards with different applications.
I also thought about @deeptho for what it does for us, the enthusiasts, and I can imagine that it doesn't have much time for each of us who has problems with his application or driver.
And there is something else that is not related to the installation, but to the question that some users, including me, ask themselves regarding the use of cards in both Windows and Linux. Windows has the great advantage that there are various DVB applications that help you to select according to taste and use. On Linux, however, with the potential it has, it still doesn't offer us too many options. The results are mixed and so far inconclusive in terms of performance. For instance, I'm glad that @deeptho seems to have been stimulated by the 6903x card and thought of creating an application capable of highlighting its potential. I have read the stid135 chip specification and I am amazed that tbs can't exploit to the full capacity that this chip has, and that is because the SMTicro manufacturer doesn't allow access to the source.
But that's another story.
In fact, the only problem I have on Ubuntu 20.04, and not only me, is the resolution change. Deeptho presented us where the problem comes from, but I think he could solve this problem too, especially since TBS offers several variants of installing drivers on Linux, without Deeptho's of course.

 

[Llew]

Until the superb deeptho projects, I was using the updateDVB spectrum and blindscanner, and before that Kaffiene. Unfortunately updateDVB can't use the TBS6903X, but it does do DVB-T and the LOF configuration allows inputting KA frequencies.

 

[Satspot]

That's pretty much how I started with the project, after getting neumo-blindscan working. I used Fedora FR34 with kernel 5.13.16.200 on a USB stick.

I was just curious to get it running on a Ubuntu OS, as I was more used to that, but it meant having to chase up some of the different library naming conventions between Fedora and Ubuntu. Of course it does mean @satesco has to set all his dependencies up for the Fedora OS

Absolutely but when you stray outside the particular flavour of Linux that the developer built and tested on you really do need to know your stuff as far as Linux is concerned. Once you start working outside the distro’s package manager building/compiling you run the risk of breaking your install and need to know where to go looking to repair the problem which is not an easy task. I’m not aiming this comment at you but for anyone else who may fancy following the Ubuntu route without the requisite skill sets. It’s known to work in the Fedora so that’s the route I would take.

 

[Satspot]

Until the superb deeptho projects, I was using the updateDVB spectrum and blindscanner, and before that Kaffiene. Unfortunately updateDVB can't use the TBS6903X, but it does do DVB-T and the LOF configuration allows inputting KA frequencies.

Yes it’s a wonderful project developed by @deeptho Not too many people these days developing projects in such depth for the DVBS world and certainly not aimed at the open source community. I really would follow his lead as far as Fedora is concerned. Again that last comment is clearly not aimed at you.

 

[satesco]

Absolutely but when you stray outside the particular flavour of Linux that the developer built and tested on you really do need to know your stuff as far as Linux is concerned. Once you start working outside the distro’s package manager building/compiling you run the risk of breaking your install and need to know where to go looking to repair the problem which is not an easy task. I’m not aiming this comment at you but for anyone else who may fancy following the Ubuntu route without the requisite skill sets. It’s known to work in the Fedora so that’s the route I would take.

What intrigues me is that my driver problem is not related to Deeptho drivers, but to TBS drivers on Ubuntu 20.04. On Ubuntu 16.04 or 18.04 I didn't have problems with tbs drivers, but only on 20.04! When I first installed the tbs drivers on this OS, the same thing happened exactly as with Deeptho. After I notified the TBS team of this situation, they found the solution with ./sh, and since then no matter how many versions of kernels appear, the installation of the tbs drivers is done correctly, without any consequences.
So it's not the drivers that are to blame, but the way they are installed.
On the other hand, I installed Neumodvb even on Ubuntu 20.04 and it worked without a problem but of course with a changed resolution. That's why the solution has to be found, not the drivers!
As a consequence of the fact that Neumodvb works on Ubuntu 20.04, then I say that even on Ubuntu you can work with Deeptho's application. I would say that it would be a kind of test that Neumodvb is valid on any distro. Moreover, Deeptho himself thinks it is possible that his application can work on Ubuntu too. If he had more time, he could prove that the application is supported by ubuntu. But he preferred Fedora, it seems to suit him better.
If he doesn't have time to try his app on Ubuntu, then I could even be a tester, just like Llew was on Fedora. And it would benefit those who want his app on Ubuntu. I'm sure he would agree to such a test.

 

[Satspot]

You should know that I thought of installing Fedora for the reasons you mentioned. But I learned Linux on Ubuntu 16, then 18 and now I'm up to 20.04. But I use Ubuntu also because I do tests with other DVB cards with different applications.
I also thought about @deeptho for what it does for us, the enthusiasts, and I can imagine that it doesn't have much time for each of us who has problems with his application or driver.
And there is something else that is not related to the installation, but to the question that some users, including me, ask themselves regarding the use of cards in both Windows and Linux. Windows has the great advantage that there are various DVB applications that help you to select according to taste and use. On Linux, however, with the potential it has, it still doesn't offer us too many options. The results are mixed and so far inconclusive in terms of performance. For instance, I'm glad that @deeptho seems to have been stimulated by the 6903x card and thought of creating an application capable of highlighting its potential. I have read the stid135 chip specification and I am amazed that tbs can't exploit to the full capacity that this chip has, and that is because the SMTicro manufacturer doesn't allow access to the source.
But that's another story.
In fact, the only problem I have on Ubuntu 20.04, and not only me, is the resolution change. Deeptho presented us where the problem comes from, but I think he could solve this problem too, especially since TBS offers several variants of installing drivers on Linux, without Deeptho's of course.

It might be worth noting there’s not a great love between Linux and TBS and in particular Ubuntu with the result it’s a lot more difficult to develop any application without the full picture. Most of the developers are working blind in many cases and are reverse engineering to find solutions. You only have to look at nVidia for an example of that. A quick read of this link might give you an idea if you don’t already know this TBS drivers will no longer build under Ubuntu 16.04, could someone please explain why?

Many ask the question why don’t hardware manufacturers work closer with the Linux community to get their hardware working under Linux. They’d shift more units as a result Of course the bad words here are Open Source so that’s unlikely anytime soon. Bearing this in mind if a Linux developer manages to get his application up and running in a particular flavour of Linux that’s the one I’d go with unless I knew my way around Linux particularly well.

I too have tested many DVBS/T cards under numerous flavours of Linux over the years. I’m still nursing an old Hauppauge Nova S2 Card on a Core 2 Duo on the latest version with more backports than you could shake a stick at just to keep it alive.

I really do suggest you create a new partition for Fedora on your drive and do all your testing/evaluation of neumoDVB there before you end up aging prematurely.

 

[Satspot]

What intrigues me is that my driver problem is not related to Deeptho drivers, but to TBS drivers on Ubuntu 20.04. On Ubuntu 16.04 or 18.04 I didn't have problems with tbs drivers, but only on 20.04! When I first installed the tbs drivers on this OS, the same thing happened exactly as with Deeptho. After I notified the TBS team of this situation, they found the solution with ./sh, and since then no matter how many versions of kernels appear, the installation of the tbs drivers is done correctly, without any consequences.
So it's not the drivers that are to blame, but the way they are installed.
On the other hand, I installed Neumodvb even on Ubuntu 20.04 and it worked without a problem but of course with a changed resolution. That's why the solution has to be found, not the drivers!
As a consequence of the fact that Neumodvb works on Ubuntu 20.04, then I say that even on Ubuntu you can work with Deeptho's application. I would say that it would be a kind of test that Neumodvb is valid on any distro. Moreover, Deeptho himself thinks it is possible that his application can work on Ubuntu too. If he had more time, he could prove that the application is supported by ubuntu. But he preferred Fedora, it seems to suit him better.
If he doesn't have time to try his app on Ubuntu, then I could even be a tester, just like Llew was on Fedora. And it would benefit those who want his app on Ubuntu. I'm sure he would agree to such a test.

And the magic words are “if he has the time”. If he does be prepared for much testing, many failures and many hours of frustration. If that’s what you’re prepared for and a willing developer with the time I reckon you have a deal.

 

[satesco]

Of course, we cannot ask Deeptho to work on his project on more than one distro. But the fact that I managed to see that Neumodvb works on Ubuntu 20.04, means that it is possible that his project is valid on Ubuntu. I just ask him to try to solve the problem with installing drivers after the tbs model, with ./sh.
Here is how his application looks installed on Ubuntu 20.04. So it can...

 

[Satspot]

Of course, we cannot ask Deeptho to work on his project on more than one distro. But the fact that I managed to see that Neumodvb works on Ubuntu 20.04, means that it is possible that his project is valid on Ubuntu. I just ask him to try to solve the problem with installing drivers after the tbs model, with ./sh.
Here is how his application looks installed on Ubuntu 20.04. So it can...

Indeed as you would expect as he states in his GitHub........

In principle it should work with any version, but once in a while changes in the generic linux kernel
causes incompatibilities with linux_media, which then fails to compile. Usually the problems are in other unrelated
drivers (which is what you experience).

That’s something to bear in mind too. One simple one point upgrade on the kernel can break your install. If you do manage to get it working under Ubuntu with his help it may well be worthwhile pinning that Linux kernel version.

 

[satesco]

Our dialogue so far proves you are speaking knowledgeably about Linux. That's why I take heed of what you say. But I think for now it is premature to talk about what changes occur with updates or upgrades to Ubuntu. It's good that you warn me about possible problems that occur with upgrades, but for now, the problem is not related to the future, but to a strictly punctual one, how to install Deeptho's drivers without changes in resolution? This is the only question I ask our forum colleague? I was able to demonstrate that before that his application works. I think Deeptho would be pleased to see that his application works in Ubuntu 20.04 with all the problems I had with his installation. As they say, wait and see.

 

[deeptho]

Satesco, and everyone,
there are many messages today and I will not try to attempt to address all the issues raised, but here is a summary
The drivers on your computer come from two places
1. the linux kernel as installed in your os.
2. the tbs drivers which are integrated into media_build to allow them to build separately from the kernel.
They are maintained by tbs and crazycat and I can tell you that is not an easy job.

media_build makes changes to the kernel source to fix all kinds of problems.
... and introduces new ones.

The summary is that it builds many kernel modules, including the ones that you don't need/want changed and
then depending on how you install it, also installs a new version of other unrelated drivers. It seems one of those is
based on slightly different code than the one in the ubuntu kernel. For example, perhaps ubuntu has fixed some bug in
a display driver, but that fix is not yet in the code that is compiled by media_build. After installation, you know have accidentally installed a "bad" driver.

So the trick is to not overrwite the bad driver. This means
1. compiling drivers for exactly the same kernel version as installed by ununtu. Otherwise, the "good" driver is
not even present (for the correct version) from the start
2. finding out which driver is the one that should not be overritten
3. Either making sure that the installation scripts do not overwrite that driver (this might be the tbs proposed solution, Not sure) or keeping a copy of the correct driver and afterwards restoring it.

So: if someone knows what driver is being overwritten, then simply copy that driver file somwhere before installing and then
later copy it over the "bad" version that is accidentally installed.

This solution may not always be possible. Some drivers depend on each other and need to be replaced together (all of them
or none of them). This is probably why media_build overwrites everything, Usually this works.

Satesco is unlucky because probably his display driver has a bug which is fixed only by unbuntu but not in some
official kernel, or because the fix is in the official kernel but not yet in media_build or because the fix is in the
generic media_build but not yet in the tbs version of media_build or perhaps because he is (needs to) compile an
older version of the kernel.

Needless to say: this is not a good way of working, with at least three different possible versions for each driver:
1) ubuntu 2) generic media/media_build and 3) tbs /media/media_build and all of them potentially having small differences.
On top of that there are also differences between kernels.

Normally none of that matters, except now that there is some unrelated bug fixed in some unrelated drivers.
So this problem has nothing todo with tbs, with blindscan drivers or with and it will eventually disappear when all
versions are synchronised.


A simple solution is to ask Llew to make a copy of his ubuntu kernel and drivers, install them on Satesco's computer
and boot from that.
The copy needs to include:
-any file in /boot related to the correctlly running kernel version.
ls /boot/*`uname -r`* /lib/modules/*`uname -r`*

such files can be copied with tar. After installation, you also need to update grub.cfg. There must be a ubuntu-specific
procedure for that.

Note that the linux drivers (blindscan) are better than the windows drivers for tbs6909x and tbs6903x.

And if it is any consolation: with my cards, many of the windows programs do not work at all or with some serious limitations.
E.g.., ebspro: rf-scan not supported, iqmonitor (never any useful result), crayzscan (some versions work on some cards).
I have even seen blue screens of death. So you need some luck.


And of someone has info on what the problem exactly is, I can have a look at that driver (but explanations like
"tbs suggests to use ./install.sh to install are not informative enough in that respect.) and could add it to
the kernel source.

In the longer term I plan to go for a new install system. That might be easier (or not).

PS. I don't have ubuntu and cannot test. It also depends on your computer hardware.

 

[satesco]

Thank you so much, Deeptho, for the explanation. I want to solve myself problem you explained, but I will need help this time. It's a job for a Linux specialist and not a layman.
About 6903x on Windows, I made a presentation on a Romanian forum. When I have time, I'll translate it. Maybe, who knows, it will help.

 

[g host]

I have read the stid135 chip specification and I am amazed that tbs can't exploit to the full capacity that this chip has, and that is because the SMTicro manufacturer doesn't allow access to the source.

hi Satesco.

Here is how the work is done.
STM sell SDK for over 1k (NDA attached) along with hardware prototype fully functional. TBS aquire SW and HW for its programmers.
Unofficial, a prototype dvb card with drivers and source code pass to Cat wich will make the rest for us.
Now, SDK is buggy and STM guys could not complete task to resolve just in time. So, the problem is passed to OEM and, this alog with problems from Ukraine war, make users unhappy.
Even, other users are complaining about quality of STM sources in some forums.

P.S.
Sorry for offtopic.

 

[Satspot]

Possibly slightly off topic but definitely worth a read. I was particularly interested when the user unplugged the unit, left it for a while and his problem was miraculously solved. Need Help on TBS5922se Linux Driver Install

 

[deeptho]

hi Satesco.

Here is how the work is done.
STM sell SDK for over 1k (NDA attached) along with hardware prototype fully functional. TBS aquire SW and HW for its programmers.
Unofficial, a prototype dvb card with drivers and source code pass to Cat wich will make the rest for us.
Now, SDK is buggy and STM guys could not complete task to resolve just in time. So, the problem is passed to OEM and, this alog with problems from Ukraine war, make users unhappy.
Even, other users are complaining about quality of STM sources in some forums.

P.S.
Sorry for offtopic.

And the software is very much away fro the quality needed to be included in the linux kernel, and becuase of the large size of the code, it would take a lot of effort to clean it all.

At least under linux we have the source...

and where is the fun if it all "just worked"?

 

[Satspot]

And the software is very much away fro the quality needed to be included in the linux kernel, and becuase of the large size of the code, it would take a lot of effort to clean it all.

At least under linux we have the source...

and where is the fun if it all "just worked"?

I think you’ll find that anyone coming from a Windows environment want exactly that. An install script or a list of copy/paste commands and “everything just works”.

 

[deeptho]

Satesco,
I rarely have the "it just works" experience under windows. More common is "it does not work, and there is no way
to fix it". Spending time on needless calls with microsoft support to fix five year old bugs only to hear them (!) complain about the microsoft teams software is as bad as it gets. And - as a heavy user - I have seen much useful functionality disappear
in microsoft office over the years, to the point that it has become largely useless.

Under linux also sometimes things don't work, but at least usually there is a way to fix the problems and some people to help (instead of the usual "try reinstalling" type of advice).

Why us windows when doors are easier. :->