Here I have to change the driver stv090x.c in ./media as described. The point probably is
that this only works if the the patched driver copy is newer than the replaced one. This
is because make relies on time stamps. So if you downloaded the media tree from TBS again
your files could have been newer than my patched copy. Just checked this here again:
My downloaded TBS tree dates from Feb 12 10:47
This tree has been compiled and installed before (including my patches too)
I make sure in ./media_build I have again the stv090x.c from Feb 12 10:47
My patched stv090x.c driver copied to ./media dates from Feb 14 19:26
I go to ./media_build and do a make that compiles just one module stv090x.o
Now in my ./media_build I have a patched todays copy of stv090x.c Feb 16 13:45
Every thing works as discribed in the README_FIRST.txt if the patched driver is newer
than the files in the TBS tree. I guess you downloaded the GIT tree again and it was
newer than my patched driver? You can open the patched source with mc and save it again
to get the newest file on the planet. Maybe I should explain that in my README_FIRST.txt.
Nice to hear your GNU/Linux receiver is now up and running fine. I have a problem here
with my Debian 10 and latest 64bit tellicast client. Some 10 minutes after I start tellicast
there is a very small but slowly increasing use of swap space. Is there a memory leak?
How does your NAS with a far newer kernel handle that? What does top (memory) show?
P.S. SatPy/Pytroll is powerful and extreme fun. But this is not an overnight thing either ...