Sundtek Support Forum

Hallo,

starte mal folgende Befehle:

/opt/bin/mediaclient --testastra -d /dev/dvb/adapter0/frontend0
/opt/bin/mediaclient --readsignal=50 -d /dev/dvb/adapter0/frontend0

Du kannst den Treiber auch manuell laden, auch prüfen ob das Netzteil funktioniert (sofern möglich) 12V

sudo -s
cd /opt/bin
killall mediasrv
./mediasrv -v

danach mit der gewohnten Applikation einen Sender einstellen und schauen ob sich auf der Konsole etwas tut.

Auch um sicherzugehen dass die Anlage in Ordnung ist bitte irgendwie gegentesten z.B mit einem Receiver am gleichen Anschluss (also am gleichen Kabel)

Hi,

Du kannst gerne in den Discord Chat schauen, um das Problem welches Du da hast zu besprechen.

https://discord.gg/AR5QJhyNnw

Könnte ein Problem mit dem Docker System und musl-c die ist etwas anders als der reguläre Treiber, aber Du hast jetzt erst mal eine Debug Version am Laufen mal schauen was da dann rauskommt.

Hallo,

Hast Du beide Adapter getestet?

was zeigt denn folgender Befehl an, wenn der Betroffene Sender auf Adapter0 empfangen wird?
/opt/bin/mediaclient --readsignal=0 --band=universal -d /dev/dvb/adapter0/frontend0

(eventuell auch adapter1 testen)

Kannst du deine Senderdatenbank (sundtek.db) an kontakt at sundtek de schicken?

As mentioned first enable the feature again, I saw there were many changes not only sysvipc, sysvipc is very likely unrelated to what you really need or want. This won’t affect only us but also other software packages in a negative way. Android comes with its own software environment and they implemented another IPC mechanism.

By the way dream box also tried to disable sysvipc but they went back quickly years ago since they saw multiple drawbacks. Don’t force the removal of a standard unless it’s really officially deprecated and you really have to.

Please test re enabling it and loading the particular module which you are looking for

Hi,

I do not recommend disabling `CONFIG_SYSVIPC`. Many Linux applications depend on System V IPC, and by disabling it you are stripping away a significant part of the standard Linux IPC functionality. Even embedded Linux set-top boxes commonly have `SYSVIPC` enabled. I would not remove it without a very good reason.

`CONFIG_SYSVIPC` provides System V shared memory, semaphores, and message queues. These interfaces have been part of Unix/Linux for decades and are still actively used. Shared memory in particular allows processes to exchange data efficiently without repeatedly copying large amounts of data between separate process buffers, which can save CPU time.

We also have an Android build of our driver that can operate without SYSVIPC, but Android uses different mechanisms for inter-process communication and shared memory. Alternatively, we can even use Unix domain sockets instead of SYSVIPC where necessary.

However, the fact that Android can work without System V IPC is not a good reason to remove it from a normal Linux build.

I see virtually no practical benefit in disabling `CONFIG_SYSVIPC`, while doing so unnecessarily reduces compatibility with existing Linux software.

If I would see the advantage of the removal I would have no problem with doing so - but limiting the system in that area doesn't look like a benefit to me.