[gelöst]Restart von vdr bei Schnitt, wenn "Platte beinahe voll!"

  • Hallo


    Ich habe hier ein eigentlich gravierendes Problem, dass mir schon längere Zeit unter den Nägeln brennt, das aber sonst niemand hier im Board zu haben scheint. Und nachdem es mir heute zum wiederholten mal passiert ist, als ich versehentlich die Lautstärke ändern wollte, nachdem der vdr schon ein 3/4 Stündchen mit Schneiden beschäftigt war (NFS ist halt nicht so schnell, aber dazu mehr später), hier also jetzt das Problem:


    Der vdr verabschiedet sich mit einem Segmentation Fault, wenn er, während die Meldung "Platte beinahe voll!" erscheint, schneidet. Aber nur dann, wenn man den vdr während des Schneidens normal weiterbenutzen will. Lässt man die Fernbedienung unangerührt, schneidet er in der Regel bis zum Ende fertig, unter der Voraussetzung, dass auch noch genügend Platz auf der Festplatte ist.
    Dieses Problem tritt erst seit der Version 1.3.x in Erscheinung, bei der Version 1.2.x kann ich mich an solch ein Verhalten nicht erinnern, obwohl das auch schon eine Weile her ist.
    Zum Reproduzieren des Fehlers verwende ich die aktuelle Vaniilla Version (1.3.37) zusammen mit dem dxr3-Plugin. Der selbe fehler tritt aber mindestens schon seit der Version 1.3.11 auf (das ist die erste 1.3.x Version, die ich verwende). Der Kernel unter dem vdr läuft ist 2.4.26. Das video Verzeichnis wird über NFS gemountet, root ist ebenfalls über NFS gemountet (diskless, siehe Signatur). Das einzige was Syslog mir vor dem Abgang gibt ist das:


    Wenn mir jemand sagt, wie ich dem vdr mehr entlocken kann oder auch wie man ein Backtrace erstellt, würde ich das gerne tun.


    Das ganze ist mir aber, soweit ich mich erinnern kann, auch schon mit einem MT gepanschten LinVDR mit FF Karte passiert, scheint also auch kein dxr3-spezifisches Problem zu sein. Ich habe das Problem schon einmal vor einem 3/4 Jahr in diesem Thread geschildert:


    http://www.vdrportal.de/board/…?postid=267948#post267948


    Aber irgendwie ist niemand auf das Problem eingegangen.
    Vielleicht ist das ganze ja auch nur ein Feature, dessen Sinn sich mir bis zum jetzigen Zeitpunkt einfach nicht erschliessen will.
    Bitte lasst mich nicht im Dunkeln.


    Gruss


    derschorsch

  • amair: Ich bin echt froh, dass ich nicht der einzige bin, dem das passiert.


    Ich habe übrigens nochmal versucht, das ganze unter LinVDR 0.7 mit dem MT20050518 Patch und dem Kernel 2.6.14 (siehe auch Signatur) nachzustellen und prompt ist es wieder passiert, ohne dass der VDR auch nur damit begonnen hätte, zu schneiden. Naja, das stimmt nicht ganz, es existiert das Schnittverzeichnis mit einer 001.vdr, die aber nur 30kb gross ist.
    Ich bin jetzt mal einfach so forsch und behaupte, dass dies ein bisher unentdeckter Bug von VDR ist, der nur nicht erkannt wird, weil die meisten ziemlich grosse Festplatten haben. Ich hingegen mit meinem notorischen Festplattenplatzmangel, habe ständig dieses Problem.


    Ich hab jetzt auch mal corefiles von der 1.3.37 Vanilla Version erstellt und backtraces gemacht. Dabei bin ich nach einer Anleitung aus dem Board vorgegangen. Ich hoffe ich habe alles richtig gemacht. Hier das Ergebnis von 2 Crashes:

    crash Nummer 2:

    Ist das ganze eher was für die mailingist, oder bin ich komplett auf dem Holzweg?


    Gruss


    derschorsch

  • Zitat

    Ich bin jetzt mal einfach so forsch und behaupte, dass dies ein bisher unentdeckter Bug von VDR ist, der nur nicht erkannt wird, weil die meisten ziemlich grosse Festplatten haben.


    OFF_TOPIC on


    Ich finde es ja schon geil, das VDR schon so weit ist, daß sich Leute freuen wenn sie mal einen "richtigen" Bug gefunden haben !


    OFF_TOPIC on

    VDR: DD 5.5 mit 4 Tunern , Intel 847 mit nvidia Kepler 630 , 4GB RAM , 1x 1TB , yavdr 0.5 X10 Fernbedienung von Pollin zu Steuerung, Diverse XBMC (openelec + Windows) im Haus als Clients

  • Hi,

    Zitat

    Original von derschorsch
    Ich bin jetzt mal einfach so forsch und behaupte, dass dies ein bisher unentdeckter Bug von VDR ist, der nur nicht erkannt wird, weil die meisten ziemlich grosse Festplatten haben. Ich hingegen mit meinem notorischen Festplattenplatzmangel, habe ständig dieses Problem.


    Hatte bis vor Kurzem auch des öfteren dieses Problem, jetzt habe ich eine größere Festplatte ;)



    Also ich würde mal Klaus informieren, da es im Vanilla VDR auftritt. Hast Du auch alle Plugins deaktiviert (hab' das was von einer DXR3 im Backtrace gelesen)?
    Tritt bei mir allerdings auch ohne DXR3-Plugin auf...


    Gruß,
    Andreas

  • mbruehl: Was heisst freuen. Ich bin sehr zufrieden mit meinem VDR und benutze ihn schon mindestens seit der 1.0.x. Nur das Problem habe ich nun mal schon so lange, habs auch schon mal vor über einem halben Jahr versucht anzusprechen, damals ist aber niemand drauf eingegangen. Deshalb hab ichs diesmal vielleicht ein bisschen "reisserischer" aufgemacht. Wenn das zu übertrieben ist, tuts mit leid.


    amair: Ich habe nur das dxr3-Plugin aktiviert, damit ich auch Schneiden kann. Aber wie gesagt, ich habs nochmal mit meiner MT gepanschten LinVDR Version mit FF Karte versucht und da ist es auch passiert.


    Gruss


    derschorsch

  • Zitat

    Wenn das zu übertrieben ist, tuts mit leid.


    Um Gottes willen, nein! Fehler müssen behoben werden !
    Es ist nur deine Ungläubigkeit "ich habe wirklich einen Fehler gefunden der in die Mailingliste gehört", die einen daran erinnert wie weit VDR schon ist.
    Ich habe noch keinen Fehler gefunden der nicht von mir selbst oder irgendwlchen Pantschereien verursacht worden ist. Ich durfte letzte Woche mit offiziellem Segen des WAF den Sat Receiver im Wohnzimmer abbauen. So stabil ist er.


    Frohes schaffen !!

    VDR: DD 5.5 mit 4 Tunern , Intel 847 mit nvidia Kepler 630 , 4GB RAM , 1x 1TB , yavdr 0.5 X10 Fernbedienung von Pollin zu Steuerung, Diverse XBMC (openelec + Windows) im Haus als Clients

    Einmal editiert, zuletzt von mbruehl ()

  • Zitat

    Original von amair
    Also ich würde mal Klaus informieren, da es im Vanilla VDR auftritt.


    Könnte jemand, der sich mit der Materie auskennt, den vermeintlichen Bug verifizieren? Ich will ja den Meister nicht unnötig belästigen und von wichtigerem abhalten, wenns nicht unbedingt nötig ist. Wie kann ich überhaupt Klaus informieren, über die email auf der VDR Homepage, oder muss ich mich mit meinem kläglichen Englisch in der mailinglist versuchen?


    Gruss


    derschorsch

  • Hallo,

    Zitat

    Original von derschorsch


    Könnte jemand, der sich mit der Materie auskennt, den vermeintlichen Bug verifizieren?


    Wie meinst Du verifizieren?
    Ich dachte, das hast Du schon gemacht. Vanilla VDR, Schneiden, Platte voll, Absturz. Coredump hast Du auch.


    Zitat

    Ich will ja den Meister nicht unnötig belästigen und von wichtigerem abhalten, wenns nicht unbedingt nötig ist. Wie kann ich überhaupt Klaus informieren, über die email auf der VDR Homepage, oder muss ich mich mit meinem kläglichen Englisch in der mailinglist versuchen?


    Gruss


    derschorsch


    Die E-Mail auf der VDR-Homepage wird wohl ankommen, es ist die gleiche wie in der Mailingliste. Als VDRPortal-User kls ist er auch erreichbar.


    Gruß,
    Andreas

  • amair
    Mit verifizieren meinte ich eigentlich nur, dass vielleicht ein paar mehr Leute bestätigen, dass es ein Bug ist. Ich möchte einfach ausschliessen, dass es ein Fehler in meiner Konfiguration ist. Damit möchte ich keineswegs Dein Urteilsvermögen und technisches Verständnis in Frage stellen (ich benutze übrigens deine VDRAdmin Version, coole Sache :] ). Da Du bis jetzt der einzige bist, der mir positivies Feedback gegeben hat, bin ich mir nur nicht sicher, ob es wirklich ein genereller Bug in VDR ist. Ansonsten scheint das Problem niemanden zu betreffen.


    Ich werd versuchen, mit meinen begrenzten Mitteln der Sache auf den Grund zu gehen. Kann ja auch nix schaden, sich mal ein bisschen mit der Materie auseinanderzusetzen. Mein Verdacht geht in die Richtung, dass der Cut Thread irgendwie von der Platzüberpfrüfung gestört wird, vielleicht hats auch was mit dem lock zu tun. An einem zu kleinen Wert für den Watchdog liegts auf jeden Fall nicht, ein getriggerter Watchdog beendet VDR ja auch schliesslich nicht mit einem Seg Fault, oder? Ich bin auf der Suche nach meinem Problem auf einen 2 Jahre alten Thread in der mailinglist gestossen, der auf einen zu kleinen Wert für den Watchdog hinwies.
    Ich seh das jetzt einfach mal als Herausforderung an und zudem eine Möglichkeit meine eingestaubten, rudimentären C++ - Kenntnisse aufzufrischen. Da es ja auch kein dringendes Problem zu sein scheint, hab ich ja auch genügend Zeit und wenn ich erfolgreich bin, um so besser. Vielleicht ziehe ich mir da aber auch einen zu grossen Schuh an.
    Ich meld mich an dieser Stelle dann wieder, wenn ich was in Erfahrung bringen konnte, oder wenn ich irgendwo auf ein Problem stossen sollte.


    Gruss


    derschorsch


    PS: Für alle Fälle hab ich schon was in englisch aufgesetzt für die mailinglist :rolleyes:

  • Da ich hier irgendwie nicht weiterkomme, aus oben beschriebenen Gründen, will ich hier mal meine gesammelten Erkenntnisse zusammenfassen.


    1. Ich konnte den Fehler nicht mehr reproduzieren, wenn ich einfach den Aufruf von:

    Code
    Interface->Confirm(tr("Low disk space!"), 30);

    in void AssertFreeDiskSpace(int Priority) in der recording.c auskommentiere. Damit wird sowohl bei einer Aufnahme als auch beim Schneiden nicht mehr angezeigt, wenn der Plattenplatz knapp wird, aber wenigstens läuft dann das Schneiden stabil.


    2. Ausserdem bleibt nach einem Absturz das .lock-vdr file erhalten. Um den Fehler erneut zu provozieren muss man es vorher löschen, da sonst der Schneidevorgang beginnt, ohne die "Platte beinahe voll!" Meldung zu bringen. Natürlich nur wenn man nicht so lange warten will, bis das lock file automatisch gelöscht wird (10 min glaub ich). Ich gehe daher davon aus, dass der Absturz nichts mit dem Lock Mechanismus zu tun hat.


    Viel mehr konnte ich nicht herausfinden.


    Daher hier jetzt ein paar Fragen.


    :deppenalarm


    Kann es sein, dass der Aufruf von Interface->Confirm (interface.c) aus der AssertFreeDiskSpace (recording.c) Funktion, die wiederum aus dem Cut Thread (cCuttingThread::Action) (cutter.c) aufgerufen wird und somit letztendlich ein Skins.Message (skins.c) bewirkt, irgendeinem anderen Aufruf von Skins.Message in die Quere kommt und damit den Segmentation Fault auslöst? Kann man sagen, dass AssertFreeDiskSpace threadsafe ist, wobei ich keine Ahnung habe, was das eigentlich heissen soll und in diesem Zusammenhang überhaupt von Bedeutung ist?


    Durch den Aufruf von AssertFreeDiskSpace und damit Skins.Message im Cut Thread wird ausserdem bewirkt, dass dieser anhält, entweder für 30 Sekunden, bis die Anzeige von selbst wieder verschwindet, oder bis eine Taste gedrückt wird. Welchen Sinn macht das genau, insbesondere weil AssertFreeDiskSpace(-1) bewirkt, dass dann 10 Sekunden nach der Anzeige schon die nächste erscheint und somit Intervalle von 10 Sek Schneiden 30 Sek Warten entstehen, die das Schneiden unnötig verlangsamen. Oder soll das dazu dienen, in den dreissig Sekunden die Festplatte aufzuräumen? Vielleicht ist das ja eines der oben erwähnten Features, die sich mir nicht erschliessen wollen.


    Gruss


    derschorsch (auf Erleuchtung hoffend)

  • IMHO darf nur aus nur aus dem Mainthread das OSD angesprochen werden,
    Für die blanke Ausgabe eine Message gabe es deshalb ab es auch in 1.3.37 folgende Änderung :

    Zitat

    - The new function Skins.QueueMessage() can be called from a background thread
    to queue a message for display. See VDR/skins.h for details.


    Kann aktuelle ebenfalls nicht testen, da ebenfalls zwei große Platten vorhanden sind...


    my 2 cent,
    Andreas

  • Zitat

    Original von Hulk
    IMHO darf nur aus nur aus dem Mainthread das OSD angesprochen werden,
    Für die blanke Ausgabe eine Message gabe es deshalb ab es auch in 1.3.37 folgende Änderung :


    Heisst das im Umkehrschluss, dass Skins.Message(), damit Interface->Confirm und somit auch AssertFreeDiskSpace nicht threadsafe ist?
    Das hiesse dann ja, dass man den Aufruf von Skins.Message in Interface->Confirm durch Skins.QueueMessage zu ersetzen hätte, was aber natürlich keinen Sinn macht, da damit alle Abfragen im OSD wie z.B. "Aufzeichnung löschen?" auch davon betroffen wären. Was auch deshalb keinen Sinn macht, weil QueueMessage die Meldung verzögert anzeigen würde, wenn ich das richtig verstanden habe, und somit nicht praktikabel ist.


    Zitat

    Kann aktuelle ebenfalls nicht testen, da ebenfalls zwei große Platten vorhanden sind...

    Schade ;(


    Gruss


    derschorsch

  • Zitat

    Original von derschorsch
    1. Ich konnte den Fehler nicht mehr reproduzieren, wenn ich einfach den Aufruf von:

    Code
    Interface->Confirm(tr("Low disk space!"), 30);

    in void AssertFreeDiskSpace(int Priority) in der recording.c auskommentiere. Damit wird sowohl bei einer Aufnahme als auch beim Schneiden nicht mehr angezeigt, wenn der Plattenplatz knapp wird, aber wenigstens läuft dann das Schneiden stabil.


    Sind auf der Maschine eine separate video-Partition und System-Partition vorhanden?
    Da Interface->Confirm versucht, ins Logfile zu schreiben, würde dies schief gehen, falls die Systemplatte
    voll läuft. (Nur so eine Idee...)


    CU
    Oliver

  • Zitat

    Original von UFO
    Sind auf der Maschine eine separate video-Partition und System-Partition vorhanden?
    Da Interface->Confirm versucht, ins Logfile zu schreiben, würde dies schief gehen, falls die Systemplatte
    voll läuft. (Nur so eine Idee...)


    video- und Systempartition sind auf verschiedenen Partitionen, auf beiden ist noch genügend Platz frei. Ich bekomme auch sonst alle syslog Einträge angezeigt.


    Ich hab aber jetzt einfach mal spasseshalber das

    Code
    Interface->Confirm(tr("Low disk space!"), 30);

    in AssertFreeDiskSpace() in recording.c durch

    Code
    Skins.QueueMessage(mtWarning, tr("Low disk space!"), 30);

    ersetzt.
    Bis jetzt konnte ich keinen Crash mehr provozieren. Ich werde aber mal weiter testen.


    Gruss


    derschorsch

  • Zitat

    Original von derschorsch

    Schade ;(


    Na dann habe ich mal meine Platten gefüllt ... (is allerdings eine fast vanilla 1.3.32) mit einigen Plugins, aber die Stelle ist nach deine Vergehensweise repoduzierbar.
    nur die Videopartition war voll, die Systempartition hatte noch genügend platz...
    Mainthread:

    Code
    (gdb) thread 1
    (gdb) bt
    #0  0x08110db4 in cSkinSTTNGDisplayMessage::Flush (this=0x8c95570)
        at skinsttng.c:1075
    #1  0x081051f8 in cSkins::Flush (this=0x81f73e4) at skins.c:207
    #2  0x080bb1ef in cInterface::GetKey (this=0x8c818c0, Wait=true)
        at interface.c:35
    #3  0x081275c4 in main (argc=29, argv=0xbffffaf4) at vdr.c:689
    Current language:  auto; currently c++


    Cutterthread

  • @Hulk
    Thanx :welle


    Ist das damit jetzt ein offiziell beglaubigter VDR Bug? Ich kann nämlich als absoluter Programmier- und Debug-DAU absolut nix mit den backtraces anfangen.
    Wie gesagt, ich schlag mich schon seit fast einem Jahr damit rum, weil ich eigentllich immer zu wenig Platz auf meiner Videopartition habe.


    Vielleicht kannst Du ja das ganze in der mailinglist publik machen. Ich kenn mich damit nämlich auch nicht aus.


    Gruss


    derschorsch

  • Zitat

    Original von derschorsch
    Vielleicht kannst Du ja das ganze in der mailinglist publik machen. Ich kenn mich damit nämlich auch nicht aus.


    Klaus sich für den Report und obrigen Fix bedankt

    Zitat

    You're absolutely right - calling Interface->Confirm() from a thread is a no-no.


    Könntest Du deinen Realname, am besten in der ML posten im Thread "Seqfault of cutting thread on "Low disk space!"" posten :


    Zitat

    But I take it that you have suggested this fix, right?
    If not, please tell the one who did to come forward so
    that he can be given credit in the VDR/CONTRIBUTORS
    file.


    Ich habe nur die losen Enden verbunden... :]
    Andreas


    EDIT :
    um der vdr -- VDR Mailing List beizutreten ...
    http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

  • @Hulk: danke fürs melden :]


    Da komm ich ja zu später Stunde noch zu grossen Ehren.


    Allerdings ist der Workaround oben nicht als Fix gedacht, da die Meldung 30 Sekunden lang ist und mit AssumeFreeDiskSpace mit Priority -1 alle 10 Sekunden angestossen wird und damit die MessageQueue mit "Platte beinahe voll!" voll läuft, wenn man nicht eingreift.


    Aber das kann ich ja dazuschreiben, wenn ich herausgefunden habe, wie man in die mailinglist postet.



    EDIT:

    Zitat

    um der vdr -- VDR Mailing List beizutreten ...
    http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

    Alles klar!


    Nochmal danke


    Gruss


    derschorsch

Jetzt mitmachen!

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