1.2.1 - animations reloaded

  • Moin Louis,


    Hast du denn die "komischen Effekte" (dass das aktive Listenelement nicht gelöscht wird) auch, wenn du eine "vernünftige" listfadetime oder listshifttime (z.b. 100ms) benutzt?


    Ja habe ich. Das war ja der Grund, mit den Werten ein bisschen zu probieren...
    listshifttime ist dabei der eigentliche Verursacher - mit 50 FPS, listshifttime = 0 und listfadetime = 100 geht es.


    Der VDR schmiert auch mit 10 FPS und listshifttime = 50 und listfadetime = 0 ab.


    So richtig fluffig läuft es auf ION oder Raspberry eigentlich nur mit 0 0 (womit ich aber auch gut leben kann ;) ).


    Grüsse

  • Der VDR schmiert auch mit 10 FPS und listshifttime = 50 und listfadetime = 0 ab.


    Jo ich schau mir das nochmal an...wie gesagt da muss eh noch ne Prüfung rein.


    Ciao Louis

  • Nachdem ich die skindesigner Dateien/Ordner komplett getauscht und die Einträge in der setup.conf des skindesigners gelöscht habe, funktioniert das jetzt wie vorgesehen.... schon mal gut 8)


    Spielen da die Patches von jrie mit rein? Anscheinend schon...ich bin eher davon ausgegangen, dass die Patches das Wiedergabeverhalten verbessern sollen? Wenn die Patches da was bewirken, sollte der Crash ja auch mit dem softhddevice aus dem offiziellen Git ohne OpenGL Osd auftreten? Ist dem so?

    Soweit ich das noch im Kopf habe, waren in meinem funktionierenden Compilat (abgesehen von dem Tonversatz) sowohl Patche von jrie bezüglich Wiedergabe, als auch einer bezogen auf die Deadlocks (device.c.4.diff) drin. Ich muss das nochmal genauer eruieren.


    Die ungepatchte GIT-Version von softhddevice-openglosd geht bei mir jedenfalls nicht. Die knallt schon bei wildem Rumgezappe unter eastuary weg. Kann eventuell auch an meiner nicht aktuellen ffmpeg-Version liegen.

  • Hi inob,

    Soweit ich das noch im Kopf habe, waren in meinem funktionierenden Compilat (abgesehen von dem Tonversatz) sowohl Patche von jrie bezüglich Wiedergabe, als auch einer bezogen auf die Deadlocks (device.c.4.diff) drin. Ich muss das nochmal genauer eruieren.


    Die ungepatchte GIT-Version von softhddevice-openglosd geht bei mir jedenfalls nicht. Die knallt schon bei wildem Rumgezappe unter eastuary weg. Kann eventuell auch an meiner nicht aktuellen ffmpeg-Version liegen.


    interessant...die Patches in der device.c sind ja eigentlich komplett unabhängig vom shd. Dann scheinen aber die Patches für das shd die anderen patches irgendwie zu beeinflussen. Wäre interessant, wie sich das ganze mit dem "normalen" shd aus dem offiziellen Git verhält...


    Ciao Louis

  • Moin,


    im Git ist eine Version 1.2.1, die die mit den Neuerungen aufgetretenen Problemchen fixen sollte.Zusätzlich kann man sich nun im schmalen Aufzeichnungsmenü im extuary4vdr wie von Perlbo vorgeschlagen optional die Poster Thumbnails mit anzeigen lassen.


    Saman: den von dir auf den Screenshots beschriebenen Bug, dass beim aktivierten Shiften in den Menülisten das aktive Element nicht mehr gelöscht wird, habe ich irgendwie absolut nicht nachvollziehen können. Nur zur Sicherheit: du verwendest den metrixhd schon so wie im Git ausgeliefert? Nicht dass du da irgendeine Version von dir drüber gebügelt hast. Falls es mit der Version 1.2.1 immer noch passiert, müssten wir mal zusammen schauen, wie wir das am besten debuggen können.


    Ciao Louis

  • Moin Louis,


    danke für die neue Version.
    Läuft stabil.


    Der angehängte Screenshot ist mit frisch installiertem Plugin und deinem metrixHD aufgenommen worden.
    Einstellungen sind 50 FPS und listshifttime = 100 und listfadetime = 100 auf dem RPi3.
    Eventuell sind ION und RPi da auch einfach nur am Limit.
    Nun habe ich aber auch bemerkt, das das mit estuary4vdr nicht auftritt? Ich schau mal ob ich da Unterschiede finde.


    Grüsse


    EDIT: OK - warum das beim estuary4vdr nicht so ist, weiss ich jetzt :)


    Du hast beim metrixHD die 'listelement' in displaychannel.xml jeweils um fadetime="{listfadetime}" und shifttime="{listshifttime}" ergänzt.
    Beim estuary4vdr gibt sowas nicht. Wenn ich das im metrixHD wieder rausnehme läuft es bei beiden gleich.

    Bilder

    2 Mal editiert, zuletzt von Saman ()

  • Saman: eigentlich sollte nur einer der beiden Werte != 0 sein. Entweder shifthen oder faden...hast du dann den Effekt immer noch?


    Ciao Louis

  • Leider ja, auch mit FPS = 25, listfadetime = 100 und listshifttime = 0
    aber nur in den Listen in displaychannel.xml.

  • Leider ja, auch mit FPS = 25, listfadetime = 100 und listshifttime = 0
    aber nur in den Listen in displaychannel.xml.


    Sehr seltsam...an der Geschwindigkeit deiner Systeme kann es eigentlich nicht liegen. AKtuell habe ich da keine Idee, da müsste man mal ein bisschen Debug Code einbauen, um zu erkennen was da schief läuft.


    Ciao Louis

  • Mit der aktuellen GIT-Version habe ich nach wie vor das Problem, dass der scrollende Programm-Info-Text unter dem skalierten TV Bild in der Programmübersicht ab und zu flackert. Eine Systematik, wann das auftritt, läßt sich nicht erkennen. Am Anfang hatte ich vermutet, dass es bei 1080i Sendern passiert, was aber nicht der Fall ist.


    Außerdem kommt es reproduzierbar zu segfaults, wenn ich im Aufnahmemenü eine Aufzeichnung lösche und zwar just zu dem Moment, wenn sich das Bild (Anzeige) aktualisiert. Steht dann irgendwas mit "skindesigner animator..... bla... segfault" im log. Hängt eventuell mit dem extrecmenu zusammen, welches ich Zwecks "Abwärtssortierung" noch verwenden muss. Allerdings hat das mit der Vorgängerversion von skindesigner und eastuary problemlos geklappt.

  • Außerdem kommt es reproduzierbar zu segfaults, wenn ich im Aufnahmemenü eine Aufzeichnung lösche und zwar just zu dem Moment, wenn sich das Bild (Anzeige) aktualisiert. Steht dann irgendwas mit "skindesigner animator..... bla... segfault" im log. Hängt eventuell mit dem extrecmenu zusammen, welches ich Zwecks "Abwärtssortierung" noch verwenden muss. Allerdings hat das mit der Vorgängerversion von skindesigner und eastuary problemlos geklappt.

    Die Segfaults kann ich bestätigen.
    Aber, sie treten bei der Version 1.1.7 auch schon auf und nur wenn man das extrecmenu-Plugin verwendet und den extuary4vdr-Skin. Metrix funktioniert ohne Probleme.

    SAT Hardware: Gibertini SE75 | DuraSat Dur-Line UK-24 | DD OctopusNET V2 Rack (Firmware 1.1.6) mit MaxS8
    Server: Asus M5A78L-M/USB3 | Sempron 145@2Cores | 8GB ECC RAM | PicoPSU | Debian Stretch 64Bit | VDR 2.4.5 mit SAT>IP, epgsearch, live, markad
    Clients: RaspberryPI 2/3 | Yocto Poky Linux (Openembedded) 3.2+git | Linux Kernel 5.4.72 | VDR 2.4.5 mit SAT>IP, RpiHDDevice, SkinDesigner, Remote, Extrecmenu, Femon, Mlist


    R.I.P: Gigaset M740 mit VDR von open7x0.org

  • Die Segfaults kann ich bestätigen.
    Aber, sie treten bei der Version 1.1.7 auch schon auf und nur wenn man das extrecmenu-Plugin verwendet und den extuary4vdr-Skin. Metrix funktioniert ohne Probleme.


    Hm, gut zu wissen...macht es noch einen Unterschied, ob das breite oder das schmale Aufzeichnungsmenü im estuary4vdr verwendet wird?


    Wenn ihr beide die Segfaults so schön reproduzieren könnt, dann könnt ihr doch sicherlich auch einen Backtrace vom Crash erstellen. Dann kann ich es mir ggf. sparen, das tolle extrecmenu zu installieren ;)


    Ciao Louis

  • Wenn ihr beide die Segfaults so schön reproduzieren könnt


    Dazu brauchts nur eine Änderung der Einstellungen, speziell der Ein-/Ausblendzeiten. Speichern mit OK und weg isser. Wohlgemerkt, alles was mit skindesigner kommt, komplett neu installiert, inkl. Löschung der alten skindesigner Einträge in der setup.conf.


    Muss ich den VDR halt doch mal mit Debug übersetzen.

  • Moin,

    Dazu brauchts nur eine Änderung der Einstellungen, speziell der Ein-/Ausblendzeiten. Speichern mit OK und weg isser. Wohlgemerkt, alles was mit skindesigner kommt, komplett neu installiert, inkl. Löschung der alten skindesigner Einträge in der setup.conf.


    Wie jetzt? Das klingt aber jetzt nach Setup menü?! Ich dachte du redest über das Aufzeichnungsmenü? Oder war das mit den Ein-/Ausblendzeiten ein Freudscher Vertipper und du meinst Start- bzw- Stoppzeiten von Aufnahmen? ;)


    Muss ich den VDR halt doch mal mit Debug übersetzen.


    Wäre schon schön, ich brauch das extrecmenu Plugin ja nicht ;)


    Ciao Louis

  • Einen segfault kann ich auf die beiden oben beschriebenen Verfahren auslösen.

  • Moin,


    Einen segfault kann ich auf die beiden oben beschriebenen Verfahren auslösen.


    hmmm...ich habe eben sogar mal das extrecmenu Plugin installiert...selbst da kann ich keinen Crash provozieren, wenn ich eine Aufnahme lösche?! Dass es im Setup Menü crasht ist mir völlig neu, ich denke, du kannst dir vorstellen, wie oft ich das schon bedient habe :D


    Hilft nix, ich brauch backtraces ;)


    Ciao Louis

  • Erster Versuch (softhddevice-openglosd+skindesigner+estuary4vdr): segfault beim Schneiden einer Aufnahme, die bereits geschnitten vorliegt. Anders gehts auch, z.B. Schneiden + Verschieben, aber so gehts am schnellsten. Reicht der Auszug so?


    Dateien

  • Moin,


    ja der Backtrace passt so...ich denke, anhand des Backtraces sehe ich auch den Grund für den Crash. Seltamerweise sind bei dir parallel zwei "Animationsthreads" am laufen, das darf eigentlich nicht sein. In den Änderungen zur Version 1.2. war genau das mein Ziel, dass alle Animationen, die parallel laufen (scrollen, faden, shiften, blinken) über einen gemeinsamen Thread behandelt werden, der dann auch für alle Animationen gemeinsam ein "Flush" pro Frame macht. Ich denke, da spielt das extrecmenu mit rein, dass da irgendwas komisch aufgerufen wird.


    War es beim extrecmenu nicht so, dass bei einem laufenden Schnitt dauern das OSD geflusht wird? Damit gab es früher mal Probleme, dass das OSD dann geflackert hat. Gab es da nicht einen Würgaround für? Irgendeine Setup Option? Am besten wäre es wohl, wenn du mal alle deine Setup Optionen für das extrecmenu posten könntest, dann kann ich die bei mir fürs debugging so übernehmen.


    Du schreibst jetzt, dass der Crash bei laufendem Schnitt des öfteren auftritt. D.h. also, dass du die Crashes nicht so wirklich reproduzieren kannst und sie ab und an mal auftreten? Ich hatte dich ursprünglich so verstanden, dass beim Löschen einer Aufnahme der VDR reproduzierbar crasht. Deshalb habe ich testweise auch nur mal zwei drei Aufnahmen per extrecmenu gelöscht, dabei ist bei mir aber kein Crash aufgetreten. Das ist eine wichtige Info für mich...tritt der Crash reproduzierbar immer bei der gleichen Aktion auf, dann ist der Fehler i.d.r bei einem Zugriff auf einen nicht initialisierten Pointer zu suchen. Tritt der Crash allerdings "sporadisch" auf (wobei die Häufung hierbei egal ist), dann handelt es sich eher um eine Race Condition beim multithreading.


    Deshalb die Frage, damit ich das Problem bei mir reproduzieren und debuggen kann: wie oft tritt das auf?


    Ciao Louis

  • Zitat

    War es beim extrecmenu nicht so, dass bei einem laufenden Schnitt dauern das OSD geflusht wird?


    Da war mal was, aber genau dran entsinnen kann ich mich auch nicht mehr.


    Wobei das Wegfliegen nicht nur während des Schneidens auftritt sondern auch, wenn man lediglich Aufnahmen in Unterordner verschiebt oder löscht. Da aber nicht immer und nicht zuverlässig reproduzierbar.


    Was immer zu 100% zu einem segfault führt ist, eine Originalaufnahme versehen mit Schnittmarken zu schneiden und nach Abschluss die Originalaufnahme nochmals zu schneiden, ohne die geschnittene Version vorher zu löschen. Er fragt dann ja, ob er die bereits geschnittene Version überschreiben soll was man mit OK bestätigt und kurz drauf fliegt er weg.


    setup.conf von extrecmenu

  • iNOB: alles klar, danke für die Infos. Dann werde ich bei Gelegenheit mal schauen, ob ich das in den Griff bekomme ;)


    Ciao Louis

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!