Ja, gibt es beide nachdem ich den Service manuell enabled hatte (oder gab's den schon?)
Den muss es schon gegeben haben. In /usr/lib ist schreibgeschützt. Die Frage ist jetzt, warum der Service nicht automatisch gestartet wurde - wie es geplant war.
Auch eine interessante Frage wäre in dem Zusammenhang auch, warum der Wechsel von VDR <-> Kodi auch so klappt.
Der neue Dienst ist noch nicht aktiviert. Mach mal systemctl enable VDRCoreELEC und schau, was dann journalctl dazu sagt.
Der sollte eigentlich automatisch enabled sein. Um das zu erreichen musste ich die Unit nach /usr/lib/systemd/system damit die Links direkt auch im Image angelegt werden.
Kannst du mal schauen ob es die Datei /usr/lib/systemd/system/VDRCoreELEC.service und den Link /usr/lib/systemd/system/multi-user.target.wants/VDRCoreELEC.service -> ../VDRCoreELEC.service gibt?
Das ist schon irgendwie seltsam:
odroid1:~ # systemctl enable VDRCoreELEC
Created symlink '/storage/.config/system.d/multi-user.target.wants/VDRCoreELEC.service' → '/usr/lib/systemd/system/VDRCoreELEC.service'.Hier wird der Link in /storage angelegt. Klar. /usr/lib ist schreibgeschützt, aber warum ist das überhaupt notwendig? Der Link /usr/lib/systemd/system/multi-user.target.wants/VDRCoreELEC.serviceexistiert doch schon?
ClearOSD.sh wird teilweise als /usr/local/bin/ClearOSD.sh aufgerufen, an anderen Stellen aber als .config/vdropt/ClearOSD.sh wo es nicht existierte
Oh. Habe ich da etwas übersehen? Ja, habe ich 
So, hier die avisierte Lösung, um direkt in vdr booten zu können, ohne dass zuvor Kodi gestoppt werden muss. Das sollte das gelegentlich auftretende gleichzeitige Starten von vdr und Kodi nun eigentlich zuverlässig verhindern.
Sooo. Ich habe deine Änderungen alle eingebaut und bei 2 CE22 Systemen funktioniert das Update. Der Wechsel Kodi <-> VDR klappt dabei auch. Dabei habe ich auch versucht, Bestandssysteme irgendwie zu bereinigen.
Da ich dein Problem allerdings nicht nachvollziehen kann, habe ich erstmal versucht sicherzustellen daß nix kaputt gegangen ist.
Es wäre wirklich gut, wenn Selbstbauer ein Update machen könnten um evt. Fehler noch finden.
Kannst Du https://github.com/j1rie/vdr-plugin-usbkbd in VDR*Elec aufnehmen?
Erledigt.
Der Commit wurde gemerged, aber das Paket ist weiterhin vorhanden. Ich denke, es müsste vorerst reichen, wenn man das irgendeinem (virtual) package als Abhängigkeit mitgibt.
Das wird erst dann eine Rolle spielen, wenn ich wieder ein Update von CE/LE mache. Aber zur Sicherheit habe ich das Paket nach packages/tools kopiert. Es wird noch nicht gebaut, aber die Vorbereitung ist da.
So, hier die avisierte Lösung, um direkt in vdr booten zu können, ohne dass zuvor Kodi gestoppt werden muss. Das sollte das gelegentlich auftretende gleichzeitige Starten von vdr und Kodi nun eigentlich zuverlässig verhindern.
Ich werde das einbauen, wenn es etwas kühler ist. Aktuell ist es viel zu heiß (> 31 Grad im Raum) für konzentriertes arbeiten.
Hast du vielleicht sogar einen Patch, der alles schon beinhaltet? Das würde die Sache erheblich beschleunigen?
Das locale-addon ist in Kodi installiert und auf de_DE.UTF-8 konfiguriert. Sowohl Kodi als auch vdr haben deutsches Menü.
Wie rufst du das Script auf? Von der Console oder per systemd? Die env Variable
LOCPATH=/storage/.kodi/addons/service.locale/locpathsollte in beiden Fällen gesetzt sein, damit die Locales auch gefunden werden. Ich vermute, daß man vielleicht im Script das noch setzen muss, wenn es nicht automatisch verfügbar ist.
Der Ordner /usr/local/system.d dient hier nur als Ablageort und wird - anders als /usr/lib/systemd - von systemd nicht beachtet?
Genau. Ich fand es sinnvoll, die systemd units editierbar zu halten und dazu müssen sie eben nach /storage/* kopiert werden.
Wird switch_kodi_vdr.service von systemd automatisch gestartet, oder nur durch das in der in der /usr/local/bin/autostart.sh ...
Der Service wird nicht automatisch gestartet. Ganz im Gegenteil, im install.sh wird die Unit explizit disabled. In der autostart.sh wird dann systemctl start switch_kodi_vdr.path gestartet, das dann übernimmt.
neue Idee: Kann es ein Problem sein, wenn die Box neu gebootet wird, während Kodi noch läuft? (z.B. bei Stromausfall oder Hard-Reset). Dann steht in /storage/.cache/switch_kodi_vdr immer noch kodi. Der Autostart liest aber aus der .profile vdr.
Okay. An so ein Problem hatte ich nicht gedacht.
Macht vielleicht diese Ergänzung in der /usr/local/bin/autostart.sh Sinn?
Kannst du das testen? Du müsstest nur die /usr/local/bin/autostart.sh irgendwohin nach storage kopieren und in der /storage/.config/autostart.sh den Pfad auf das geänderte Script ändern.
Ansonsten sehe ich kein Problem, das direkt einzubauen, weil dies ja eigentlich auch so sein sollte.
Also wird der Autostart noch vor kodi.service ausgeführt. Wenn Kodi dann noch nicht gestartet ist, geht der Befehl systemctl stop kodi ins Leere, weil es noch nichts zu stoppen gibt.
Hmmm. Der Autostart ist noch vor Kodi? Dann ist das Zufall, daß ich die Probleme nicht habe?
Wie kann man dann aber den Start von Kodi verhindern, wenn nur VDR gestartet werden soll?
Es gibt wohl den Parameter "Conflict=", der dann aber den anderen Service abschiesst, wenn der neue gestartet werden soll. Damit würde dann aber auch der Wechsel von VDR nach Kodi ohne den Stop des VDRs nicht mehr funktionieren.
Oder würde es reichen, vor dem Kodi Stop noch ein wenig zu warten? Oder die Kodi unit muss leicht umgeschrieben werden, wenn der Autostart auf VDR steht.
Vielleicht kann man auch mit ConditionEnvironmentetwas zaubern und den Kodi Start verhindern, wenn der Start auf VDR steht?
Wenn ich das wenigstens nachstellen könnte, aber so wäre alles ein Schuß ins Blaue.
ich habe es nun sowohl unter 21-ng als auch 22-no mehrfach gehabt, dass nach dem Booten nicht nur vdr lief (wie gewollt, da START_PRG=vdr in der ~/.profile), sondern auch noch Kodi.
Ich habe selbst 2 Instanzen von CE22-no laufen und das Problem noch nie gehabt.
Die systemd unit switch_kodi_vdr.path prüft, ob die Datei /storage/.cache/switch_kodi_vdr geändert wurde und startet dann die unit switch_kodi_vdr.service. Und diese Unit startet das Script /usr/local/bin/switch_kodi_vdr.sh.
Das Script liest dann erst /storage/.profile und dann /storage/.cache/switch_kodi_vdr. Und je nachdem, welchen Wert die ENV Variable START_PRG am Ende hat (START_PRG='vdr' oder START_PRG='kodi') wird entweder VDR oder Kodi gestartet.
Bei sieht es z.B. (nach dem Reboot und ohne Wechsel nach Kodi) so aus:
/storage/.profile: START_PRG=vdr
/storage/.cache/.switch_kodi_vdr ist leer
Und damit wird nur VDR gestartet. Beim Start von VDR wird als erstes Kodi gestoppt systemctl stop kodi.
Wenn bei dir beides läuft und der VDR gestartet werden soll, dann kann ich mir nur vorstellen, daß der Stop von Kodi nicht funktioniert. Aber warum sollte das so sein?
Beim booten passiert folgendes:
Das System selbst findet eine /storage/.config/autostart.shund ruft das Script auf. Das Script selbst ruft unter anderem auch /usr/local/bin/autostart.sh auf. Und darin findet sich dann
# Start either Kodi or VDR on reboot
. /storage/.profile
if [ "${START_PRG}" = "vdr" ]; then
systemctl stop kodi
if [ "Amlogic-ce" = "Amlogic-ce" ]; then
echo 4 > /sys/module/amvdec_h264/parameters/dec_control
fi
systemctl start vdropt
fiDas /storage/.profile wird noch gelesen um die Variable START_PRG zu bestimmen. Und falls der Wert vdr ist, dann wird Kodi gestoppt und vdr gestartet. Der Default ist ein Start von Kodi.
Eine versteckte Datei .watch_prg habe ich in /storage/.cache noch nie gesehen.
Das muss eine Altlast eines Dokumentationsfehlers sein. Die Datei, auf die gelauscht wird ist /storage/.cache/switch_kodi_vdr.
Als Basis müsste LibreELEC-Generic.x86_64 dafür taugen, da kein x11 läuft.
Das Plugin habe ich integriert. Allerdings compiliert das nur für LibreELEC-13 Generic. Die Abhängigkeit von FFmpeg (>= 7) verhindert eine Installation für LibreELEC-12.
Hat jemand für mich ein funktionierenden Eintrag für die channels.conf?
Ich will noch ergänzen, daß es auch das Repository gibt, das auch cfg und channels.conf Einträge, die von Kodinerds konvertiert wurden. Damit kann man zumindest schnell mal schauen, ob ein Kanal überhaupt (noch) funktioniert und dann evt. eines der anderen Protokolle einsetzen.
Es gibt auch bei Codeberg Runner. Aber halt nicht so üppig dimensioniert wie bei GitHub und kein ARM. Bei Codeberg hat man die Wahl zwischen Woodpecker CI und Forgejo Actions.
Ja genau das ist aber das was ich meinte. Self-Hosted Runner funktionieren bei "kleineren" und/oder laufzeitbegrenzten Actions.
Und dafür sind sie extrem nützlich. Ich habe noch nicht geschaut, wie die Actions aufgebaut sind. Github Workflows sind auf jeden Fall z.T. stark gewöhnungsbedürftig und kosten viel Zeit die zum Rennen zu bringen.
Forgejo, the software Codeberg is built on, offers a CI/CD feature called Actions. Forgejo Actions can be used with self-hosted runners and Codeberg also provides a hosted version in a limited fashion in open alpha.Ich denke ein Projekt "VDR*ELEC" kann ich nur auf self-hosted Runner nicht in dem Umfang bauen lassen. Alleine wenn ich mir die Laufzeiten der Workflows anschaue und wieviele Workflows rennen, bräuchte ich eine größere Rechnerfarm. Ich darf gar nicht daran denken, was passiert, wenn Github mir den Saft abdreht. Aber spätestens dann steht ein Umzug an.
Ich finde das Konzept von Codeberg sehr vielversprechend und sympathisch. Wenn ich so darüber nachdenke, wäre es vielleicht auch eine Lösung nach Codeberg umzuziehen und Github für größere Projekte als Backup zu nutzen. Darüber muss ich mal nachdenken.
Ich habe jetzt _python-evdev unter CE21 kompiliert und tatsächlich ist die Installation unvollständig, allerdings bricht der Build aber auch nicht ab. Ich kann mit der Fehlermeldung nicht viel anfangen. Hast du eine Idee?
/home/rh/projekte/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-ng.arm-21/toolchain/bin/armv8a-libreelec-linux-gnueabihf-gcc -shared -Wl,--as-needed -fuse-ld=gold -march=armv8-a+crc -mtune=cortex-a53 -mabi=aapcs-linux -Wno-psabi -Wa,-mno-warn-deprecated -mfloat-abi=hard -mfpu=neon-fp-armv8 -Wall -pipe -O3 -fomit-frame-pointer -DNDEBUG build/temp.linux-x86_64-3.11/src/evdev/ecodes.o -L/home/rh/projekte/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-ng.arm-21/toolchain/armv8a-libreelec-linux-gnueabihf/sysroot/usr/lib -o build/lib.linux-x86_64-3.11/evdev/_ecodes.cpython-311-x86_64-linux-gnu.so
writing build/lib.linux-x86_64-3.11/evdev/ecodes.py
Traceback (most recent call last):
File "/home/rh/projekte/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-ng.arm-21/build/_python-evdev-a47b5b5a6f79bde6823095d1105501856338aed7/src/evdev/genecodes_py.py", line 6, in <module>
from evdev import ecodes_runtime as ecodes
ImportError: cannot import name 'ecodes_runtime' from 'evdev' (unknown location)
failed to generate static build/lib.linux-x86_64-3.11/evdev/ecodes.py - will use ecodes_runtime.py
running install
running build
running build_ext
ecodes.c already exists ... skipping build_ecodes
writing build/lib.linux-x86_64-3.11/evdev/ecodes.py
Traceback (most recent call last):
File "/home/rh/projekte/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-ng.arm-21/build/_python-evdev-a47b5b5a6f79bde6823095d1105501856338aed7/src/evdev/genecodes_py.py", line 6, in <module>
from evdev import ecodes_runtime as ecodes
ImportError: cannot import name 'ecodes_runtime' from 'evdev' (unknown location)
failed to generate static build/lib.linux-x86_64-3.11/evdev/ecodes.py - will use ecodes_runtime.pyweil /usr/lib/python/evedev unvollständig ist:
Öhm. Ok. Da scheint eine Menge zu fehlen in der 21er Version.
Aber das Paket _python-evdev unterscheidet sich nicht zwischen 21 und 22 
Das wird spannend...
mit der aktuellen Version passt wohl ein Patch für vdr-plugin-restfulapi nicht mehr:
Stimmt. Allerdings bekomme ich das Plugin nicht mehr gelinkt und ich verstehe nicht warum:
VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-no.aarch64-22/toolchain/lib/gcc/aarch64-libreelec-linux-gnu/16.1.0/../../../../aarch64-libreelec-linux-gnu/bin/ld.gold: error: changestatetracker.o: incompatible targetIch versuche erstmal einen Downgrade von restfulapi.
Edit:
Ich habe die letzte Version gefunden, die noch kompiliert und jetzt kenne ich auch den Grund für die Probleme. Es ist der Commit https://github.com/yavdr/vdr-plug…cc38c0cb8bb672d
Edit 2:
seahawk1986 hat das im Repository gefixed und jetzt ist auch die letzte aktuelle Version des Plugins in VDR*ELEC verfügbar.
Auch dass Code produziert wird, den keiner versteht - teilweise nicht mal der Entwickler selbst - ist nicht neu.
Da musste ich lachen. Das geht mir bei uraltem eigenem Code manchmal auch so.
Zurück zum Thema.
Man wird nicht verhindern können, daß Open Source Quellcode zum Training verwendet wird. Ob dieser auf Github liegt oder woanders. Github hat für mich den Vorteil, daß dort Runner (amd64 und arm64) angeboten werden, die ich nutzen kann. Wie lange noch, steht in den Sternen und Self-Hosted Runner sind keine Alternative, weil soviel Rechenleistung gar nicht zur Verfügung steht.
Codeberg hatte ich auch mal in Betracht gezogen und als sehr gute Alternative für runnerlose Projekte erkannt, aber mir behagt der Split der Projekte nicht: Ein Teil auf Github und ein anderer Teil auf Codeberg.
Reine Git-Projekte haben den Vorteil relativ schnell umzugsbereit zu sein.
Bei KI generiertem Code bin ich zwiegespalten. Manchmal sieht das vernünftig aus und manchmal denke ich nur, was fürn Mist. Eine Bewertung muss immer selbst vorgenommen werden, blind vertrauen würde ich dem System nie.
Wenn ich aktuell lese, das die Kosten für KI Nutzung tokenbasiert sein soll, erledigt sich das Thema bald von selbst. Die Kosten lassen sich nicht vernünftig kalkulieren und es kann ein Faß ohne Boden werden. Irgendwie muss die ganze Investition in KI/Hardware/Energie sich auch mal rechnen.
Es wurden und werden immer wieder die wildesten Säue durchs Dorf getrieben. Wer erinnert sich noch an die Blockchain? Alles sollte (absolut sinnfrei) in die Blockchain, ein Allheilmittel und Wunderwerk der Technik. Wie auch schon oben erwähnt: Das ganze Politik- und Managergefasel muss erst aus dem Thema raus, bevor die sinnvollen Anwendungen (falls überhaupt vorhanden) erkannt werden können.
Habe stundenlang gesucht. Zum selber kompilieren hingegen gibt es viele.
Ein Plugin lässt sich nicht im luftleeren Raum compilieren. Dazu sind zumindest die passenden VDR-Header und die notwendigen Bibliotheken notwendig. Und man muss immer damit rechnen, daß noch nicht alles notwendige installiert ist und dann geht die Suche los.
Die Frage ist, was genau du willst? Den manchmal dornigen Weg gehen und VDR+Plugins selbst bauen oder einfach nur ein System haben, das funktioniert?
Für Ubuntu würde ich die einfachere Variante wählen und die yavdr Quellen einbinden (wie von @SurfaceCleanerZ) schon angemerkt oder auch yavdr-ansible in Betracht ziehen. Beide Varianten bieten zumeist sehr aktuelle Versionen des VDR und der Plugins an. Die Ubuntu eigene Version des VDR 2.6.0 ist schon relativ alt und dazu dann neue Versionen von Plugins zu erhalten ist eher schwierig.
Fragen zu yavdr(-ansible) kann man hier erfolgreich platzieren.
ich möchte das VDR Plugin IPTV installieren.
Das klingt für mich nicht so, als ob du den kompletten VDR und alle Plugins bisher selbst compiliert und installiert hast. Die erste Anlaufstelle sollte also das Repository sein, aus dem VDR und die Plugins stammen.
Welche VDR Distribution verwendest du denn? Die meisten davon haben auch eine aktuelle Version des iptv-Plugins.
Die Images für
CE 20/21/22 bauen problemlos.
LE 12 sieht bisher auch gut aus.
LE-Generic ist wie immer das Sorgenkind. Ich muss mal wieder versuchen, die zum Bau zu überreden.
Ein paar der Images für LE13 bauen nicht. Also der Build läuft schon durch, aber die Imagegenerierung schlägt bei u-boot fehl. Es wird eine Abhängigkeit zu libyaml erkannt, die auf dem System aber so gar nicht vorhanden ist.
2026-06-02T15:54:25.6881445Z Package yaml-0.1 was not found in the pkg-config search path.
2026-06-02T15:54:25.6888466Z Perhaps you should add the directory containing `yaml-0.1.pc'
2026-06-02T15:54:25.6898157Z to the PKG_CONFIG_PATH environment variable
2026-06-02T15:54:25.6898634Z No package 'yaml-0.1' found
2026-06-02T15:54:25.6899143Z Package yaml-0.1 was not found in the pkg-config search path.
2026-06-02T15:54:25.6899557Z Perhaps you should add the directory containing `yaml-0.1.pc'
2026-06-02T15:54:25.6899888Z to the PKG_CONFIG_PATH environment variable
2026-06-02T15:54:25.6900152Z No package 'yaml-0.1' found
2026-06-02T15:54:27.2746460Z /usr/bin/ld: scripts/dtc/yamltree.o: in function `yaml_propval_int':
2026-06-02T15:54:27.2747569Z yamltree.c:(.text+0x170): undefined reference to `yaml_sequence_start_event_initialize'
2026-06-02T15:54:27.2748415Z /usr/bin/ld: yamltree.c:(.text+0x17c): undefined reference to `yaml_emitter_emit'
2026-06-02T15:54:27.2749018Z /usr/bin/ld: yamltree.c:(.text+0x1f0): undefined reference to `yaml_scalar_event_initialize'
2026-06-02T15:54:27.2749622Z /usr/bin/ld: yamltree.c:(.text+0x1fc): undefined reference to `yaml_emitter_emit'
2026-06-02T15:54:27.2750204Z /usr/bin/ld: yamltree.c:(.text+0x2b8): undefined reference to `yaml_scalar_event_initialize'
2026-06-02T15:54:27.2750854Z /usr/bin/ld: yamltree.c:(.text+0x2e0): undefined reference to `yaml_sequence_end_event_initialize'
2026-06Das ist schon etwas schräg. Im Makefile sieht das so aus:
ifeq ($(wildcard $(PKG_CONFIG_SYSROOT_DIR)/usr/include/yaml.h),)
HOST_EXTRACFLAGS += -DNO_YAML
else
dtc-objs += yamltree.o
# To include <yaml.h> installed in a non-default path
HOSTCFLAGS_yamltree.o := $(shell pkg-config --cflags yaml-0.1)
# To link libyaml installed in a non-default path
HOSTLDLIBS_dtc := $(shell pkg-config --libs yaml-0.1)
endifEs gibt nirgends eine yaml.h, auch nicht auf dem Build-Host. Vielleicht verstehe ich die Bedingung da auch nicht richtig.
Ich habe mal testweise libyaml komplett rausgepatcht und damit ging der Build dann durch. Aber was stimmt nicht an der Bedingung
ifeq ($(wildcard $(PKG_CONFIG_SYSROOT_DIR)/usr/include/yaml.h),)
und wieso geht der in den else-Zweig?