11
Sundtek DAB/DAB+/FM/FM HD / Re: Fragen und Weierentwicklung Streaming Server
« Letzter Beitrag von dkadioglu am August 26, 2026, 06:47:09 Vormittag »Habe ich gestern Abend erledigt.
Neueste Beiträge
12
Sundtek DAB/DAB+/FM/FM HD / Re: Fragen und Weierentwicklung Streaming Server
« Letzter Beitrag von Sundtek am August 25, 2026, 06:56:13 Nachmittag »Kannst du deine Senderdatenbank (sundtek.db) an kontakt at sundtek de schicken?
13
Sundtek DAB/DAB+/FM/FM HD / Re: Fragen und Weierentwicklung Streaming Server
« Letzter Beitrag von dkadioglu am August 24, 2026, 07:35:04 Vormittag »Gibr es zu Punkt 1 meines Eingangsposts etwas Neues? Mir ist beim Scan nach Kanälen mal wieder aufgefallen, dass das encoding-Problem noch besteht, d. h. Sendernamen mit Umlauten werden immer noch nicht richtig dargestellt. Vieöen Dank.
14
Treiber / Re: CoreELEC mediasrv unhandled exception after build 20260819
« Letzter Beitrag von Sundtek am August 22, 2026, 09:03:27 Nachmittag »If you want to have an android system go fully android - a half hybrid doesn't make much sense; Enable SYSVIPC again it won't hurt it shouldn't interfere with your idea to load an existing other library.
15
Treiber / Re: CoreELEC mediasrv unhandled exception after build 20260819
« Letzter Beitrag von ultraman am August 22, 2026, 05:00:57 Nachmittag »Enabling CONFIG_SYSVIPC works. But the option will stay disabled. If we see issues later with other CE components we will need to find better solution.
But for now this is it.
I asked claude to make me LD_PRELOAD library. Seems it works.
But for now this is it.
I asked claude to make me LD_PRELOAD library. Seems it works.
Code: [Auswählen]
LD_PRELOAD library that emulates SysV IPC (shm/sem/msg) entirely in
userspace using POSIX shared memory objects + pthread PROCESS_SHARED
mutexes/condvars. Intended for kernels built with CONFIG_SYSVIPC=n,
where shmget()/semget()/msgget() and friends would otherwise fail with
ENOSYS.
16
Treiber / Re: CoreELEC mediasrv unhandled exception after build 20260819
« Letzter Beitrag von Sundtek am August 22, 2026, 04:47:18 Nachmittag »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
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
17
Treiber / Re: CoreELEC mediasrv unhandled exception after build 20260819
« Letzter Beitrag von ultraman am August 22, 2026, 04:28:37 Nachmittag »As I wrote there is a reason for this changes. And we will not go back until really needed by some other components.
18
Treiber / Re: CoreELEC mediasrv unhandled exception after build 20260819
« Letzter Beitrag von Sundtek am August 22, 2026, 04:22:22 Nachmittag »There are many other changes, I highly doubt enabling sysvipc will affect your plan. Doublecheck this with your team, if it really breaks something we can help with enabling the socket route within the driver for your system.
Don’t limit your system for no real reason.
Don’t limit your system for no real reason.
19
Treiber / Re: CoreELEC mediasrv unhandled exception after build 20260819
« Letzter Beitrag von ultraman am August 22, 2026, 01:28:49 Nachmittag »Sadly enabling CONFIG_SYSVIPC is not an option. As I wrote we aligned linux config to android one because we use one kernel module from Android (dovi.ko for DV playback) and seems it helps with stability. We didn't saw any other issues in last few days after this change. If anything else pop ups then we could (and should) reconsider but for now it will stay disabled.
This means tuner will just not work anymore with this option disabled?
This means tuner will just not work anymore with this option disabled?
20
Treiber / Re: CoreELEC mediasrv unhandled exception after build 20260819
« Letzter Beitrag von Sundtek am August 22, 2026, 12:17:10 Nachmittag »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.
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.