Absturz beim Setzen einer Schnittmarke

  • Hallo allerseits,


    nachdem ich jetzt alle Probleme mit DVB-Treiber und Lirc gelöst habe liess das nächste Problem nicht lange auf sich warten ;) :


    Sobald ich bei einer Aufnahme irgendetwas mit Schnittmarken mache, sprich eine Schnittmarke setze oder zu einer springe, stürzt der VDR komplett ab und die einzige Möglichkeit ist ein Reboot.


    Alles andere scheint soweit zu funktionieren.
    Möglicherweise ist es hilfreich dazuzusagen dass beim Versuch eine Aufzeichnung umzubenennen folgende Fehlermeldung erscheint:


    "Fehler beim Ansprechen der Aufzeichnung"


    Möglicherweise besteht zwischen beiden Phenomenen ein Zusammenhang.
    Mit den Rechten kann eigentlich kein Problem vorliegen, denn das habe ich schon überprüft und allen Benutzern volle Zugriffsrechte erteilt um diese Fehlerquelle von grundauf auszuschliessen.


    Möglicherweise hat VDR auch ein Problem damit dass die Aufzeichnungen direkt auf ein per NFS gemountetes Laufwerk geschrieben werden, von dem auch gebootet wird.


    In der Syslog steht leider auch nichts Aufschlussreiches.


    Vielleicht hat irgendjemand eine Ahnung woran sowas liegen könnte.


    mfG,


    Code7R

    Casetronic Travla C137 - EPIA M-10000 - VDR 1.6.0-1 incl. Extension Pack - Kernel 2.6.18 - Debian Testing

  • Hallo nochmal,


    ich habe mal ein paar Tests mit verschiedenen VDR-Versionen gemacht.
    Das oben beschriebene Problem tritt bei allen 1.3er Versionen auf, bei 1.2.6 allerdings nicht.


    Desweiteren habe ich mal absichtlich einen "Absturz" provoziert, indem ich mehrmals zwischen gesetzten Schnittmarken hin- und hergesprungen bin um zu sehen was passiert wenn ich dem VDR einfach etwas mehr Zeit gebe. Und siehe da nach etwa 5-6 Minuten rührt sich wieder etwas.


    Das könnte dafür sprechen dass der VDR aufgrund der relativ langsamen Netzwerkverbindung länger braucht um die betreffende Stelle in der Aufnahme zu finden.


    Seltsam ist allerdings dass das Problem bei der 1.2.6er nicht auftritt.


    Ich befürchte dass ist ein etwas zu spezifisches Problem als das jemand hier ne Lösung parat hätte. ;) Aber vielleicht hat ja noch jemand eine Idee.


    mfG,


    Code7R

    Casetronic Travla C137 - EPIA M-10000 - VDR 1.6.0-1 incl. Extension Pack - Kernel 2.6.18 - Debian Testing

  • Ist zwar ziemlich offtopic in diesem Forum, aber schreib' einfach mal "export LD_ASSUME_KERNEL=2.4.1" in die runvdr (vor dem Aufruf des vdr).


    Oliver

  • Hallo Code7R,


    Zitat

    Original von Code7R
    Möglicherweise hat VDR auch ein Problem damit dass die Aufzeichnungen direkt auf ein per NFS gemountetes Laufwerk geschrieben werden, von dem auch gebootet wird.


    nein, das ist kein Problem beim VDR (habe ich auch so, alle Aufnahmen liegen auf dem Server)


    Hast Du vielleicht mal eine Platte um diese als /video allein zu benutzen, um diese Fehlermöglichkeit auszuschließen?


    Zitat

    In der Syslog steht leider auch nichts Aufschlussreiches.


    Zeigt die Konsole entwas an? Bei meinen Versuchen mit NFSRoot-FS habe ich eine Meldung (... NFS-Server reagiert nicht ... o.ä) auf dem Bildschirm gesehen, der Rechner war dann ca. 20-30 Sekunden nicht bedienbar.


    Zitat

    Aber vielleicht hat ja noch jemand eine Idee.


    Betrift das alle Aufnahmen?
    Ist die index.vdr fehlerfrei? --> eventl. löschen und mit genindex neu aufbauen lassen.


    Hardy

    Suche: 6 Richtige für die nächste Lottoziehung
    PS: Wer Rechtschreibfehler findet, darf sie behalten!

  • Hallo auch,


    Zitat

    Hast Du vielleicht mal eine Platte um diese als /video allein zu benutzen, um diese Fehlermöglichkeit auszuschließen?


    Ja das könnte ich versuchen.


    Zitat

    Zeigt die Konsole entwas an? Bei meinen Versuchen mit NFSRoot-FS habe ich eine Meldung (... NFS-Server reagiert nicht ... o.ä) auf dem Bildschirm gesehen, der Rechner war dann ca. 20-30 Sekunden nicht bedienbar.


    Nein darauf hab ich geachtet. Diese Fehlermeldung kenne ich auch allerdings nur wenn ich den NFS-Server auf der anderen Seite ganz abschalte.
    Könnte es vielleicht an Einstellungen in der Exports-Datei auf dem Server liegen? Könntest du mir vielleicht die betreffende Zeile aus deiner als Muster zur Verfügung stellen?


    Zitat

    Ist die index.vdr fehlerfrei? --> eventl. löschen und mit genindex neu aufbauen lassen.


    Naja soweit ich das beurteilen kann ist die fehlerfrei. Die Aufnahmen werden ja auch korrekt abgespielt. Nur rumspringen in der Aufnahme verträgt er nicht.


    Vielleicht liegts auch am Server selbst. Der NFS läuft unter Mandrake, das auf mich schon immer einen etwas schwerfälligen Eindruck gemacht hat.


    mfG,


    Code7R


    P.S. So off-topic find ich das garnet. Immerhin gehts um Aufnahmen.

    Casetronic Travla C137 - EPIA M-10000 - VDR 1.6.0-1 incl. Extension Pack - Kernel 2.6.18 - Debian Testing

  • Hallo Code7R,

    Zitat

    Original von Code7R
    Könnte es vielleicht an Einstellungen in der Exports-Datei auf dem Server liegen? Könntest du mir vielleicht die betreffende Zeile aus deiner als Muster zur Verfügung stellen?


    nein, ich verwende Netware als Server (deshalb hat ja auch mein Tux ein rotes Mäntelchen an). Dort ist i.M. alles noch etwas anders.


    Zitat

    Naja soweit ich das beurteilen kann ist die fehlerfrei. Die Aufnahmen werden ja auch korrekt abgespielt. Nur rumspringen in der Aufnahme verträgt er nicht.


    Abspielen läst sich eine Aufnahme auch ohne index.vdr, diese ist ja genau zum rumspringen gedacht.
    Sie enthält die Datei-Nummer (001.vdr ...) und die Position der Frames in dieser Datei um an dieser stelle die Wiedergabe zu starten.
    Es könnte also genau dein Problem sein.


    Hardy

    Suche: 6 Richtige für die nächste Lottoziehung
    PS: Wer Rechtschreibfehler findet, darf sie behalten!

    Einmal editiert, zuletzt von HFlor ()

  • Hallo nochmal,


    ich habe inzwischen einiges getestet:


    Ich habe Genindex benutzt um die index.vdr neu zu erstellen. Leider keine Veränderung.


    Ebenfalls habe ich eine Festplatte in das Gerät gebaut um festzustellen ob das Problem vielleicht bei der Übertragung der Aufnahmen über das Netzwerk liegt. Auch Fehlanzeige. Immernoch das selbe Problem.


    Allerdings war ich in der Lage das Problem etwas genauer zu bestimmen:


    Wenn man eine Aufnahme abspielt, pausiert, und dann an der aktuellen Stelle eine Schnittmarke setzt, friert VDR ein. Dies passiert ebenfalls, wenn man zwischen Schnittmarken hin- und herspringt. Die Dauer des Absturzes hängt anscheinend direkt von der Gesamtlänge der Aufzeichnung ab.


    Habe schon gedacht es könnte daran liegen dass mein VDR keine Swap-Partition hat. Ich habe allerdings mittel "free" festgestellt dass der verfügbare Hauptspeicher während des oben beschriebenen Fehlers nie unter 100MB sinkt. Daran kanns also nicht liegen !???


    Fazit: So langsam gehen mir die Ideen aus. ;) Wie gesagt, mit VDR Version 1.2.6 funzt alles prächtig. Aber an einen Bug im 1.3.12 glaube ich auch nicht, denn sowas wäre ja schon aufgefallen.


    Naja, aber da etwa 90% der Leute hier allgemein mehr Ahnung von Linux haben als ich hoff ich mal das Ihr was damit anfangen könnt.


    mfG,


    Sascha

    Casetronic Travla C137 - EPIA M-10000 - VDR 1.6.0-1 incl. Extension Pack - Kernel 2.6.18 - Debian Testing

    Einmal editiert, zuletzt von Code7R ()

  • Zitat

    Original von Code7R
    ich habe inzwischen einiges getestet:
    ...


    Aber wohl nicht, was ich oben geschrieben habe, oder?


    Oliver

  • Hallo,


    im Moment verwende ich das runvdr-script noch garnicht zum start von vdr, da die Treibermodule bereits durch etc/modules geladen werden.


    Ich habe allerdings den Befehl "export LD_ASSUME_KERNEL=2.4.1" schon einmal unmittelbar vor dem Start des VDR von Hand ausgeführt ohne dass dies einen nennenswerten Effekt hatte.


    Ich werds aber auch noch einmal innerhalb von runvdr versuchen.


    Könntest du mir vielleicht kurz erläutern von das Setzen dieser Variable bringt bzw. warum es in meinem Fall etwas bringt? Das würde mir (und anderen) möglicherweise helfen ähnliche Fehler in Zukunft selbst zu beheben.


    Danke im Voraus,


    Sascha

    Casetronic Travla C137 - EPIA M-10000 - VDR 1.6.0-1 incl. Extension Pack - Kernel 2.6.18 - Debian Testing

  • Zitat

    Original von Code7R
    im Moment verwende ich das runvdr-script noch garnicht zum start von vdr, da die Treibermodule bereits durch etc/modules geladen werden.


    Ich habe allerdings den Befehl "export LD_ASSUME_KERNEL=2.4.1" schon einmal unmittelbar vor dem Start des VDR von Hand ausgeführt ohne dass dies einen nennenswerten Effekt hatte.


    Das sollte es tun, vorausgesetzt, man hat sich nicht vertippt. ;)


    Zitat

    Könntest du mir vielleicht kurz erläutern von das Setzen dieser Variable bringt bzw. warum es in meinem Fall etwas bringt? Das würde mir (und anderen) möglicherweise helfen ähnliche Fehler in Zukunft selbst zu beheben.


    Mit Kernel 2.6 hat vdr ein Problem mit den neuen NPTL-Funktionen. Dies äußert sich darin, daß es Probleme beim Setzen/Verschieben von Schnittmarken gibt. :rolleyes: Der Befehl bewirkt, daß die neuen NPTL-Funktionen nicht verwendet werden. Hat afaik bisher immer geholfen.


    CU
    Oliver

  • hallo,

    Zitat

    Original von UFO
    Mit Kernel 2.6 hat vdr ein Problem mit den neuen NPTL-Funktionen. Dies äußert sich darin, daß es Probleme beim Setzen/Verschieben von Schnittmarken gibt. :rolleyes: Der Befehl bewirkt, daß die neuen NPTL-Funktionen nicht verwendet werden. Hat afaik bisher immer geholfen.


    CU
    Oliver


    sind eigentlich noch sonstige 'Nebenwirkungen' bekannt in Bezug auf 'nptl' ,
    oder beschraenkt sich das momentan auf das Setzen bzw Verschieben von den Schnittmarken ?
    mfg

  • Zitat

    Original von holymoly


    sind eigentlich noch sonstige 'Nebenwirkungen' bekannt in Bezug auf 'nptl' ,
    oder beschraenkt sich das momentan auf das Setzen bzw Verschieben von den Schnittmarken ?


    Mir sind nur die Schnittprobleme bekannt. Da sich das Thread-Konzept jedoch durch den gesamten vdr durchzieht, würde es mich nicht wundern, wenn es noch andere subtile Probleme gäbe...


    Daher sollte man sicherheitshalber LD_ASSUME_KERNEL=2.4.1 verwenden, bis das NPTL-Problem beseitigt ist. Hat afaik keine negativen Auswirkungen.


    CU
    Oliver

  • Hallo Oliver,


    also ich denk ich muss dir nachträglich mal Danke für den tollen Tip sagen.


    Hab LD_ASSUME_KERNEL=2.4.1 mal (nochmal) versucht und siehe da, Problem gelöst.


    Nachricht an alle andren: Hört auf den Mann. ;)


    mfG,


    Sascha

    Casetronic Travla C137 - EPIA M-10000 - VDR 1.6.0-1 incl. Extension Pack - Kernel 2.6.18 - Debian Testing

Jetzt mitmachen!

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