[geloest] Timeshift Problem mit 1.7.x

  • Hi,


    ich mach mal n Thread nur fuer das Problem hier auf:
    Bei zentoo auf der SMT friert VDR haeuffig bei Timeshift ein,
    zuerst dachte ich das waere eine xineliboutput Problem,
    aber seitdem ich gdb und strace auf der Box am laufen hab, sieht
    es anders aus.


    Auszuloesen ist das Verhalten einfach. Timeshift starten auf USB, z.B.
    und ein Paar mal Pause druecken.
    Ploetzlich haengt die Box, Standbild keine Menues .....
    SVDRP ist auch weg (seltsam)


    strace vom VDR:


    Es sieht so aus als ob sich da ein, oder mehrere locks ueberschneiden.


    gdb log


    Hat jemand so etwas schon mal gehabt ?


    Gruesse,


    Giga

  • Ich hab den Bug bis in die dvbplayer.c verfolgt, ich verstehe das Problem
    noch nicht ganz, aber es sieht so aus.


    Irgendwann liest der reader thread ein Paket vom File, und wird es nicht
    los, scheinbar, weil der Player thread noch nicht wieder laeuft, oder
    weil das Paket keine gueltigen Daten enthaelt.
    Danach loopt der thread und gibt auch keine Daten mehr weiter.


    Eine Loesung ist es die Daten in dem Fall zu verwerfen, das gibt
    einen kurzen Fehler im Bild, aber der thread blockt nicht mehr.


    Giga

  • Ich hab den Bug gefunden:


    Bei sehr langsamen Medien kann ein Request haengen, was zu einem
    Race zwischen dem Reader und dem Player fuehrt. dabei kann
    es sowohl zu einem Haenger, wie zu einem Leak kommen:


    Patch:


    Gruesse,


    Giga

  • Ich hab den Bug gefunden:


    Bei sehr langsamen Medien kann ein Request haengen, was zu einem
    Race zwischen dem Reader und dem Player fuehrt. dabei kann
    es sowohl zu einem Haenger, wie zu einem Leak kommen:


    Zu deinem Patch habe ich ein paar Fragen...


    Zitat
    Code
    1. @@ -117,14 +119,21 @@
    2. {
    3. newSet.Signal();
    4. Cancel(3);
    5. - free(buffer);
    6. + if (result)
    7. + free(result);
    8. + if (buffer)
    9. + free(buffer);
    10. }


    Hat das einen bestimmten Grund, 'result' und 'buffer' hier abzufragen? 'free()' ist doch "NULL-proof".


    Zitat


    Die letzten 4 Zeilen haben doch unmittelbar vorher durch den Clear()-Aufruf bereits stattgefunden - oder übersehe ich da was?


    Magst du bitte mal schauen, ob folgende überarbeitete Version deines Patches immer noch wie erwartet funktioniert?



    Falls du in HISTORY/CONTRIBUTORS genannt werden willst, schick mir bitte deinen vollen Namen und deine Email-Adresse.


    Klaus

  • Ich hab den Bug gefunden:


    Bei sehr langsamen Medien kann ein Request haengen, was zu einem
    Race zwischen dem Reader und dem Player fuehrt. dabei kann
    es sowohl zu einem Haenger, wie zu einem Leak kommen:
    ...


    Auf der VDR-ML gab es eine Meldung, daß diese Änderung Probleme mit vdr-xine macht (siehe http://linuxtv.org/pipermail/vdr/2012-February/025783.html). Ich tendiere daher dazu, diese Änderung wieder Rückgängig zu machen.
    Gibt es dagegen Einwände? Oder einen Fix für das vdr-xine Problem?


    Klaus


    EDIT: war ein "quote" zuviel...

  • Wäre schade wenn das wieder zurückgenommen würde - auf ein stabiles Pausieren hatte ich mich schon gefreut.


    Das Pausieren funktioniert in der 1.7.24 unabhängig von dieser Änderung jetzt ordentlich. Sowohl für SD als auch HD. Und es wird auch nicht mehr der Bildschirm mehrere Sekunden schwarz.
    Probier's einfach mal aus ;-)


    Zitat

    Fix für xine kenne ich leider nicht. Was sagt rnissl dazu ?


    Das eigentliche Problem, das der Patch in diesem Thread fixen soll, konnte ich selber nicht nachvollziehen. Da mir die Änderung aber durchaus plausibel erschien, habe ich sie übernommen. Wenn die nun aber mehr Probleme erzeugt als sie löst, muß ich sie leider wieder entfernen.


    Klaus

  • Pausieren scheint jetzt zum ersten Mal seit SD-FF-Zeiten wieder zu funktionieren (zumindest mit softhddev und xineliboutput), auch ohne obige Korrektur. Was ist denn jetzt wirklich dafür verantwortlich?

    vdr-2.3.8
    softhddevice, chanman, dbus2vdr, dvd, dvdswitch, dynamite, epgsearch, femon, filebrowser, graphlcd, graphtftng,
    menuorg, osdteletext, radio, recsearch, streamdev-server, tvguide, vdrmanager, vnsiserver

    linux-3.13.0-123 M3N78-VM (Nvidia 8200) CIne CT-V7 DVB-C
    yavdr-0.6 als Basis mit vielen Änderungen

  • Ich hab jetzt geschaut: wesentlich ist der Teil mit INDEXFILETESTINTERVAL in recording.c, der neu reingekommen ist.

    vdr-2.3.8
    softhddevice, chanman, dbus2vdr, dvd, dvdswitch, dynamite, epgsearch, femon, filebrowser, graphlcd, graphtftng,
    menuorg, osdteletext, radio, recsearch, streamdev-server, tvguide, vdrmanager, vnsiserver

    linux-3.13.0-123 M3N78-VM (Nvidia 8200) CIne CT-V7 DVB-C
    yavdr-0.6 als Basis mit vielen Änderungen

  • Ich hab jetzt geschaut: wesentlich ist der Teil mit INDEXFILETESTINTERVAL in recording.c, der neu reingekommen ist.


    Früher wurde eine Aufnahme gestartet, dann wurde einige Sekunden gewartet, dann die Wiedergabe gestartet, wieder einige Sekunden gewartet und schließlich der "Pause"-Befehl geschickt.
    Das stand naturgemäß auf recht tönernen Füßen, denn wenn sich der erwartete Zustand nicht innerhalb der vorgegebenen Zeit eingestellt hat, ging es eben schief.


    Ab Version 1.7.24 wird jetzt die Aufnahme und auch gleich die Wiedergabe gestartet. Die Wiedergabe wartet, bis in der Index-Datei mindestens zwei Einträge drin sind und macht dann ein "Goto" zum ersten Frame mit dortigem Standbild. Das läuft anscheinend recht zuverlässig und dauert nur genau so lange, wie es eben braucht. Kein längerer schwarzer Bildschirm mehr und auch keine abgebrochene Wiedergabe, weil die Aufnahme noch nicht so weit ist.


    Klaus

  • Mal eine Frage "am Rande": Ist denn Timeshift mit der VDR-Server-Client-Lösung (hier) auch am Client möglich?

    VDR-Server: Gentoo (AMD64/Core-i7) / VDR-1.7.23 / Digital Devices Octopus CI & 2xDuoFlex S2 HDTV (Rev. V3)
    VDR-Client: Gentoo (AMD64/Atom-D525) / VDR-1.7.23 / Chieftech & iMON-Pad / ASUSTeK - AT5IONT-I / 4GB-RAM & 65GB-SSD
    Alt: 3xTT-1.5 / linuxtv-dvb-1.1.1 + test_av-1.28 + FW-2622 / vdr-1.3.37 / viele Plugins / LFS-4.1