Posts by Dr. Seltsam

jojo61 wrote:

Du kannst ja mal mit dem Wert spielen und Feedback geben ob man es verbessern kann. Die -24000 von Hier

ich habe mit diversen Werten (-100000 bis + 100000) experimentiert, die Unterschiede sind aber minimal. Den Zustand, dass sofort nachdem das Schwarzbild beim Umschalten weg ist, das Bild mit synchronem Ton läuft, kriege ich nicht hin. Im besten Fall wird die Zeitspanne, bis das (zunächst immer erst mal anlaufende) Bild stehen bleibt und auf den Ton wartet, geringfügig kürzer.

Wie bist Du denn auf die -24000 gekommen? Durch Probieren oder hast Du die pts-Werte an der Stelle geloggt?

Hier

https://forum.odroid.com/viewtopic.php?p=139989&sid=580346fe6e2c750bebc775f3011989cf#p139989
behauptet jemand, man könne einfach die kompletten TS-Pakete an das device schicken, und es würde selbst für die Synchronisation sorgen.

nun wäre noch die Frage, ob jojo61 das zwar schnelle, aber unelegante Umschaltverhalten verbessern kann. Das neue Bild ist fast sofort da, läuft eine Sekunde, bleibt dann stehen und kurz danach geht es weiter. So war das Umschaltverhalten in den Anfängen einst bei softhddevice.

Ich habe mir heute einen Wolf gesucht und nochmal sys/class und sys/modules vor und nach der kodi-Wiedergabe abgeglichen, finde aber keine heiße Spur. Ich vermute, dass kodi irgendwie die Buffergrößen verändert oder die Art, wie Bild und Ton sich synchronisieren.

Es ist aber auch zu ärgerlich, dass es für die API keine Doku gibt und jeder Entwickler selbst experimentieren darf, welche Kommandos in welcher Reihenfolge angewandt welchen Effekt haben.

jojo61 wrote:

Also ich sehe hier bei mir keinen Unterschied ob ich dec_control auf 4 oder auf 0 setze. Wenn es bei euch hilft dann könnt ihr das ja in softoggle einbauen.

nein, das hilft weder gegen das Ruckeln bei Rückkehr zu vdr noch führt es dazu, dass vdr genauso schnell umschaltet, wenn man mit kodi zuvor noch keinen Film abgespielt hat. Hast Du für letzteres eine Erklärung?

Quote

Das das Bild beim zurückschalten von Kodi ruckelt und man erst mal umschalten muss, das habe ich hier auch. Die Ursache dafür habe ich bisher nicht gefunden.

Das einbauen des deinterlacers und korrigieren der PTS übergaben scheint nicht geholfen zu haben. Auch wenn es erst mal danach aussah.

Da ist dann wohl weiterhin das umschalten in softoggle nötig.

Dieses Problem besteht aber nur, wenn man kodi nicht nur geöffnet, sondern auch einen Film abgespielt hatte. Es tritt auch auf, wenn man einen Film aus der ARD-Mediathek abspielt - und das hatte ich am Mittwoch noch problemlos getestet, ohne dass vdr danach ruckelte. Ich werde mal ältere Revisionen testen.

beta : ja, das war die Lösung, die Du ursprünglich in Deinem HowTo schon beschrieben hattest. Aber der Stand war damals, dass es nach einer Änderung von jojo61 am Plugin nicht mehr notwendig war. Vielleicht eine Regression?

Der o.g. echo-Befehl müsste wenn dann übrigens mit 0 statt 4 ausgeführt werden, denn 0 ist der Wert im vdr-Betrieb, ehe kodi einen Film abgespielt hat. Die 4 kommt erst durch kodi.

Ich habe also in der softoggle vor dem attachen von softhdodroid einecho 0 > /sys/module/amvdec_h264/parameters/dec_control eingefügt, aber das verhindert das Ruckeln auch nicht.

