Die Frage ist, warum bis zum nächsten NTC-Update die RTC des Rechners so weit falsch gehen konnte ...
Installation eines VDR+Plugins nativ auf CoreELEC Boxen
-
-
Wenn ich das richtig sehe dann wird nicht die RTC des Rechner genutzt sondern die Softwareuhr. Die wird beim start des Rechners aus der RTC geladen.
Ich habe nun mal die ganzen NTP updates abgehängt und die Softwareuhr über den vdr stellen lassen. Das Ergebniss bleibt gleich (die Zeit springt).
Nun stellt sich die Frage warum die Softwareuhr so falsch läuft.
Edit:
So einfach war das abschalten des NTP beim connman doch nicht. Aber nun habe ich es geschafft und der NTP ist weg. Damit springt die Zeit zwar immer noch, aber nun ändert der vdr das mit adjtime und damit gibt es keine sprünge mehr. Damit sind dann die Bufferoverflows weg.
-
Zabrimus So das zweite Problem ist auch gelöst (siehe vtunger-ng thread). Falls Joe_D sein GIT nicht nachzieht dann schicke ich dir einen patch.
Ich habe die letzten beiden Tage einen neuen VDR mit deinem Image aufgebaut und dort auch den cefbrowser und das web plugin eingerichtet. Dabei sind mir ein paar Dinge aufgefallen:
- im socket.ini sind deine IP Adressen enthalten. Es wäre besser wenn du dort 127.0.0.1 eintragen würdest. Die meisten haben eh alles lokal laufen.
- nach dem Installieren von docker im Kodi werden 2 service dateien dafür in .config/system.d angelegt. Die service.docker.. muss man löschen. Ansonsten werden beim start 2 docker instanzen gestartet und dann started der cefbrowser nicht mehr.
- im cefbrowser.service solltest du am Schluss noch den Parameter -z 1920 einfügen. Das ist eh der Standard der meisten User.
- ich habe die socket.ini und codec.ini manuell in .conig/vdropt angelegt. Sie wurden beim installieren vom cefbrowser nicht umkopiert.
- es fehlen die Batches die beim runterfahren prüfen wann die nächste Aufnahme gestartet werden soll und die den Wakeup entsprechend setzen.
Ich könnte dir meine batches dafür zur verfügung stellen damit sie mit aufgenommen werden.
Damit sollte es besser Out of the Box laufen.
-
- im socket.ini sind deine IP Adressen enthalten. Es wäre besser wenn du dort 127.0.0.1 eintragen würdest. Die meisten haben eh alles lokal laufen.
Hmm. Ich bin eigentlich davon ausgegangen, daß nun alle Nutzer ihr lokales Netzwerk umstellen und die IP aus der Config verwenden Das Problem wurde schon einmal angesprochen, aber ich habe es tatsächlich vergessen.
- nach dem Installieren von docker im Kodi werden 2 service dateien dafür in .config/system.d angelegt. Die service.docker.. muss man löschen.
Ahhh. Du hast es gefunden? Da meine letzte neue frische Installation schon lange sehr her ist und ich auch über das Problem
gestolpert bin, wollte ich es untersuchen und habe es dann - wie oben - einfach vergessen.
Patches oder Scripte um alles "out of the box" lauffähig zu bringen nehme ich auf jeden Fall sehr gern entgegen.
-
Patches oder Scripte um alles "out of the box" lauffähig zu bringen nehme ich auf jeden Fall sehr gern entgegen.
So hier nun ein paar Scripte. Alles muss nach /storage/.config/vdropt. Nun mal kurz wofür sie gut sind:
- wakeupacpi
Testet beim runterfahren wann der nächste Timer ansteht und setzt die Wakeupzeit.
Beim start wird er vom autostart.sh aufgerufen und prüft ob es ein RTC Wakeup ist. Dann setzt er ein Flag damit der vdr nach der Aufnahme wieder runterfährt.
- makesleep
Wird vom vdr nach einer Aufnahme aufgerufen und prüft ob das Flag sitzt um dann runterzufahren.
- stopwaiter
Wird von makesleep aufgerufen und verzögert den Aufruf von stopmidas damit der Timer der gerade beendeten Aufnahme auch sicher schon gelöscht ist.
- stopmidas
Wird vom vdr per command.conf oder beim drücken der Power Taste aufgerufen und prüft ob aktuelle Aufnahmen laufen oder in kürze anstehen. Dann wird ein Flag gesetzt und der vdr bleibt angeschaltet. Nach der Aufnahme wird dann runtergefahren (siehe makesleep).
Nun noch ein paar Änderungen an bestehenden Scripten:
- autostart.sh (muss nach .config)
Das ist die autostart.sh von Kodi und dort muss dann wakeupacpi aufgerufen werden.
- vdr.conf (muss nach .config/vdropt/conf.d)
Hier sind die Aufrufe der Scripte vom vdr konfiguriert.
- commands.conf
Hier habe ich den Shutdown verändert, damit stopmidas aufgerufen wird.
-
So hier nun ein paar Scripte.
Danke. Ich habe alles in VDR*ELEC untergebracht. An die Default Konfiguration (IP Adressen) des Browsers und Konsorten muss ich noch ran.
-
Nur zur Sicherheit... der commit funktioniert auch mit Versionen != Coreelec+Odroid bzw. wirkt sich da nicht nachteilig aus?
-
Nur zur Sicherheit... der commit funktioniert auch mit Versionen != Coreelec+Odroid bzw. wirkt sich da nicht nachteilig aus?
Hmmm... Guter Punkt.
Wenn ich das richtig sehe, dann können Probleme eigentlich nur in wakeupacpi auftauchen. Da könnten systemspezifische Aktionen stattfinden.
Ob überall
verfügbar ist, kann ich nicht beurteilen.
-
Bis auf den Aufruf von hwclock ist alles linux standard. Den musste ich Ändern weil beim Kodi nur eine busybox ist. Da hat hwclock leicht andere Parameter. Den Aufruf könnte man auch weg lassen so lange sichergestellt ist das die Hardwareuhr auf UTC läuft.
-
passt das denn auch für Boxen ohne Hardware-RTC wie Tanix TX3? In meinem Shutdown-Script gibt es im Gegensazu zu dem auf dem N2 keinen hwclock-Aufruf.
Bash#!/bin/bash NextTimer=$(($1 - 600 )) # 10 minutes earlier bash -c "echo 0 > /sys/class/rtc/rtc0/wakealarm" if test $NextTimer -gt "0"; then bash -c "echo $NextTimer > /sys/class/rtc/rtc0/wakealarm" fi halt -p
QuoteWird vom vdr per command.conf oder beim drücken der Power Taste aufgerufen und prüft ob aktuelle Aufnahmen laufen oder in kürze anstehen. Dann wird ein Flag gesetzt und der vdr bleibt angeschaltet.
sollten das Handling nicht besser vdr anhand seiner setup-Parameter überlassen werden?
CodeMin. event timeout = 30 Min. user inactivity = 300 If the command line option '-s' has been set, VDR will automatically shutdown the computer if the next timer event is at least MinEventTimeout minutes in the future, and the user has been inactive for at least MinUserInactivity minutes. Setting MinUserInactivity to 0 disables the automatic shutdown, while still retaining the possibility to manually shutdown the computer.
-
sollten das Handling nicht besser vdr anhand seiner setup-Parameter überlassen werden?
Ich fahre den VDR immer per Command runter. Falls dann aber noch eine Aufnahme läuft dann verhindert das Script das der vdr runterfährt und sorgt dafür das er es nach der Aufnahme dann tut. Du kannst die scripte ja mal auf deiner Tanix ausprobieren und siehst dann ob es klappt. Auch deine Tannix hat ja eine virtuelle RTC für den wakeup.
Du kannst den -s Parameter für den VDR auch gerne auf deinem Script belassen. Nur fährt er dann auch nach der Aufnahme runter ?
Aber vielleicht habe ich das Prozedere mit dem -s Parameter bisher auch nicht verstanden
-
Für mich als jemanden, der seine Rockchip Kisten überhaupt nicht herunterfährt, ist das alles nicht relevant. Darum nur meine Nachfrage... Wenn auch evtl. sonst niemand, aber zumindest ich nutze VDRSternElec nicht mit einem Amlogic/CoreELEC Wenn der commit zu keinen Komplikationen führt, ist alles gut. Ansonsten wäre ein hardwarebezogener Patch oder ein Opt-In besser.
-
Wenn der commit zu keinen Komplikationen führt,
Wenn du nie runter fährst dann betrifft es dich nicht.
Mit den Scripten wird nur bewirkt das der VDR bei einer laufenden Aufnahme nicht runterfährt, sondern erst danach.
Und bei einem Timer wakeup für eine Aufnahme wird sichergestellt das er nach der Aufnahme wieder runterfährt.
Solange du an der vdr.conf nichts änderst bleibt alles so wie es war. Die wird ja nicht automatisch upgedatet.
-
Kannst Du bitte das vdr-plugin-statusleds mit aufnehmen? Aktuelle Version: https://github.com/j1rie/vdr-plugin-statusleds
Mein Ziel ist dann LED per Odroid gpio anzusteuern.
-
Kannst Du bitte das vdr-plugin-statusleds mit aufnehmen?
Erledigt.
-
Ok, super - aber es klemmt noch irgendwo:
CodeTraceback (most recent call last): File "/home/rossi/VDRSternELEC/CoreELEC/scripts/genbuildplan.py", line 374, in <module> REQUIRED_PKGS = processPackages(args, ALL_PACKAGES) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/rossi/VDRSternELEC/CoreELEC/scripts/genbuildplan.py", line 303, in processPackages raise Exception(msg) Exception: Invalid package reference: dependency _vdr-plugin-statusleds in package vdr-all::PKG_DEPENDS_TARGET is not valid Parallel build failure - see log for details. Time of failure: Mon Nov 4 18:24:05 UTC 2024 make: *** [Makefile:10: image] Error 1
-
Ok, super - aber es klemmt noch irgendwo:
Ei ei ei. Lokaler Build -> Alles gut. Nur der Commit war nicht vollständig
Jetzt sollte es aber bauen.
-
Build ist durch, aktuelles image installiert, Datei ~/.config/vdropt/enabled_plugins editiert bzw. um statusleds erweitert, Neustart - aber das Plugin wird nicht geladen.
Leere Config Datei angelegt: touch /storage/.config/vdropt/conf.d/statusleds.conf hat nicht gereicht.
Probiere Morgen weiter.
-
Leer reicht nicht, damit VDR ein Plugin lädt, muss zumindest [<Plugin Name>] drin stehen.
-
Und mal wieder baut es nicht Diesmal ist es das plugin dvbapi.
Code
Display Morehome/jojo/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-ng.arm-21/toolchain/bin/armv8a-libreelec-linux-gnueabihf-g++ -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 -O3 -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -c -DPLUGIN_NAME_I18N='"dvbapi"' -DGITVERSION='"-GIT-873477d999"' -DLIBDVBCSA_NEW -DLIBDVBCSA -DLIBSSL -o DVBAPI.o DVBAPI.cpp DeCSA.cpp: In function 'void aes_set_control_words(void*, const unsigned char*, const unsigned char*)': DeCSA.cpp:102:22: warning: 'int AES_set_decrypt_key(const unsigned char*, int, AES_KEY*)' is deprecated: Since OpenSSL 3.0 [-Wdeprecated-declarations] 102 | AES_set_decrypt_key(ev, 128, &((struct aes_keys_t *) aeskeys)->even); | ~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from DeCSA.h:35, from DeCSA.cpp:34: /home/jojo/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-ng.arm-21/toolchain/armv8a-libreelec-linux-gnueabihf/sysroot/usr/include/openssl/aes.h:54:5: note: declared here 54 | int AES_set_decrypt_key(const unsigned char *userKey, const int bits, | ^~~~~~~~~~~~~~~~~~~ DeCSA.cpp:103:22: warning: 'int AES_set_decrypt_key(const unsigned char*, int, AES_KEY*)' is deprecated: Since OpenSSL 3.0 [-Wdeprecated-declarations] 103 | AES_set_decrypt_key(od, 128, &((struct aes_keys_t *) aeskeys)->odd); | ~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/jojo/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-ng.arm-21/toolchain/armv8a-libreelec-linux-gnueabihf/sysroot/usr/include/openssl/aes.h:54:5: note: declared here 54 | int AES_set_decrypt_key(const unsigned char *userKey, const int bits, | ^~~~~~~~~~~~~~~~~~~ DeCSA.cpp: In member function 'bool DeCSAKey::Set_even_control_word(const unsigned char*, unsigned char)': DeCSA.cpp:422:5: error: 'dvbcsa_bs_key_set_ecm' was not declared in this scope; did you mean 'dvbcsa_bs_key_set'? 422 | dvbcsa_bs_key_set_ecm(ecm, even, cs_key_even); //libdvbcsa must be upgraded to support this. | ^~~~~~~~~~~~~~~~~~~~~ | dvbcsa_bs_key_set
Ich hatte gar nicht gesehen das das plugin upgedatet wurde.
Der git pull hatte diesbezüglich nichts angezeigt.
Participate now!
Don’t have an account yet? Register yourself now and be a part of our community!