Beiträge von jojo61

    Ich muss nochmal auf das Thema Pause beim streamen kommen. Wenn ich einen Stream pausiere und nach ein paar Sekunden weiterlaufen lasse dann ist alles in Ordnung.

    Wenn ich den Stream aber länger anhalte (ca. grösser 1 Minute) dann läuft er danach zwar wieder an, aber er stottert und manchmal bricht er dann auch nach ein paar Sekunden ganz ab.

    Das stottern kann man durch vor oder zurückspulen nicht beheben. Nur ein komplettes abbrechen über Menü und neu starten funktioniert.


    Das ist leider ein Showstopper für das ganze web plugin. Ohne die Möglichkeit einen Stream anzuhalten macht es wenig Sinn.


    Im Log des remotrans ist nichts auffälliges zu sehen. Da wird nach der Pause der ffmpeg wieder neu gestartet mit -ss auf aktuelle Position.

    Muss also irgendwo anders liegen das Problem.

    Ich habe alles versucht was ich reseten kann, aber nix hilft. Das Problem muss im vdr-plugin-mpv gelöst werden. Ich denke einThread indem das ganze libmpv handling stattfindet und der dann beendet wird könnte evtl. helfen. Damit dann auch wirklich alles abgeschlosen wird. Zum testen könnte sich ja auch das plugin mal beenden nach dem ersten streamen. Nur um zu sehen das es klappt.

    Der join sollte auf jeden Fall auf den exit des Thread warten.

    Ich habe nun mal auf meinem X96 eine deta/atta orgie veranstaltet und es hat immer geklappt. D.h. der pthread_cancel hat immer einen erfolgreichen cancel abgesetzt und der join hat erfolgreich auf den exit gewartet.


    Wie sieht das denn bei dir im Log aus wenn es nicht klappt.

    testcancel liefert leider nie einen return-Wert,

    Stimmt. testcancel kommt zurück wenn kein Cancel ansteht und es kommt nicht zurück wenn ein cancel ansteht und der thread ist beendet.

    Ich habe gelesen, dass man den Boot-Vorgang per Console (an Pin 10 Rx, 8 Tx, 38 VCC, 9 Gnd) debuggen kann. Frage: hat das schonmal jemand gemacht?

    Ja das geht und das habe ich schon gemacht. Wenn alles gebootet ist kommt man da auf eine shell.

    Schlechte Nachrichten. Nach weiterer Analyse sehe ich zwar das es am vsync liegen muss, aber ich kann nichts finden wie ich das reparieren kann.

    Ich habe mal im vdr-plugin-mpv nachgesehen ob er alles zu macht beim beenden des Streams und das sieht auch gut aus (soweit ich das beurteilen kann).

    Allerdings sagt das nichts darüber aus ob die libmpv auch intern alles zu macht beim beenden. Um das zu garantieren müsste man der ganze mpv wohl als Thread laufen lassen der sich dann tatsächlich mit exit beendet. Damit dann der Kernel auch aufräumen kann.


    Ich gebe erstmal auf ;(

    Nach einigen tests bin ich nun der Meinung das der mpv das vsync ausschaltet und auch nicht wieder einschaltet. Dann werden die Frames ohne sync aktualisiert und daher kommt dann das flackern. Nun muss ich nur noch rausfinden wie man es wieder einschaltet :)

    With the softhddevice there is no suspended/resume twice.

    Ja kann sein das das Problem bei mir liegt. Ich werde es mal untersuchen.

    Der Suspend für external Player ist ja auch etwas exotisch :)

    Was mich stört ist das der Suspend 2 mal kommt. Einmal vor dem start von mpv und noch einmal nach dem ende von mpv und nach dem Resume.


    Kann es sein das das mpv plugin bei der Meldung "Playlist not found" nochmal ein Suspend/Resume macht ?

    Ich konnte es nun mal testen und habe nach dem beenden des mpv ein flackern im Bild. Wenn ich mir das Log ansehe dann kommt der Resume wohl etwas zu früh und das mpv plugin ist noch nicht ganz fertig. Wenn ich einen sleep(2) in den Resume einbaue dann ist das flackern weg.

    Also testet mal indem ihr in der Datei softhddev.c in Zeile 3274 ein sleep(2); einbaut ob es dann geht.

    Ich habe mal versucht das hier nachzustellen. Da ich aber mit dem mpv plugin noch nie etwas gemacht habe, scheitere ich schon an den Parametern :) Auf meinem Intel PC läuft das Video nicht an und er sagt das er Audio nicht initialisieren kann.

    Ich starte mit -v gpu -h vaapi-copy -c x11 Ich denke da fehlt noch etwas. Könnt ihr da mal helfen .....

    pthread_setcancelstate(PTHREAD_CANCEL_ENABLE, NULL);

    pthread_testcancel();

    pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, NULL);

    Mit cancel_enable wird ein Cancel des Treads zugelassen und mit testcancel wird geprüft ob ein cancel ansteht. Wenn ja dann wird der Thread dort gecancelt und es gibt kein return. D.h. wenn er hier nicht durch kommt dann kann der Threaad nicht gecanceld werden weil er im Zustand cancel_disable für die eigentliche arbeit steht. Damit wird sichergestellt das er nur hier gecancelt werden kann. Dewegen wollte ich wissen ob er hier durchkommt (was er eigentlich mindestens einmal pro sekunde tun müsste). Wenn man die Zeile mit dem cancel_disable wegnimmt dann kann er wohl immer gecancelt werden egal wo er gerade im Ablauf ist.


    Ich hatte mit meinem Odroid getestet ob ein deta hängen bleibt. Konnte es aber nicht reproduzieren.