Link-Fehler findet man immer erst dann, wenn es jemand meldet oder man das sources komplett löscht (was ich eher gaaaanz selten mache).
Bei VDR*ELEC klar, ich meinte die "offiziellen" nightlies... 
Posts by rell
-
-
Dr. Seltsam : Zwar ungetestet, aber baut: https://github.com/rellla/VDRS…cc457d45cb368f9822583d134
Das Problem ist, dass es bei den CoreELEC Builds wohl auch ein Cache gibt, aus dem die Quellen gezogen werden, und es erst dann auffällt, wenn es jemand meldet.
12 Stunden sind krass. Ich hatte hier vor ein paar Tagen ca. 3h für einen CoreELEC-21 build. 20 und 19 bewegen sich auch so um die 3 Stunden - bei einem frischen build. Spätere builds brauchen je nach neuen Paketen zwischen 2-7min.
Zugegeben, hier werkelt auch ein i7-3770@3,4GHz und 24GB Ram...
-
generell habe ich nichts dagegen. Nur wie sieht es in der Zukunft aus, weißt du/ihr schon etwas darüber wie es mit der Unterstützung im Kernel weiter gehen soll?
Dazu äußern sich ja schon die Eingangsposts in diesem Thread...
Langfristig Spass macht das wohl nur mit mainline Unterstützung. Der kurzfristige Erfolg ist zwar schön und reicht wohl für die meisten, aber evtl. wäre es kein Schaden, dass man sich anschaut, wie weit LibreELEC hier schon ist? Das nutzt zumindest zukunftssichere Komponenten. Vor einiger Zeit hatte ich das Image für eine S905 Box mal kurz angetestet, und kodi und vdr liefen zumindest schon mal...
EDIT: https://linux-meson.com/hardware.html würde doch gar nicht so schlech aussehen für S922X -
Und ja, das Verhalten von softhdodroid in und ausserhalb der chroot ist in der Tat seltsam, wenn denn sonst alles gleich ist...
-
aber wenn du selbst entwickelst oder so wie ich immer nah an den Entwicklern bist ist das schon extrem hinderlich. - alleine heute das Problem mit softhdodroid mit jojo61 zu testen wird da schon zum Problem.
Ich sehe das Problem hier nicht, bzw. für mich ist es akzeptabel. softhddevice-drm teste ich auch mit dem Image. Patch ins Verzeichnis, image bauen (<2min), update, fertig. Klar da sind wir bei 5-10 Minuten, aber dafür spare ich mir die chroot.
-
Dr. Seltsam: Interessehalber kurze Zwischenfrage... was ist eigentlich der Grund für die chroot Umgebung? Nur um zu kompilieren?
-
Für Nr. 1 sollte es reichen, die kernelconfigs zu patchen. https://github.com/CoreELEC/Co…/devices/Amlogic-ne/linux
-
Es wird ja anscheinend auf der Konsole immer nur angezeigt, welches Paket zuletzt fertig gebaut wurde ("DONE"). Vielleicht kannst Du künftig auch anzeigen, welches Paket aktuell gebaut wird?
Das macht CE/LE standarsmäßig so, stört mich aber auch. Das könnte man sicher patchen.
Ich hatte kurz vor 18 Uhr begonnen. Nach
Gibt es eine Möglichkeit, den build-Prozess auf ein oder mehrere bestimmte images zu beschränken? Im target-Ordner habe ich jetzt images auch für Boxen, die ich gar nicht habe. Mir hätten das generic und das für den N2 gereicht. Wahrscheinlich hätte das auch noch Zeit gespart.
Mit der Variable UBOOT_SYSTEM kannst du das auf ein System beschränken. https://wiki.libreelec.tv/deve…/build-commands-le-11.0.x
-
Könnte sein. Vielleicht findest du in den Dateien in .threads/* Hinweise. Zumindest zu dem was auf dem Plan steht und was fertig ist. Oder du schaust direkt ins build Verzeichnus und beobachtest einfach den aktuellsten Ordner
-
Ich hatte mal Probleme mit zu wenig Arbeitsspeicher. Swapt er?
-
Die Logs sind im build Ordner unter CoreELEC/build*/.threads/logs
Da kannst du nach dem aktuellsten schauen. Jedes Paket produziert sein eigenes Log.
Ich weiß nicht wie mächtig dein build host ist, aber kodi wäre eines der größeren Pakete, was eher am Ende kommt...
-
So gehts auch, bei x86 allerdings mit Libreelec. Bei einer direkten Installation von VDR*ELEC sollte es aber auch nicht anders sein. Hier wird zusätzlich nur VDR aufgesattelt.
-
Vorausgesetzt, du hast https://github.com/Zabrimus/VDRSternELEC#readme durchgeackert, musst du überhaupt nichts für VDR nachinstallieren, da VDR*ELEC bereits alles mitbringt. Das schlechteste, was am Ende passieren sollte, ist, dass der VDR aufgrund von Ausgabedevice Problemen nicht startet. Da hat eben noch keiner getestet und ich bin da in den verschiedenen intel/nvidia/libplacebo Geschichten nicht drin.
Also, image Datei von einem der letzten Releases von https://github.com/Zabrimus/VDRSternELEC nehmen und die readme durcharbeiten. Danach sollten erst die Probleme kommen.
-
Zabrimus' VDRSternELEC benutzt CoreELEC @ c88b1dd (https://github.com/Zabrimus/VDRSternELEC).
Stimmt so generell nicht. Beim build über build.sh wird für Corelec-20 builds immer HEAD von coreelec-20 ausgecheckt. Die Version des submoduls stimmt nur nicht im git, da eine neuere Version wohl nicht gepusht wurde.
coreelec-19 nutzt in der Tat die 0.10.1
EDIT: Hm, warte, muss meine Aussage nochmal überdenken.
-
Keine Ahnung
So, wie es mit LibreELEC läuft, läufts auch hier. Google wird dir helfen... Es hat sich imo noch niemand getraut, x86 zu probieren.
-
Einen Nvidia Vergleich kann ich schlecht machen, weil ich schon Jahre keinen x86 vdr mehr habe. Die Bildqualität ist Top und die Umschaltzeiten sind flotter als mit dem alten softhddevice.
Kannst du die Umschaltzeiten zeitlich abschätzen oder im Optimalfall ein kleines Video machen
? Bei mir läuft der Rock 4 Plus und ich bin nicht sicher, was schnelle/normale/langsame Umschaltzeiten sind.Ansonsten klare Empfehlung für einen RK3399. Läuft hier 2x als (PCIe-lose) Variante mit Futter vom Server. Als "Fertigprodukt" läuft auf dem Rockpro64 auch VDR*ELEC.
Gruß
Andreas
-
Das Thema habe ich schon länger im Kopf. Es muss doch einfacher gehen, als jedesmal das Makefile zu patchen. Das macht LE/CE bei den anderen packages ja auch nicht... Auch bei den mitgelieferten vdr-plugins nicht.
Ich könnts mir beizeiten mal anschauen, wenn du willst... Am Ende würde es vieles entschlacken und einfacher machen.
Gruß
Andreas
-
-
Die Fehlermeldung riecht für mich übrigens stark danach, dass du da ein kleines Durcheinander mit den FFMpeg und softhddevice Versionen hast, die da gegeneinander gebaut wurden bzw. jetzt zusammen benutzt werden sollen. ff_hevc_dsp_init_aarch64
gabs wohl im header, den das softhddevice haben will, in der verlinkten lib ist es aber nicht mehr da... softhddevice muss immer gegen dieselbe ffmpeg Version gebaut bzw. gelinkt werden.
-
Wenn du die Kernel- und FFMpeg Versionen inkl. Patches verwendest, die auch LIbreELEC nutzt, sollte es funktionieren.
P.S.: Die Libreelec-Variante habe ich ausprobiert. Sie läuft, deckt aber noch nicht alle Bereiche ab
....Wäre es für dich eine Option, wenn du deine LE-Variante für dich um die Bereiche erweiterst?