ich hätte vielleicht schreiben sollen, dass ich gar nicht Dein image verwende sondern die chroot-Lösung von beta. Sorry.

Ich habe dort jetzt auch das Problem, das nach Rückkehr von kodi zu vdr dort das Bild ruckelt. Das fängt sich erst wieder beim nächsten Umschalten. Den obigen echo-Befehl habe ich im laufenden Betrieb schon ausprobiert, bringt nichts. Ich werde jetzt nochmal versuchen, den vor dem attachen von softhdodroid auszuführen.

Grundsätzlich wäre es vielleicht besser, wenn man beim Wechseln von vdr zu kodi doch den Playmode pmExtern_THIS_SHOULD_BE_AVOIDED verwendet. Und dann müsste jojo61 in softhdodroid bei Wechsel von diesem playmode zu einem anderen sämtliche Erstinitialisierungen, die es beim Start durchgeführt hat, nochmal an die Hardware schicken. (Es generell beim attachen durchzuführen macht m.E. keinen Sinn). Ich fürchte, das wird sonst auf Dauer die Suche nach der Nadel im Heuhaufen.

ich habe jetzt mal vor und nach dem Start von kodi+Filmwiedergabe die Ordner sysy/class... kopiert und dann ein diff gemacht. Ich weiss nicht, ob das weiterhilft. In beiden Situationen lief TV vom vdr, und natürlich sind diverse Werte naturgemäß dennoch anders.

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.

und in/sys/class/media-configs/vfm sowie /sys/class/vfm/map steht zusätzlich[06] default_amlvideo2 { vdin1(0) amlvideo2.1}

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.

irgendwie hat das das Umschalten rasant beschleunigt, aber auch etwas hakeliger genacht. Das neue Bild kommt jetzt fast sofort, stockt dann einen Moment (wohl wegen Synchronisation mit Audio) und läuft dann weiter.
Ich weiter nichts verändert außer heute den neuen Stand kompiliert + installiert.

Brauchst Du denn Deine ganzen Modifikationen? Ich würde einfach auf die aktuelle Version umstellen.

Das Problem in Deinem Script ist ansonsten der Abschnitt

Bash ist nicht gerade meine Stärke. Hier wird geprüft, ob die Datei /etc/default/rcS existiert, und wenn ja, wird daraus der Wert yes oder no ermittelt. Existiert die datei nicht (wie das bei Dir der Fall war), wird die Zuweisung

vorgenommen, die ich nicht so recht verstehe. Zumindest scheint das Ergebnis nicht das benötigte yes zu sein, und das war Dein Problem. Wahrscheinlich würde es reichen, den Block auf

abzuändern. Dann kannst Du die obsolete /etc/default/rcS löschen.

Das detachen des Ausgabedevices vor dem Ausschalten war zumindest damals notwendig, damit der Rechner nicht beim Runterfahren hängen bleibt und auf das Beenden eines Prozesses wartet. Kann sein, dass das heute nicht mehr nötig ist, schadet auf alle Fälle auch nicht. Ich habe gleich präventiv gleich beide Ausgabeplugins eingetragen, weil ich sie manchmal zum Testen wechsle.
Da ich alles selbst kompiliere, mache ich vieles einfacher und simpler als in den Debian-Paketen. Shutdown-hooks habe ich z.B. gar nicht.
Ich verwende zum Starten von vdr die ganz normale runvdr und habe die in den xfce Autostart gelegt. Man kann entweder direkt dort oder als Parameter in /etc/vdr/conf.d/vdr.conf den shutdown-Parameter ( -s) beim Starten von vdr vorgeben. Der verweist auf den shutdown-wrapper (ein ausführbares binary), das dann mein Script /usr/local/bin/vdrpoweroff.sh ausführt.

