Mein letztes (lauffähiges) Update ist vom 01.02
Hmm. Danach sind die Ausgabeplugins und CE/LE aktualisiert worden. Kodi läuft aber?
Ich habe heute nochmal die Packages auf letzten Versionen aktualisiert.
Mein letztes (lauffähiges) Update ist vom 01.02
Hmm. Danach sind die Ausgabeplugins und CE/LE aktualisiert worden. Kodi läuft aber?
Ich habe heute nochmal die Packages auf letzten Versionen aktualisiert.
vdr2:~ # journalctl | grep adapter
Feb 07 19:14:31 CoreELEC kernel: cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
Feb 07 19:14:31 CoreELEC kernel: video_framerate_adapter: loading out-of-tree module taints kernel.
Nach git pull läuft gerade build...
Ja, Kodi läuft. Nach dem build bzw. update berichte ich weiter.
Gestern habe ich dann noch ein build ohne dynamite gemacht und eingespielt. Mit dem Image wurde ebenfalls kein Tuner erkannt.
Dann nochmal build Ordner gelöscht und über Nacht, komplett neu, mit dynamite bauen lassen.
Heute Morgen das erzeugte Image eingespielt - alles läuft
Besitze 2x Odroid. Die oben genannte Aktion passierte auf dem Testgerät. Dann war ich mutig und habe das identische (lauffähige) Image auf dem produktiven Odroid eingespielt.
Und siehe da: keiner Tuner da - kein Signal verfügbar
Dann nochmal alles stromlos gemacht, gewartet, nochmal probiert - immer noch kein Tuner da und als letzten Versuch nochmal mit dem selben Image upgedatet.
Gleiches Ergebnis.
Das Updateprozedere unter CoreELEC ist doch stetig? Zwischendurch bin ich auch mal zurück auf das Image vom 01.02 und dann wieder ein aktuelles zum Test eingespielt...
Sollte ich mal komplett neu installieren? Ohne Update Prozedur hin und zurück.
Ich bin ratlos.
Wenn du das Update durchgeführt hast, vergewissere dich, dass es auch funktioniert hat. Bei mir schlägt das manchmal aus welchen Gründen auch immer fehl. Ein Update überschreibt dir alles bis auf den /storage-Ordner. Da sind die Einstellungen drin.
Hast du versucht, ein Image auf SD-Karte zu schreiben und diese Images bei beiden auszuprobieren? Wenn das geht, kann es nur an den Einstellungen, caches etc. unter /storage liegen. Und bevor du da lange suchst, geht es wahrscheinlich schneller, das System ganz neu aufzusetzen.
Mit update meinst Du, Du legst eine Datei in /storage/.update?
Welche? Das image oder die tar-Datei? Eigentlich sollte das keinen Unterschied machen und sowohl Kernel als auch System mit den neuen Dateien überschreiben. Wo ich mir jetzt nicht sicher bin ist, wie Zabrimus das mit den DVB-Treibern gelöst hat. Sind die direkt im Kernel durch aktuellere Versionen ersetzt worden, oder braucht man dazu ein addon "DVB drivers from the latest kernel"? Hier wäre es dann wichtig, dass nicht das gleichnamige addon aus dem CE-Paket sondern das von Zabrimus verwandt wird. Eigentlich sollten beide die WinTV dualHD unterstützen. Kann es sein, dass noch eine Firmwaredatei fehlt? Es gibt ja mehrere Revisionen von dem Stick, die unterschiedliche Firmwaredateien benötigen.
Laut Deiner Ausgabe von journalctl | grep adapter gibt es keinen einzigen DVB adapter. Poste mal einen kompletten Auszug von journalctl ab Bootvorgang.
Wenn du das Update durchgeführt hast, vergewissere dich, dass es auch funktioniert hat. Bei mir schlägt das manchmal aus welchen Gründen auch immer fehl. Ein Update überschreibt dir alles bis auf den /storage-Ordner. Da sind die Einstellungen drin.
Hast du versucht, ein Image auf SD-Karte zu schreiben und diese Images bei beiden auszuprobieren? Wenn das geht, kann es nur an den Einstellungen, caches etc. unter /storage liegen. Und bevor du da lange suchst, geht es wahrscheinlich schneller, das System ganz neu aufzusetzen.
Bei mir startet vdr als erstes, da sehe ich ja gleich ob ein Fernsehbild kommt... zur Kontrolle starte ich dann auch nochmal Kodi und damit bin ich fertig mit der Kontrolle. Beide Odroid Systeme haben eine eMMC, Update läuft über *.img.gz in /storage/.update
Mit update meinst Du, Du legst eine Datei in
/storage/.update?
Welche? Das image oder die tar-Datei? Eigentlich sollte das keinen Unterschied machen und sowohl Kernel als auch System mit den neuen Dateien überschreiben. Wo ich mir jetzt nicht sicher bin ist, wie Zabrimus das mit den DVB-Treibern gelöst hat. Sind die direkt im Kernel durch aktuellere Versionen ersetzt worden, oder braucht man dazu ein addon "DVB drivers from the latest kernel"? Hier wäre es dann wichtig, dass nicht das gleichnamige addon aus dem CE-Paket sondern das von Zabrimus verwandt wird. Eigentlich sollten beide die WinTV dualHD unterstützen. Kann es sein, dass noch eine Firmwaredatei fehlt? Es gibt ja mehrere Revisionen von dem Stick, die unterschiedliche Firmwaredateien benötigen.Laut Deiner Ausgabe von journalctl | grep adapter gibt es keinen einzigen DVB adapter. Poste mal einen kompletten Auszug von journalctl ab Bootvorgang.
Ja, ich hole mir das gebaute Image von meiner build vm (per NFS). Also z.B. CoreELEC-Amlogic-ng.arm-20.3-Nexus_devel_20240205204629-Odroid_N2.img.gz -> /storage/.update
Ahh, DVB Treiber gebe ich beim bauen mit an (./build.sh -config CoreELEC-20-ng -extra dynamite,channellogos -addon dvb-latest,dvb-tools,network-tools,system-tools). Und zusätzlich ist noch das CoreELEC Addon dvb-latest installiert. Das ist ein guter Hinweis!
Also entweder das Eine oder das Andere? Probiere es dann nochmal ohne dvb-lates im build Aufruf. Dachte es wäre das Gleiche, nur schon gleich im Image mit drin.
Aber kann das am Ende das beschriebene Verhalten verursachen?
Auf Firmware Meldungen im Journal hatte ich grep auch losgejagt. Da kam nix. Besitze insgesamt 3x WinTV dualHD, welche ich per dynamite als DVB-C oder DVB-T2 Tuner deklariere (je nach Serial). Das ermöglicht mir ein Tuner Mischbetrieb *HowTo.
Mein Testsystem hat nur einen WinTV dualHD welcher auf DVB-C gestellt ist.
Komplettes Startlog von journalctl reiche ich nach.
Danke!
Ahh, DVB Treiber gebe ich beim bauen mit an (./build.sh -config CoreELEC-20-ng -extra dynamite,channellogos -addon dvb-latest,dvb-tools,network-tools,system-tools). Und zusätzlich ist noch das CoreELEC Addon dvb-latest installiert. Das ist ein guter Hinweis!
Also entweder das Eine oder das Andere? Probiere es dann nochmal ohne dvb-lates im build Aufruf. Dachte es wäre das Gleiche, nur schon gleich im Image mit drin.
Ich meine, dass im Build-Prozess ein eigenes "Zabrimus-addon" dvb-latest erzeugt wird, das separat installiert werden muss. Wenn gleichzeitig auch das addon von CE installiert ist, kommt es evtl. zu einer Vermischung und im Ergebnis keinen lauffähigen Treibern.
Bei mir startet vdr als erstes, da sehe ich ja gleich ob ein Fernsehbild kommt... zur Kontrolle starte ich dann auch nochmal Kodi und damit bin ich fertig mit der Kontrolle.
Das startet auch, wenn das Update fehlgeschlagen ist. Mit cat /etc/release siehst du, ob die aktuelle Version auch die ist, die du installieren wolltest.
Und wenn du einfach das Addon über Kodi installierst? Der einzige Unterschied zur Version von Zabrimus sind m.E. diese Patches und damit eine andere .config. Und wie Dr. Seltsam schon geschrieben hat, ein Vermischen kann auch Probleme machen.
Ich meine, dass im Build-Prozess ein eigenes "Zabrimus-addon" dvb-latest erzeugt wird, das separat installiert werden muss.
Die Addons, die man zusätzlich bauen kann dienen nur der Bequemlichkeit bei z.B. einer Neuinstallation. Addons schnell installieren ohne erst die Richtigen in Kodi suchen zu müssen.
Das dvb-latest allerdings ist eine Ausnahme. Es entspricht zwar auch fast dem Original-Addon, allerdings wurde in meiner Version ein Log-Spamming ausgeschaltet. Näheres dazu weiß bestimmt der Anforderer und Patch-Ersteller jojo61.
Ansonsten finde ich das Problem etwas skuril. Ich vermute auch, daß es eine seltsame Mischung von Addons/Konfigurationen/o.ä. gibt. Ich würde auch mal eine neue SD oder neue Installation versuchen, um ganz sicher zu gehen.
Also z.B. CoreELEC-Amlogic-ng.arm-20.3-Nexus_devel_20240205204629-Odroid_N2.img.gz -> /storage/.update
Das funktioniert auch? Ich kopiere immer nur das tar nach /storage/.update also z.B. das CoreELEC/target/CoreELEC-Amlogic-ng.arm-20.3-Nexus_devel_20240208094217.tar.
Innerhalb eines Releases (z.B. CE-20) bin ich auch schon ohne Probleme hin- und hergesprungen. Einmal habe ich ein Update von CE-19 nach CE-20 gemacht, aber nie zurück.
Ich meine, dass im Build-Prozess ein eigenes "Zabrimus-addon" dvb-latest erzeugt wird, das separat installiert werden muss. Wenn gleichzeitig auch das addon von CE installiert ist, kommt es evtl. zu einer Vermischung und im Ergebnis keinen lauffähigen Treibern.
Gut, ich würde heute Abend unter Kodi das Addon deinstallieren und dann nochmal mein Image (mit Zabrimus dvb-latest) probieren.
Was meinst Du mit "separat installiert werden muss" genau? Bzw. wo müsste ich das installieren? Reicht es nicht, dass ich es beim bauen mit angegeben habe?
Insgesamt bin ich froh jetzt einen Lösungsansatz zu haben.
Gut, ich würde heute Abend unter Kodi das Addon deinstallieren und dann nochmal mein Image (mit Zabrimus dvb-latest) probieren.
Was meinst Du mit "separat installiert werden muss" genau? Bzw. wo müsste ich das installieren? Reicht es nicht, dass ich es beim bauen mit angegeben habe?
Bei mir liegt nach dem Build im Ordner VDRSternELEC/CoreELEC/target/addons/Amlogic-ng/20.3/arm/driver.dvb.dvb-latest/ eine Datei driver.dvb.dvb-latest-20.3.0.zip
Das ist das addon, das Du installieren musst. Dazu muss in Kodi die Installation aus lokalen zip-Dateien freigeschaltet werden. Vorher am besten ein bereits installiertes addon aus dem CE-repository deinstallieren.
ZitatInsgesamt bin ich froh jetzt einen Lösungsansatz zu haben.
Den werden wir erst so richtig dann haben, wenn Du uns endlich ein Log präsentierst
"Eigentlich" sollte das Addon (falls mit dem Image gebaut) im Image enthalten sein und sich selbst installieren, siehe hier.
Aber wenn man die commits ansieht, funktioniert das nur, wenn noch keine Version des Plugins installiert ist.
D.h. Addon per kodi deinstallieren, Verzeichnis /storage/.kodi/addons checken ob leer, VE-update installieren.
Bei mir liegt nach dem Build im Ordner VDRSternELEC/CoreELEC/target/addons/Amlogic-ng/20.3/arm/driver.dvb.dvb-latest/ eine Datei driver.dvb.dvb-latest-20.3.0.zip
Das ist das addon, das Du installieren musst. Dazu muss in Kodi die Installation aus lokalen zip-Dateien freigeschaltet werden. Vorher am besten ein bereits installiertes addon aus dem CE-repository deinstallieren.
Aha! Das muss man aber wissen...
So, hier wieder alles chic!
- Kodi gestartet und DVB driver deinstalliert
- neu gestartet
- Image: CoreELEC-Amlogic-ng.arm-20.3-Nexus_devel_20240208183448-Odroid_N2.img.gz (mit -addon dvb-latest build Option) per NFS in /storage/.update kopiert
- Neustart und Installation abgewartet
- kein Bild, dvb-latest wurde also nicht automatisch installiert
- DVB Treiber: ~/VDRSternELEC/CoreELEC/target/addons/Amlogic-ng/20.3/arm/driver.dvb.dvb-latest/driver.dvb.dvb-latest-20.3.0.zip in /storage/downloads kopiert
- Kodi gestartet und dieses dvb-latest Addon aus Zip-Datei installiert
- Neustart
- fertig
Bitte ergänze das Readme im git diesbezüglich noch. Dort steht über diese Ausnahme nix.
Für die paar mit lokalen USB Tuner...
Ein vollständiges Log (incl. Startvorgang) ist im Anhang. Allerdings vom "reparierten" Zustand.
Danke für die Hilfe!
Trotzdem komisch. Mit dem dvb-latest addon von Kodi hätte der Tuner eigentlich auch laufen müssen. War vielleicht stattdessen ein anderes Treiber-addon installiert? Ich glaube mit den dvb-Treibern von crazycat läuft der Stick nicht.
Nein, es war "nur" der dvb-latest aus dem Kodi Addon installiert. Damit lief der Tuner von Anfang meiner VDRSternELEC Versuche an.
Und aus Unwissenheit habe ich beim bauen immer -addon dvb-latest mit angegeben, aber nie explizit installiert.
"Eigentlich" sollte das Addon (falls mit dem Image gebaut) im Image enthalten sein und sich selbst installieren, siehe hier.
Aber wenn man die commits ansieht, funktioniert das nur, wenn noch keine Version des Plugins installiert ist.
D.h. Addon per kodi deinstallieren, Verzeichnis /storage/.kodi/addons checken ob leer, VE-update installieren.
Bin über den Hinweis: /storage/.kodi/addons checken drüber weg gekommen.
Unter Umständen könnte so ein Mischmasch entstanden sein. Eben mit der Folge das kein Tuner mehr erkannt wird.
Am Ende zählt für mich das Ergebnis.
Außerdem wieder was gelernt.
Poste mal ein Log vom Fehlerfall.
das Problem treibt mich weiter um. Leider wird da soviel geloggt, dass man den Wald vor lauter Bäumen sieht. Mein erster Ansatz, nur gezielt bestimmte eigene Debug-Meldungen zu loggen, war allerdings keine gute Idee - so habe ich den größen Baum auch nicht mehr gesehen
Es kommt hier beim canceln des VideoThreads zu einem segfault. In der Folge startet vdr neu. Hätte ich aufgrund der bereits beobachteten neuen Pid auch längst drauf kommen können.
Feb 18 10:17:47 CoreELECTanixTX3 vdr[6424]: [6424] executing command '/usr/bin/killall looper'
Feb 18 10:17:47 CoreELECTanixTX3 vdr[6424]: [6470] SVDRP CoreELECTanixTX3 < 127.0.0.1:51026 client connection accepted
Feb 18 10:17:47 CoreELECTanixTX3 vdr[6424]: [6470] SVDRP CoreELECTanixTX3 > 127.0.0.1:51026 server created
Feb 18 10:17:47 CoreELECTanixTX3 vdr[6424]: [6470] [softhddev]stopping Ogl Thread svdrp DETA
Feb 18 10:17:47 CoreELECTanixTX3 vdr[6424]: [6470] [softhddev]stopping OpenGL Worker Thread
Feb 18 10:17:47 CoreELECTanixTX3 vdr[6424]: [6963] [softhddev]Cleaning up OpenGL stuff
Feb 18 10:17:47 CoreELECTanixTX3 vdr[6424]: [6963] [softhddev]OglThread cleanup
Feb 18 10:17:47 CoreELECTanixTX3 vdr[6424]: [6963] [softhddev]OpenGL Worker Thread Ended
Feb 18 10:17:47 CoreELECTanixTX3 vdr[6424]: [6963] oglThread thread ended (pid=6424, tid=6963)
Feb 18 10:17:47 CoreELECTanixTX3 vdr[6424]: [6470] [softhddev]OpenGL Worker Thread stopped
Feb 18 10:17:47 CoreELECTanixTX3 vdr[6424]: [6470] [softhddev]SetPlayMode: 0
Feb 18 10:17:47 CoreELECTanixTX3 vdr[6424]: [6470] [softhddev]SetVolumeDevice: 255
Feb 18 10:17:47 CoreELECTanixTX3 vdr[6424]: Set Playmode 0
Feb 18 10:17:47 CoreELECTanixTX3 vdr[6424]: amlreset
Feb 18 10:17:47 CoreELECTanixTX3 vdr[6424]: [softhddev]Clear: 20ms buffers 0
Feb 18 10:17:47 CoreELECTanixTX3 vdr[6424]: [6470] [softhddev]SetVideoDisplayFormat: 1
Feb 18 10:17:47 CoreELECTanixTX3 vdr[6424]: [6470] [softhddev]GetSpuDecoder:
Feb 18 10:17:47 CoreELECTanixTX3 vdr[6424]: [6470] [softhddev]SetPlayMode: 1
Feb 18 10:17:47 CoreELECTanixTX3 vdr[6424]: [6470] [softhddev]SetVolumeDevice: 255
Feb 18 10:17:47 CoreELECTanixTX3 vdr[6424]: Set Playmode 1
Feb 18 10:17:47 CoreELECTanixTX3 vdr[6424]: set trickspeed to 0
Feb 18 10:17:47 CoreELECTanixTX3 vdr[6424]: [softhddev]Suspend:
Feb 18 10:17:47 CoreELECTanixTX3 vdr[6424]: VideoStreamClose
Feb 18 10:17:47 CoreELECTanixTX3 vdr[6424]: CodecVideoClose Pip 0 Handle 7
Feb 18 10:17:47 CoreELECTanixTX3 vdr[6424]: DelHWDecoder PIP 0
Feb 18 10:17:47 CoreELECTanixTX3 vdr[6424]: VideoExit
Feb 18 10:17:47 CoreELECTanixTX3 vdr[6424]: TEST softhdodroid] video.c VideoExit(): jetzt wird VideoThreadExit aufgerufen
Feb 18 10:17:47 CoreELECTanixTX3 vdr[6424]: video: video thread canceled
Feb 18 10:17:47 CoreELECTanixTX3 vdr.sh[4116]: Segmentation fault
Feb 18 10:17:47 CoreELECTanixTX3 vdr.sh[4116]: Sun Feb 18 10:17:47 CET 2024 reloading DVB driver
Feb 18 10:17:47 CoreELECTanixTX3 vdr.sh[4116]: Sun Feb 18 10:17:47 CET 2024 restarting VDR
Feb 18 10:17:47 CoreELECTanixTX3 vdr[6987]: [6987] VDR version 2.6.6 started
Alles anzeigen
Den Code in VideoThreadExit habe ich um Debug-Ausgaben ergänzt:
if (VideoThread) {
void *retval;
Debug(3, "video: video thread canceled\n");
// FIXME: can't cancel locked
if (pthread_cancel(VideoThread)) {
Debug(3, "video: can't queue cancel video display thread\n");
}
usleep(200000); // 200ms
if (pthread_join(VideoThread, &retval) || retval != PTHREAD_CANCELED) {
Debug(3, "video: can't cancel video decoder thread\n");
}
if (retval == PTHREAD_CANCELED) {
Debug(2, "TEST: Status=PTHREAD_CANCELED\n"); //wird das im Erfolgsfall jemals geloggt?
} else {
Debug(2, "TEST: VideoThread konnte nicht gecancelt werden\n");
}
Debug(2, "TEST: VideoThreadExit wird verlassen und VideoThread auf 0 gesetzt\n");
VideoThread = 0;
}
Alles anzeigen
Außer der ersten Debug-Meldung wird hier nie irgendwas geloggt. Da VideoThreadExit zum VideoThread gehört, kommt der Code wahrscheinlich gar nicht mehr zur Ausführung, weil der Thread dann schon gecancelt ist. Damit kann dann aber auch VideoThread nie auf 0 gesetzt werden.
Da das Plugin trotz Suspend-Modus wieder auf Playmode 1 geht (???) , wird ggf. VideoDisplaywakeup aufgerufen, wo geprüft wird, ob VideoThreadInit ausgeführt werden muss. Hier sollte entgegen meiner ersten Annahme nun eigentlich nichts passieren, da dazu VideoThread false sein müsste - was aber wie oben beschrieben offenbar nie passieren kann.
Ein zweiter Fall, gerade aufgetreten:
Feb 18 10:59:26 CoreELECTanixTX3 vdr[9813]: [9813] executing command '/usr/bin/killall looper'
Feb 18 10:59:27 CoreELECTanixTX3 vdr[9813]: [9859] SVDRP CoreELECTanixTX3 < 127.0.0.1:51066 client connection accepted
Feb 18 10:59:27 CoreELECTanixTX3 vdr[9813]: [9859] SVDRP CoreELECTanixTX3 > 127.0.0.1:51066 server created
Feb 18 10:59:27 CoreELECTanixTX3 vdr[9813]: [9859] [softhddev]stopping Ogl Thread svdrp DETA
Feb 18 10:59:27 CoreELECTanixTX3 vdr[9813]: [9859] [softhddev]stopping OpenGL Worker Thread
Feb 18 10:59:27 CoreELECTanixTX3 vdr[9813]: [9840] [softhddev]Cleaning up OpenGL stuff
Feb 18 10:59:27 CoreELECTanixTX3 vdr[9813]: [9840] [softhddev]OglThread cleanup
Feb 18 10:59:27 CoreELECTanixTX3 vdr[9813]: [9840] [softhddev]OpenGL Worker Thread Ended
Feb 18 10:59:27 CoreELECTanixTX3 vdr[9813]: [9840] oglThread thread ended (pid=9813, tid=9840)
Feb 18 10:59:27 CoreELECTanixTX3 vdr[9813]: [9859] [softhddev]OpenGL Worker Thread stopped
Feb 18 10:59:27 CoreELECTanixTX3 vdr[9813]: [9859] [softhddev]SetPlayMode: 0
Feb 18 10:59:27 CoreELECTanixTX3 vdr[9813]: [9859] [softhddev]SetVolumeDevice: 255
Feb 18 10:59:27 CoreELECTanixTX3 vdr[9813]: Set Playmode 0
Feb 18 10:59:27 CoreELECTanixTX3 vdr[9813]: amlreset
Feb 18 10:59:27 CoreELECTanixTX3 vdr[9813]: [softhddev]Clear: 20ms buffers 0
Feb 18 10:59:27 CoreELECTanixTX3 vdr[9813]: [9859] [softhddev]SetVideoDisplayFormat: 1
Feb 18 10:59:27 CoreELECTanixTX3 vdr[9813]: [9859] [softhddev]GetSpuDecoder:
Feb 18 10:59:27 CoreELECTanixTX3 vdr[9813]: [9859] [softhddev]SetPlayMode: 1
Feb 18 10:59:27 CoreELECTanixTX3 vdr[9813]: [9859] [softhddev]SetVolumeDevice: 255
Feb 18 10:59:27 CoreELECTanixTX3 vdr[9813]: Set Playmode 1
Feb 18 10:59:27 CoreELECTanixTX3 vdr[9813]: set trickspeed to 0
Feb 18 10:59:27 CoreELECTanixTX3 vdr[9813]: [softhddev]Suspend:
Feb 18 10:59:27 CoreELECTanixTX3 vdr[9813]: VideoStreamClose
Feb 18 10:59:27 CoreELECTanixTX3 vdr[9813]: CodecVideoClose Pip 0 Handle 12
Feb 18 10:59:27 CoreELECTanixTX3 vdr[9813]: DelHWDecoder PIP 0
Feb 18 10:59:27 CoreELECTanixTX3 vdr.sh[4116]: Segmentation fault
Alles anzeigen
Hier crasht es nun schon, ehe VideoExit (und in der Folge VideoThreadExit) aufgerufen werden. ??
Wo genau das jetzt knallt, ist wohl nur mit einem backtrace zu ermitteln. Aber seitdem ich ulimit -c unlimited vor dem Aufruf der runvdr im CE-Script vdr.sh drin habe, crasht es nicht mehr...
Vielleicht ist es doch am einfachsten, wenn wir den Aufruf von VideoThreadExit in VideoExit einfach rausnehmen? So läuft das bei mir produktiv auf dem N2 seit Wochen ohne Probleme.
Mahlzeit Zabrimus ,
wie viele andere nutze ich Deine Basis auch auf Systemen, wo vdr in chroot läuft. Deine Kernelerweiterungen u.a. für eine RTC für die Tanix TX3 sind unverzichtbar, und auch das dvb-latest-Paket enthält ja einige Extratreiber (z.B. den von mir gewünschten pvrusb2) sowie ein weniger gesprächiges logging.
Bis jetzt hatte ich ein dvb-latest Paket aus Oktober für 20.3.0 im Einsatz, das ich mal in meinem build-system erzeugt hatte. Das funktionierte auch noch mit dem letzten CE-update. Mit dem aktuellen update von CE ng auf 20.4 funktioniert das nicht mehr, die Module bringen beim Laden "Exec format error".
Der build-Prozess ist für mich in weiten Teilen immer noch ein Buch mit 7 Siegeln. Kann ich ein einzelnes addon kompilieren, ohne dass dabei auch ein komplettes image gebaut wird?
In Deinem git finde ich unter releases nur images und update-files, aber keine fertig kompilierten addons. Vielleicht könntest Du zumindest für die von Dir gepatchten addons die installationsfertigen zip-Pakete auch bereitstellen?
Und dann hätte ich auch gleich noch einen Wunsch für dvb-latest: Könntest Du da bitte den Treiber hdpvr (drivers/media/usb/hdpvr) mit anknipsen? Das ist CONFIG_VIDEO_HDPVR.
Gruß
Dr. Seltsam
Hallo Zabrimus,
ich hab seit ein paar Monaten VDRSternElec mit HbbTV im Einsatz und bin sehr zufrieden.
Eine Kleinigkeit stört mich noch. Der Start des Systems dauert damit sehr lange.
Mit systemd-analyze plot ergibt sich dieses Bild: (Anhang in systemd.svg umbennen und mit dem Browser öffnen)
Zeit seit boot
..
10 Sec sys-devices-virtual-net-docker0.device
34 Sec cefbrowser.service
docker.service
34.5 Sec vdropt.service
Wie man im Plot schön sehen kann, passiert nach dem Start von sys-devices-virtual-net-docker0.device ca. 24 Sekunden nichts mehr, dann starten cefbrowswer und docker und der VDR
Ist das bei Dir ähnlich?
Kann man evtl. den VDR schon ohne Browser starten? Ich hab allerdings keine Abhängigkeit in den systemd units gefunden.
Hast Du an den systemd units zwischenzeitlich noch was geändert, was beim normalen Update nicht automatisch übernommen wird?
Schöne Grüße
Lothar
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!