Posts by Zabrimus

    Mir fällt aber auf, dass nachdem kodi einmal lief und einen Film abgespielt hat, auch nach Rückkehr zu vdr an mehreren Stellen

    decoder.h264.dec_control=4 statt decoder.h264.dec_control=0 steht.

    Viel findet man dazu ja nicht.

    Quote

    It is Amlogic hardware decoder parameter called DEC_CONTROL_FLAG_DISABLE_FAST_POC. What does it do exactly I don't know apart from improving LiveTV playback. ;)

    linux-amlogic/vh264.c at amlogic-3.14.y · LibreELEC/linux-amlogic · GitHub

    Was du machen könntest, wäre in der /storage/.config/autostart.sh so ziemlich am Anfang bevor das andere Script aufgerufen wird das hier einfügen

    echo 4 > /sys/module/amvdec_h264/parameters/dec_control

    Damit der Parameter vor dem VDR/Kodi Start gesetzt wird und mal schauen, ob das Auswirkungen hat.

    ich muss mich korrigieren: Heute morgen nach dem Booten (direkt in vdr) war die Umschaltgeschwindigkeit wieder wie vorher. Aber nachdem ich zu kodi gewechselt habe, dort kurz einen Film abgespielt, gestoppt und zu vdr zurückgewechselt habe, ist das turboschnelle Umschalten wieder präsent.

    Das ist seltsam. Hinterlässt Kodi vielleicht doch irgendwelche Einstellungen, die nicht zurückgesetzt werden?

    Vielleicht muss ich nochmal alles und noch mehr vergleichen.

    Der Trigger zum wechseln zwischen Kodi/VDR ist die systemd unit switch_kodi_vdr.path. Sobald die Datei

    /storage/.cache/switch_kodi_vdr geändert wird, wird das systemd unit switch_kodi_vdr.service gestartet, welches ihrerseits dann das Script switch_kodi_vdr.sh aufruft. Das entscheidet dann zwischen dem Wechsel Kodi <-> VDR.


    Aber es gibt tatsächlich etwas, was du in softhdodroid ändern könntest ;)

    Ich habe mir die Werte von /sys/class/* angeschaut: Direkt nach dem Booten, nach dem Start von Kodi, Beenden von Kodi, Beenden von VDR um Unterschiede festzustellen.

    Und nach ein paar Testläufen kam ich auf folgendes Kommando, das nach dem Beenden von VDR den Player in Kodi nicht mehr abstürzen lässt:

    echo rm pip0 > /sys/class/vfm/map

    Die Map scheint ursächlich für das Problem zu sein. Ich könnte das in die Scripte einbauen, aber sinnvoller wäre es m.E. in softhdodroid. Damit wird wieder fast der Zustand Boot = Ende von VDR hergestellt.

    So. Neue SD Karte und ganz frische Installation mit dem Generic Image aus dem Repository.

    Die Fehler in den Pfaden sollten gefixed sein und das install script sollte keine Fehlermeldung mehr anzeigen.


    Zum Thema VDR->Kodi->Mediathek:

    Das Fehlerbild ist jetzt leicht anders. Es kommen ein paar Sätze Ton allerdings ohne Bild, bevor wieder der Trace im Log zu sehen ist.

    Habe nun rausgefunden das /storage .opt gefehlt hat. Jetzt wird zwar alles angelegt aber das script switch_kodi_vdr.sh wird nicht aktiviert.

    Mist. Da muss ich nochmal ran. Ich habe entware recht früh installiert und nicht in Betracht gezogen, daß /storage/.opt (oder eben der Link /opt -> /storage/.opt) nicht existieren muss.


    So nun habe ich es genau so gemacht wie beschrieben. Nur leider crashed da nix


    Was mir aufgefallen ist, die Version wo alles unter CE läuft (ohne chroot) ist deutlich langsamer als mit Ubuntu unter chroot.

    Okayyy. Die 0.2.1 ist das letzte Release. Ich glaub danach kam nur noch dein Cleanup in softhdodroid. Ich brauche eine neue SD Karte und muss ganz frisch anfangen. Vielleicht habe ich zu oft hin und her geflasht und irgendwas (de)installiert.


    Aber was meinst du mit langsamer und dann auch noch deutlicher? Wo sollte denn da eine Bremse sein? Hmm... Da muss ich mal nachdenken.


    Trotzdem Danke für den Test. Ich schnapp mir jetzt eine neue SD Karte und fang neu an. Dann kann ich auch direkt die Scripte/Pfade korrigieren.

    systemctl mask kodi

    Damit verliere ich leider den autostart. Aber ich denke, das werde ich mal überarbeiten und eine neue unit einführen.


    Meine Meinung: wenn irgendwas deswegen in Kodi nicht stabil läuft, und sei es nur irgendein addon, dann sollte man auf PIP verzichten. Wer kodi nicht braucht und nur einen vdr laufen lassen will, braucht dazu kein CoreElec sondern kriegt das auch mit dem Ubuntu-image von Hardkernel hin.

    Es wäre m.E. eine Verschwendung, den Odroiden nur als reine vdr-Box zu nutzen. So wichtig ist PIP nicht. Ich muss gestehen, dass ich es auf dem Nvidia-PC seit über 10 Jahren nicht produktiv benutzt oder benötigt habe.

    Das Problem existiert ja unabhängig von PIP oder dem fehlendem Patch. In meiner Umgebung habe ich den Patch wieder reingenommen, um Fehler auszuschliessen.

    Mein Primärziel war/ist eine reine VDR Box. Kodi habe ich auf den anderen Clients seit Jahren nicht mehr gestartet und weiß auch gar nicht, welche Version überhaupt installiert ist. Andere im Haushalt wissen nicht mal, was Kodi ist. Nun will ich es aber auch zum Laufen bekommen.

    echo 420,10bit > /sys/class/amhdmitx/amhdmitx0/attr
    echo 2160p50 > /sys/class/display/mode


    Ich habe nur HD Devices. Im README zu softhdodroid steht was von UHD und die Daten sehen auch danach aus. Wie sehen denn die Werte für HD aus?


    Laden/Entladen von Kernel Modulen habe ich bisher nicht erfolgreich durchführen können. Teilweise bekomme ich schon beim Laden den Stacktrace. Ich versuche noch herauszufinden, ob es noch Abhängigkeiten vom kodi unit gibt, die irgendwas sinnvolles machen. Ich kann mir irgendwie nicht vorstellen, daß es an Kodi liegt, das ja auf sehr unterschiedlichen Systemen läuft.

    unloade mal beim umschalten das amlvideodri Modul und lade es neu.


    Evtl. müssen alle videomodule entladen und neu geladen werden.

    Das ist eine gute Idee. Das amlvideodri scheint zum Start von VDR nicht benötigt zu werden.


    Also boot mit VDR, Stop VDR und dann:

    1. rmmod amlvideodri -> Kodi Video Player startet gar nicht mehr

    2. modprobe amlvideodri -> Kodi Video Player startet, allerdings nur Sound und kein Bild

    3. rmmod ...; modprobe amlvideodri videobuf_res videobuf_core videodev -> Crash


    Ich probiere noch ein wenig weiter. Vielleicht finde ich die richtige Reihenfolge und die richtigen Module.

    Ausgegeben wird nur die LCN, die der VDR im cChannel sammelt. Ob es nationale Unterschiede gibt, wie und woher der Wert kommt, kann ich gar nicht sagen.

    Aber die Nummer ist schon bei demselben Provider (Vodafone) insgesamt nicht eindeutig. Es sieht so aus, als ob Radio und TV jeweils bei 1 beginnt.


    Der Code zum sammeln befindet sich in nit.c unter

    case SI::LogicalChannelDescriptorTag

    und

    case SI::HdSimulcastLogicalChannelDescriptorTag

    Ja. Ich habe einige Tests gemacht und dabei war es egal, ob mit oder ohne Patch. Ob es die stabile 19.4 Matrix oder die aktuelle Version aus dem 19er Branch war.

    Es passiert ja auch nur, wenn man initial mit VDR startet. Mit Kodi und dem Wechsel auf VDR und zurück zu Kodi gibt es auch keine Probleme.

    Mein Kabelnetzbetreiber hat wieder einen Change Day angekündigt und jedesmal die Kanalsortierung inkl. channel_map von epgd zu korrigieren ist nervig. Mit ein paar Scripten bekommt man das relativ gut hin, aber diesmal dachte ich, ich versuche es mal mit der LCN. Mal schauen, ob die wirklich so konstant sind.


    Der Patch erweitert das SVDRP Kommando LSTC um den Parameter ":lcn", damit die LCN auch mit ausgegeben werden kann.

    Damit das überhaupt funktioniert muss im Setup DVB/Standardkonformität auf NORDIG gestellt werden.

    Files

    • svdrp.c.patch

      (5.89 kB, downloaded 14 times, last: )

    Mir ein ein ganz anderes Problem mit dem Wechsel VDR <-> Kodi aufgefallen.

    Es gibt verschiedene Varianten, welche Programm nach dem Boot starten soll: VDR oder Kodi.


    Jetzt habe ich folgendes Problem:


    1. Start mit VDR, Wechsel nach Kodi. Ansehen eines Videos aus der Mediathek -> Kernel Crash

    2. Start mit Kodi, Wechsel nach VDR und wieder nach Kodi. Ansehen eines Videos aus der Mediathek -> Funktioniert


    Dabei ist es egal, ob 19.4, 19er Branch mit oder ohne den Decoder Kernel Patch. Das Verhalten ist identisch.

    Das deutet darauf hin, daß irgendeine Initialisierung durch softhdodroid anders läuft, als bei Kodi.

    Es ist nur schwierig, das ganze irgendwie einzugrenzen. Und eine echte Lösung fällt mir auch nicht ein: Erst Kodi starten, killen und dann den VDR? Pragmatische Lösungen sind gut, aber das ist selbst mir zu schräg.

    Ich bin mir nicht mehr sicher, was stimmt. Funktioniert Kodi, funktioniert es nicht? Oder funktionieren nur bestimmte Addons unter bestimmten Bedingungen nicht? Bei einer reinen VDR Maschine wäre das ja egal.


    Was nun? Patch rein, Patch raus? Beim Build entscheiden, ob mit oder ohne?

    Mir fehlt dazu die Erfahrung mit Kodi und mögliche Probleme.

    Manche Skindesigner skins liefern eigene fonts mit, jedoch habe ich noch nicht herausgefunden, wo ich diese fonts ablegen müsste kann mir hier jemand unterstützen?

    Da sprichst du was an. Fonts in /storage/.fonts sollten theoretisch funktionieren, fc-list zeigt diese auch an. Und es hat tatsächlich mal funktioniert, aber sie werden aus irgendwelchen Gründen von VDR nicht mehr gefunden/gelesen und ich habe nicht herausgefunden, warum. Die Fonts, die ich gefunden habe, installiere ich mittlerweile im Image selbst. Dazu habe ich fontconfig noch ein eigenes Font-Verzeichnis hinzugefügt. Die Fonts, die ich in das Image einbinde, findest du im Repository Fonts.


    Ich denke, ich könnte genauso noch ein weiteres Verzeichnis irgendwo in storage hinzufügen. /storage/.config/vdropt/fonts? Oder was anderes oder doch hart /storage/.fonts? Also irgendwas, in dem man neue Fonts für VDR/Skins hinzufügen kann, falls gewünscht.

    Wenn wir also mit dem softhdodroid weiter machen wollen dann müssen wir bei Coreelec bleiben

    Ich habe nicht vor zu wechseln. Die Box (inkl. Ausgabe) macht was sie soll und das gut :)

    Ich frage mich wie das bei einer Mali-450 GPU aussieht. Und könnte man das durch eine Mesa Version ersetzten die dann auch die Mali 450 mit GL/ES 3.0 versorgt.

    Das war viel weiter oben. libMali.m450.so oder ähnlich. Wenn es gelingt, Mesa zu kompilieren oder eine Version zu finden, die funktioniert, könnte man beim Start des VDR den Link in /var/lib auf etwas anderes umbiegen.


    Ich habe bei meiner Distribution VDR-Distribution für CoreELEC als Kodi addons

    es vermieden Erweiterungen direkt im CE git zu committen.

    Genau das hatte ich auch überlegt, aber dann war der Komfort bei der Entwicklung wichtiger. VDR/Plugins als Addon können binär über ein Repository angeboten werden. Mittlerweile nutze ich persönlich nur noch die kompletten Image Updates. Das geht schnell und bequem.

    Ich habe bisher nie PIP verwendet, aber so langsam könnte ich mich daran gewöhnen und das geht dann nur mit dem passendem Kernel.

    Danke. Jetzt ist der Unterschied CoreELEC/LibreELEC endlich klar geworden. Ich hatte mich schon über die verschiedenen Kernel gewundert.


    Ich habe mal ein Diff zwischen meiner Version und dem Original CE gemacht. Auch aus reiner Neugier, weil ich wissen wollte, wo ich überall rumgepfuscht habe. Wenn ich mal alle vdr-Verzeichnisse (packages/vdr, virtual/vdr-all) weg lasse, dann ist das Diff recht übersichtlich:

    - rust und rustup wurde auf eine höhere Version gezogen (für librsvg -> skindesigner)

    - image/package.mk hat Referenzen auf VDR (klar)

    - In opengl-meson werden zusätzlich die GLESv3 Header kopiert

    - In amlogic/media_modules-aml wurde der Patch gelöscht, der die Anzahl der Decoder beschränkt

    - In fontconfig habe ich ein zusätzliches Font-Verzeichnis aufgenommen


    Also eigentlich sind meine Änderungen sehr übersichtlich und sollten sich einfach nach LibreELEC übernehmen lassen.



    CoreELEC-Original-Zabrimus.diff

    Ich fragte nur, weil ich https://wiki.libreelec.tv/hardware/amlogic gesehen habe, und mir der code so aussieht, als würde libreelec auf den Kistchen laufen.

    Dann muss es jemand versuchen. Meine Änderungen sind von CoreELEC weitgehend isoliert (eigene Packages, eigenes virtual package), so daß ich durchaus denke, das LE funktionieren könnte. Zumal zwischen LE und CE ein reger Austausch stattzufinden scheint.