Dein Script heisst sicher anders und liegt auch woanders, aber Du scheinst es ja schon gefunden zu haben, wenn Du identifiziert hast, das darin /etc/default/rcS steht. (Ich vermute mal, das default im Pfad hattest Du nur vergessen). Wie genau heisst denn Dein Script und wo liegt es bei Dir? Die neueste Version dürfte die hier sein:

https://github.com/vdr-projects/vdr-addon-acpiwakeup

Da finde ich auf die Schnelle keinen Bezug auf /etc/default/rcS.

ich verwende seit Jahren ein ganz einfaches Script, auch unter Ubuntu 20.04.

Da mein vdr unter einem normalen user und nicht als root läuft, wird dieses aber nicht direkt mit der -s Option dem vdr beim Start übergeben, sondern über einen shutdown-wrapper.

Der Parameter --utc ist hier also fest gesetzt - es wird vorausgesetzt, dass im BIOS die UTC-Zeit gesetzt ist. Das ist m.E. eigentlich auch Standard bei einer Ubuntu-Installation. Die Datei /etc/default/rcS gibt es seit Ubuntu 17.04. nicht mehr.

Zabrimus wrote:

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.

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.

Aber da wird es wohl verschiedene Meinungen geben.

bei meiner Box funktioniert das: CoreElec startet, kodi ist maskiert und startet nicht, dafür vdr. Wechsel zu kodi über einen Eintrag in der commands.conf. ARD Mediathek addon gestartet, Film ausgesucht, abgespielt: eiwnandfrei. Film beendet, kodi verlassen -> vdr kommt zurück. Gleiches Spiel nochmal mit anderem Film aus der Mediathek - wieder kein Problem.

Meine Installation basiert fast vollständig auf dem HowTo von beta, d.h. der Wechsel von vdr in der chroot-Umgebung zu kodi geschieht durch Killen eines looper-Scriptes, das dann in CoreElec

• systemctl unmask kodi
• systemctl start kodi
• systemctl mask kodi

triggert.

Zabrimus wrote:

Ansehen eines Videos aus der Mediathek -> Kernel Crash

mit welchem Mediathek Addon hast Du getestet? Oder meinst Du die eigene Bibliothek?

Passiert das auch bei einem Kernel ohne Multidecode?

Schau mal im BIOS, ob Du dort ACPI-Funktionen findest, z.B.

ACPI Function -> Enabled, ACPI Standby State -> S1, Wake Up Event by -> OS

Ist aber je nach BIOS unterschiedlich benannt und kann unter Power Management oder auch woanders versteckt sein.

Im CoreElec-Forum sagen sie jetzt, dadurch würde kodi nicht mehr richtig funktionieren

o.k., Danke.

Ich habe jetzt mal im CoreElec-Forum nachgefragt, warum man dort multidecode wieder deaktiviert hat, obwohl es vor 2 Jahren ja einen fix gab, mit dem kodi auch mit aktiviertem multidecode lief. Jemand schreibt

Quote

Until it doesn’t anymore. When I do fast switching of TV channels with pvr iptvsimple addon playback stop working randomly. And this patch fixes this.

Maybe I should do another round of tests to see if the patch is still needed. But from what I know Kodi didn’t made any changes in this area so I would say patch is still needed.

Sind Dir im kodi-Betrieb irgendwelche Probleme aufgefallen? das iptvsimple-addon nutze ich nicht. Vielleicht liegt der Fehler ja auch in dessem Code.

weisst Du zufällig, in welcher Umgebung man das bauen muss? Ich meine gelesen zu haben, dass es Ubuntu 20.04 ist.
Meinst Du der Kernel ist mit der kleinen Änderung dann noch kompatibel zu den DVB-Treibern aus dem CE addon-Paket?

Zabrimus wrote:

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.

Kannst Du bitte mal in Video Treiber für Odroid-N2+ (softhdodroid) schauen? Ich brauche den passenden Kernel inkl. aktueller DVB-Treiber, möchte aber bei meiner Installation aus CoreElec mit Ubuntu-chroot bleiben.