Beiträge von JK1974

    Ich hatte nach der Kernel-Installation gelegentlich (!) keinen Ton nach einem Neustart, manchmal auch kein Bild. Ich weiß nicht, ob das in einem Zusammenhang steht. Nach dem dpkg-reconfigure alsa-dkms scheint es jetzt wie erwartet zu laufen.


    Auch XBMC scheint besser zu funktionieren. Zuvor gab´s Probleme nach der Wiedergabe von Filmen mit DTS-Ton: Filme z.B. mit MP3-Tonspur blieben stumm - als würde das Audio-Device nicht korrekt nach der DTS-Wiedergabe freigegeben.


    Gestern abend lief es dagegen anscheinend fehlerfrei - muss aber noch mehr testen bzw. von der Family testen lassen (wenn ich nach Hause komme, läuft der Fernseher oft schon - während dieser Jahreszeit allerdings weniger...).


    Fehler bei der Installation oder Kompilierung sind mir nicht aufgefallen.


    P.S.: Kannst Du mir mal einen Tipp geben, welche Logfiles zu beachten sind? In /var/log/messages, /var/log/syslog oder /var/log/user.log finde ich für meinen Geschmack meist zu wenig Infos, oder kann man bei Problemen über irgendeinen Schalter ausführlichere Logfiles erstellen lassen?

    Hi,


    habe seit gestern auch das neue yaVDR 0.2 auf einer separaten Partition neben yaVDR 0.1.1 installiert, die Aufnahmen liegen wie früher auch in einer separaten Partition.


    Welche ist denn die "saubere" bzw. richtige Lösung, diese Partition einzubinden? Eher Symlink oder ein entsprechender Eintrag in die fstab, der die Partition unter /srv/vdr/video.00 mountet?


    Danke für Eure Antworten und viele Grüße


    [EDIT: Hat sich erledigt, habe die Antwort in einem anderen Thread gefunden]

    Ich habe schon bei yaVDR 0.1.1 von diesen Rucklern in xine und XBMC berichtet - anscheinend nicht nur bei HD, sondern auch bei SD: ca. alle 10-30 Minuten ein Ruckler von ca. 1-2 Sekunden.


    Allerdings ist mir letzte Woche noch etwas aufgefallen, das eventuell weit hergeholt erscheint, aber vielleicht doch ein Hinweis sein könnte: Beim Experimentieren unter Windows (sorry!) mit Videostabilisierung von AVCHD-Material (techn.: Frameserving von Vegas nach VirtualDub mit Deshaker-Plug-in und von dort zu meGUI) habe ich mit dem x264-Encoder Testvideos kodiert, mal mit dem AVCHD- und mal mit dem Blu-ray-Profil. Ausgabeformat war MKV, theoretisch hätte also das rauskommen müssen, was man auch so als MKV in freier Wildbahn "findet".
    Durch technische Probleme mit dem Frameserving war es allerdings nicht möglich, Ton mitzukodieren, und da es mir in erster Linie um das Video ging, kam eben ein MKV ohne Ton raus.
    Mit VLC ist die Wiedergabe ruckelfrei (unter Windows), unter yaVDR 0.1.1 (sorry! werde bald updaten) mit XBMC ist jedoch keine flüssige Wiedergabe hinzubekommen. Wenn jetzt meGUI das MKV nicht falsch erstellt hat (vielleicht demuxe ich es nochmal und muxe es nochmal neu, ggf. auch mal mit Ton), würde ich zumindest bei XBMC darauf schließen, dass eine ruckelfreie Wiedergabe vom Audio-Timing abhängig ist.


    Ich verwende, wie unten zu sehen, eine GeForce-8300-onboard-Lösung, derzeit ist sogar eine leisere GeForce 240 drin. Ton kommt über S/PDIF - habe noch keinen HDMI-Verstärker.
    Kann es sein, dass die Timings von Video und Audio unterschiedlich sind und xine bzw. XBMC versuchen, diese Differenz auszugleichen, indem sie gelegentlich das Bild "ausbremsen"?
    Oder ist es "nur" ein Timing-Problem zwischen den X.org-Settings und diversen Fernsehern?


    Ich denke/hoffe, dass jetzt durch den Fußball mehr Leute auf das "Problem" aufmerksam werden bzw. sich einkreisen lässt, wann dieses Problem auftritt. Allerdings würde ich mir wünschen, dass man die Ruckler klarer trennt - manche sprechen von andauernden Rucklern im Sekundentakt, andere haben sogar Artefakte...

    Will mich auch mal als Interessent für eine Lösung des Problems dranhängen. Dachte ich wäre zu blöd, es richtig in den Settings einzustellen, denn ich kannte es bisher auch "nur" von A-Z und bin damit jahrelang gut gefahren. Gut, dafür stehen die letzten Aufnahmen jetzt ganz unten ;).

    Was meint Ihr mit kleinen Hängern? Vielleicht das hier: http://www.vdrportal.de/board/thread.php?threadid=95488?
    Ist zwar noch yaVDR 0.1.1 (da leide ich noch nicht an einem Klötzchenbildungsproblem wegen eines Bugs in der xinelib), aber ich habe auch für diese Ruckler die Ursache noch nicht gefunden.


    Da ich glaube, dass es auch unter Windows 7 auf dem gleiches System auftritt (wobei man da natürlich nie bremsende Tasks ausschließen kann; und hier gibt es beim Spielen von Need for Speed Shift deutlich regelmäßiger Ruckler), muss ich noch probieren, ob ich es durch Austauschen einzelner Komponenten wie Speicherriegel oder mal dem Testen einer anderen DVB-Karte in den Griff bekomme. Derzeit steckt eine GeForce 240 anstelle des Onboard-8300er im System, geändert hat sich nichts.


    Oder sind es die berühmten "Microruckler" im Zusammenspiel mit meinem Panasonic-Plama-TV? Da das Bild aber immer 1-2 Sekunden deutlich sichtbar ruckelt, empfinde ich das jetzt weniger als "micro"... ;)


    P.S.: Kannst Du ggf. den Thread-Titel so abändern, dass (hoffentlich) mehr auf dieses Thema anspringen?

    Windows updated die Systemzeit natürlich über das Internet. Allerdings hatte ich nicht das Gefühl, dass es damit die letzten Monate Probleme gab. Vielmehr habe ich nach Windows immer Linux nochmal gestartet, damit der VDR die Wakeup-Zeit setzen kann.

    Habe kein Update gefahren, weder ein Linux-Update, noch ein BIOS-Update. Das Linux ist unverändert geblieben. Ging einfach wohl seit ca. letzter Woche nicht mehr.


    Es gab zwei Sachen, die ich als Auslöser sehen könnte: Ich kann mich grob an einen fehlerhaften Rechnerstart erinnern, bei dem das BIOS gemeckert hat, ich solle die BIOS-Defaults laden. Spätestens danach hätte es aber meiner Meinung nach gehen sollen. Und das könnte schon länger her sein.


    Je mehr ich darüber nachdenke, vermute ich Windows 7 als Auslöser. Da ich am Windows Media Center rumgespielt habe, halte ich es nicht für unwahrscheinlich, dass Windows am ACPI o.ä. rumgespielt hat, um Einschaltzeiten für Timer etc. zu setzen. Vielleicht ist dabei was durcheinander gegangen, aber ich dachte, das hätte durch die BIOS-Defaults gerade gerückt werden müssen. Oder ist da sogar ein CMOS-Reset notwendig, um falsche ACPI-Einstellungen zu entfernen?

    Hi,


    ich setze yaVDR ein, und monatelang funktionierte ACPI-wakeup (fast) wie erwartet - hier und da ging mal ein Timer verloren, ich dachte aber, das wäre eher ein User- und kein System-Problem ;)


    Jetzt geht ACPI-Wakeup jedoch hier überhaupt nicht mehr, auch Tests über die Kommandozeile lassen den Rechner nicht aufwecken:


    Code
    echo 0 > /sys/class/rtc/rtc0/wakealarm
    echo `date '+%s' -d '+ 5 minutes'` > /sys/class/rtc/rtc0/wakealarm
    echo `date '+%s' -d '+ 5 minutes'` > /sys/class/rtc/rtc0/wakealarm


    (sicherheitshalber 2x) führt zu



    Ist das so korrekt, und wenn nein, wie kann ich es ändern?


    Im BIOS ist RTC-Wakeup natürlich aus, auch HPET habe ich deaktiviert. Sicherheitshalber habe ich vorhin auch mal die BIOS-Defaults geladen, aber es funktioniert trotzdem nicht.
    Windows 7 ist per Dual-Boot auch auf dem Rechner, aber da fast immer Linux gebootet wird und es auch zuvor keine Probleme gab, wenn Windows mal aktiv war, glaube ich nicht an eine "Wechselwirkung". Hatte allerdings letzte Woche das Windows Media Center kurz laufen, aber selbst wenn das das ACPI durcheinander gebracht hat, sollte doch alles nach dem Laden der BIOS-Defaults wieder gehen, oder nicht?


    Ganz davon abgesehen bin ich fast ein halbes Jahrzehnt gut mit nvram-wakeup gefahren und würde es nach diesen Problemen gerne wiederverwenden. Eine funktionierende nvram-wakeup.conf habe ich bereits erstellt, allerdings weiß ich nicht, wie ich das in Grub 2 mit dem Poweroff-Kernel einstellen muss - gibt´s da schon Links? Habe über die Suche nichts gefunden - scheint fast so, als wären alle auf ACPI-Wakeup umgestiegen.


    Irgendwelche Tipps zu einem der beiden Wakeup-Varianten?


    1000 Dank im Voraus!


    [EDIT]
    Das mit dem nvram-wakeup und Grub 2 habe ich hinbekommen und werde es im yaVDR-Bereich posten - für alle die, die es interessiert.
    Dennoch wäre ACPI v.a. wegen Suspend-2-RAM wohl die bessere Wahl, wenn also jemand einen Tipp hat...
    [EDIT off]

    Die DVB-Karte habe ich ausgeschlossen, weil es auch bei XBMC passiert. Andererseits läuft ja der VDR im Hintergrund weiter, sodass sie natürlich doch stören könnte.
    Ich werde die nächsten Tage mal den Speicher austauschen, eventuell kann ich auch kurzfristig mal die DVB-Karte tauschen.


    Mit Cool & Quiet sowie Prozessortaktung habe ich mich auch noch nicht beschäftigt - vielleicht liegt´s ja wirklich daran...


    Aber freut mich, dass nach so langer Zeit noch Antwort kommt und ich anscheinend nicht der Einzige bin. ;)


    EDIT: An den Containern liegt´s nicht. 1. Habe ich´s inzwischen abgestellt, weil ich ein großes TS-File haben will, 2. tritt es auch z.B. bei Videowiedergabe in XBMC auf - aus einer großen TS- oder MKV-Datei.

    Ich formuliere es mal so: Ich arbeite in einer ähnlichen Branche und kenne die Problematik mit Kunden, die meinen, alles auf dem Tablett serviert zu bekommen, obwohl es alles klar dokumentiert ist oder man nur die Google-Suche verwenden muss.
    Jetzt gibt es da zwei Möglichkeiten: Die einen akzeptieren entsprechende Hinweise und kümmern sich dann selbst um die Lösung - bis sie vielleicht wirklich an eine schwierige Stelle kommen. Andere wiederum werden ausfallend.


    Und ganz ehrlich: Auch wenn es noch so viel positive Resonanz gibt, an jedem negativen Kommentar hat man zu knabbern.


    Allerdings ist es dann doch eine Sache: Lässt man sich von den paar "Deppen" (ich nenne jetzt die Unverschämten einfach mal so) runterziehen oder geht man mit der Einstellung ran: Es gibt genügend Leute, die meine Arbeit schätzen, die anderen muss man ignorieren, denn die sind mit ihrem Verhalten wahrscheinlich auch im täglichen Leben bestraft?


    Genau Letzteres scheint Wolfgang zu fehlen. Einerseits schließe ich daraus, dass er ganz tief in sich drin keine "leck mich am A..."-Einstellung hat, sonst würde er es nicht so hart nehmen, was ihn ehrt.
    Andererseits, und das war ja wohl in den letzten Zeilen rauszulesen, finde ich seine Reaktion auch nicht korrekt und unreflektiert.
    Allerdings möchte ich auch nicht vergessen zu erwähnen, dass Wolfgang hervorragende Arbeit geleistet hat, und dass es natürlich einen Unterschied zwischen privatem und beruflichem Engagement gibt - da kann man privat mal schneller auf den Gedanken kommen, den Stecker zu ziehen.

    Ich erkenne vor allem Sync-Probleme mit Dolby-Digital-2.0-Ton, und das reproduzierbar z.B. bei ProSieben - er braucht lange zum Syncen, manchmal passt es nicht und manchmal scheint es auseinander zu laufen. Gehe ich auf MP2, gibt es keine Probleme.


    Und CPU-Last bzw. zu große Anzahl an Plug-ins sind hier nicht das Problem.

    Hi,


    ich weiß, dass es ein Dauerthema ist, Ruckler und HD, aber ich bin mir nicht im Klaren, ob meine Ruckler "normal" sind oder ob irgendetwas an meiner Konfiguration nicht stimmt.
    Zum Phänomen: Bei 1080i (Astra HD Demo), aber wohl auch bei 720p (ARD HD, ZDF HD etc.) treten alle paar Minuten (5 Minuten?) für einen Moment kurze Ruckler auf. Und das nicht nur unter xine/VDR, sondern auch unter XBMC. Schaue ich hier Material in 720p/1080p mit 24p an, gibt´s auch hier alle paar Minuten deutlich sichtbare kurze Ruckler.


    Meine xorg.conf.yavdr habe ich nach der Anleitung im XBMC-Forum erstellt und sieht wie folgt aus:



    Damit funktioniert bei mir die automatische Bildwiederholraten-Umstellung in XBMC - das ist bei meinem Panasonic-TV gut am Schwarzwerden und kurzer OSD-Einblendung zu erkennen.


    Um die Onboard-Grafik (siehe Signatur) als Fehlerquelle auszuschließen, hatte ich die letzten Tage testweise eine Geforce GTX 250 im System. Auch hier gibt es die genannten Ruckler, aber Astra HD scheint etwas flüssiger zu laufen (beides Mal "bob" als Deinterlacer).


    Derzeit habe ich u.a. den Hauptspeicher im Verdacht: Es sind "nur" 1 GByte RAM, vor allem aber meldet das BIOS beim Booten, es sei "unganged memory". In vielen Forumsbeiträgen heißt es aber, das dies der bessere Speichermodus sei. Und davon abgesehen, sollte das bei der Geforce 250 eh irrelevant sein, da sie ihren eigenen Speicher mitbringt.


    Oder sind die beschriebenen Ruckler doch "normal", weil sich die Nvidia-Karten im Gegensatz zu ATI und Nvidia nicht richtig mit dem Display syncen können, sind es also die "berüchtigten" Microruckler, die ich gar nicht so "micro" finde?
    Gibt es jemanden, der behaupten kann, dass es bei ihm über eine wirklich lange Zeit (z.B. > 30 Minuten) absolut (!) ruckelfrei läuft?


    Schonmal besten Dank für jegliche Antworten!


    P.S.: Bild geht per HDMI, Ton per S/PDIF raus.

    Zitat

    Original von Mreimer


    Zum einen hat die eher begrenzte Auswirkungen auf den Rest meines PCs und zum anderen war schon bei der alten FF die Funktionsweise der Firmware nach einiger Zeit von einigen in soweit verstanden, dass die Firmware an Technotrend vorbei um Features erweitert werden konnte (TS, 4MB, ...)


    Naja, der "Video Data Stream Broken"-Bug wurde nie behoben, ebenso wenig Abstürze, wenn man besonders schnell umgeschaltet hat etc.
    So gesehen bin ich fast froh, mit dem Budget-System keines dieser Probleme zu haben. Wenn jetzt noch das Frontend stabil wäre...

    Und man sollte vielleicht auch die Kombi-Möglichkeit nicht vergessen: Eine FF-HD könnte für stressfreie DVB-Nutzung sorgen, während man mit der normalen Grafikkarte XBMC, Webbrowser etc. nutzt - umgeschaltet mit dem Eingangwahlschalter von TV bzw. HDMI-Verstärker.


    Ich will die FF nicht verteufeln, denn ich bin mit der "Alten" recht gut gefahren. Denke ich aber z.B. an die "Video Data Stream Broken"-Geschichte, diese oder jene Firmware-Zickereien, halte ich die Grafikkartenlösung vielleicht doch eher für zukunftsträchtiger. Noch haben wir keine größere Auswahl, aber ATI und Intel können noch dazukommen, ebenso wie die Broadcom-Lösung. Die FF-HD wirkt dann wieder wie eine Insellösung (siehe eHD etc.): Mitgefangen = mitgehangen. Gut, das Problem haben wir mit Nvidias Binärtreibern derzeit auch, aber ATI kann sich auch nicht ewig dem Thema HD unter Linux verschließen.


    Und spätestens wenn wir Richtung 3DTV gehen, werden wir sehen, ob die FF-HD wirklich eine genauso zukunftssichere Wahl ist wie die alte FF. Ich weiß, ich lehne mich da sehr weit aus dem Fenster, aber Pressemeldungen zufolge wird da wohl noch an einem entsprechenden DVB-Standard bis Ende des Jahres geschraubt. Wenn die FF-HD das nicht kann, auch nicht über ein Firmware-Update, dann geht´s doch wieder in Richtung GraKa. Und die ist schnell mal eben getauscht.
    Und wenn jetzt einer sagt, 3D geht eh erst in ein paar Jahren: Es gibt 3D-Shutterbrillen für 25 Euro, mit denen man basteln und experimentieren kann. Es gibt Open-Source-Software-Player, die z.B. über USB oder den seriellen Port ein Sync-Signal ausgeben könnten. Es gibt Algorithmen, um aus einem 2D- ein 3D-Bild zu machen (siehe c´t einige Ausgaben davor). Es gibt 120-Hz-Beamer für 600-700 Euro, alternativ könnte man es auch mal mit Plasmas ausprobieren, die nur 60 Hz können (man hat es ja wohl vor einigen Jahren sogar mit 50-Hz-Röhren-Fernsehern gemacht). Kurzum: Ich weiß nicht, ob gerade die Freaks wie hier oder in anderen HTPC-Foren wirklich so lange warten werden.


    Und zum Thema CI+ und HD+ ist ja auch noch nicht das letzte Wort gesprochen.

    Auch wenn es vielleicht etwas unfair ist, aber ich stimme Torsten73 zu. Als ich den Titel gesehen habe und dort stand, dass es einen Artikel über HD-Decoder-Karten für Linux gibt, war ich gespannt, das Ergebnis aber ist enttäuschend.


    Ich habe seit rund Januar yavdr am laufen und hatte davor vergeblich mit Tonproblemen, Bildaussetzern etc. unter Ubuntu mit xineliboutput gekämpft. Mit yavdr, ebenfalls Ubuntu, aber ohne GNOME, war plötzlich praktisch alles gelöst. Und seit Januar ist es im täglichen Einsatz.
    Ja, es gibt Abstürzen von xine, aber yavdr fängt die automatisch auf. Und ja, dass das Frontend beim Spulen hängt, nervt wirklich wahnsinnig, da man dann derzeit bei yavdr das Front-end manuell neu starten muss - das ließe sich z.B. mit entsprechend konfigurierter irexec lösen, ich bin mir sicher, die arbeiten schon daran. Und ja: Ganz so einfach nach dem Motto "einstecken und los gehts" ist es nun auch nicht.
    Dennoch kommt meine Familie mit zwei Kindern (9 und 7) prima damit klar. Das Fazit also, dass vdpau nicht geeignet sei, ist definitv falsch. Und dass man mit den HW-Lösungen auch nicht jedes beliebige Format wiedergeben kann, wird auch unter den Tisch gekehrt - ich denke, dass XBMC in yavdr ein gewaltiger Mehrwert ist, der dank MKV, YouTube, MP3 inkl. Cover etc. wirklich jeden staunen und sagen lässt: Das will ich auch haben - da bin also nicht nur ich begeistert...


    Hätte der Artikel geheißen: HD-Karten mit c´t-VDR, hätte ich gesagt: Passt. Aber jeder, der den Artikel liest, bekommt den Eindruck, dass der Grafikkarten-Einsatz für einen HD-VDR nichts taugt. Und genau das ist falsch.
    Schade, denn gerade von einer c´t, die als Bibel unter den Computerzeitschriften ganz besonders zur Meinungsbildung und Diskussion beiträgt, hätte ich das nicht erwartet. Würde mir wünschen, dass Cooper das nochmal in einem anderen Zusammenhang (vielleicht XBMC?) richtig stellt bzw. nochmals überprüft.

    Habe nach einiger Zeit Pause mal wieder an das Thema heran gemacht. Hinzu kommt, dass ich mir mal die Arduino-Prototyping-Plattform unter www.arduino.cc angeschaut habe, um mehr zu verstehen, wie das mit Mikrocontrollern etc. funktioniert - für kleinere Testprojekte wie diese 3D-Sache.


    Zunächst wollte ich die Elsa-Shutterbrille mithilfe von Arduino so steuern, wie im ersten Thread beschrieben. Das geht dort mit simplen Befehlen wie digitalwrite(Pin-Nr., HIGH/LOW). Dummerweise wollte es aber nicht so, wie ich es für VESA-Brillen gelesen und im ersten Posting geschrieben habe. Da gibt es jetzt zwei Möglichkeiten: Entweder war die Revelator defekt, oder sie wird/wurde doch anders angesteuert als über einen einfachen 0/5-Volt-Wechsel.
    Also habe ich gedacht: Ich gehe mal direkt an die Shuttergläser ran. Am Revelator-Kabel gibt es ein kleines Kästchen, und mein Verdacht hat sich bestätigt: Dort ist eine kleine Platine drin, die aus einem kleinen Microcontroller und einem analogen Muxer-/Demuxer-Chip besteht. Das, was diese beiden Chips und ein paar SMDs auf der Platine produzieren, ging an 4 Kabel: zwei schwarz und ein grünes und ein blaues Kabel. Schwarz war klar Masse - und grün und blau die 5-Volt-Leitungen für jeweils das linke und das rechte Glas.
    Und tatsächlich hat´s dann mit Arduino funktioniert: Über das entsprechende Setzen auf 0 oder 5 Volt kann ich die Gläser hell oder dunkel machen.


    Interessant waren dann die folgenden Experimente mit den Hell-Dunkel-Zeiten: Sind die Brillengläser länger hell, flimmert es unsäglich. Setzt man dagegen die Brillengläser z.B. auf Öffnungszeiten von 1-3 Millisekunden und lässt sie ansonsten schwarz, hält sich das in Grenzen. Das wären auch die Zeiten, die die "neuen" Shutterbrillen offen sind (siehe c´t), allerdings bleiben die Brillen bei 120 Hz ca. 5 Sekunden schwarz, während es bei 50 Hz z.B. 17 ms wären.


    Daraufhin habe ich unter Windoof mithilfe von AVISynth ein Testfile erstellt. Auf der Nvidia-Seite gibt es z.B. Side-by-Side-Demos (ich habe "Summer in Heidelberg" genommen), die man über ein entsprechendes Skript in einen 50p-Film mit abwechselndem Bild für das linke und das rechte Auge verwandeln kann. Das Ergebnis habe ich als MPEG-2-File ausgegeben - kann dann wegen der 50 Frames jedoch nicht Main-Profile, sondern nur High-Profile sein. Den Playern ist das aber egal: Sowohl Windows (VLC, Media Player Classic, WMP), als auch Linux (XBMC) spielen das File ab.
    Auf meinem Plasma sah das auch dann entsprechend aus. Hier konnte man deutlich sehen, dass sich das Bild für das linke und das rechte Auge abwechseln.


    Ob es nun wirklich mit 50 oder 60 Hz geht und wie gut es ist, weiß ich nicht. Denn auch wenn es für ein Auge "nur" 3 ms offen ist und danach 17 ms dunkel, habe ich wohl nie wirklich die Mitte zwischen den Bildwechseln erwischt - ich hatte immer Doppelbilder.
    Der nächste Versuch wird also sein, das Video per VGA an den Plasma auszugeben und dann das VSync-Signal für die Synchronisation herzunehmen.


    Ist das VSync-Signal wirklich "nur" 0,75Vss? Und da ich Elektronik-Einsteiger bin: Wie würde ich das mit einem Microcontroller wie dem AVR verbinden? Letzterer hat digitale und analoge Eingänge, wobei ich denke, dass die analogen Eingänge auch nur positive Werte annehmen. Muss ich vielleicht eine Diode vorschalten und dann über Analog-Input überprüfen, wann der Wert auf >0 geht?


    P.S.: Wegen der unterschiedlichen Polarisation von Shutterbrillen-Gläsern und "normalen" LCDs funktioniert es weder mit LCD-Monitoren noch LCD-Fernsehern.

    Eigentlich müsste ja vdr warten bis fsck durch ist - selbst wenn man da ein paar Sekunden verliert (selbst wenn es zwei Minuten wären, sollte das bei 5 Minuten Puffer immer reichen).
    Oder man setzt es wirklich auf 0 und startet es manuell an manchen Tagen beim Ausschalten des VDRs - wobei ich mir das auch schwierig vorstellen kann, da man ja wohl vorher die Partition aushängen muss.

    Hi,
    was ich jetzt schreibe, könnte völliger Bullshit sein, aber ich hatte auch mal das Problem mit yaVDR/Ubuntu 9.10, dass er mal auf /video.00 zugreifen wollte und mal nicht.
    In Ermangelung an Ideen habe ich den Parameter "Pass" in der fstab von 2 auf 0 gesetzt, was dafür sorgt, dass die Partition nicht mehr überprüft wird. Ich hatte nämlich den Verdacht, dass wenn Linux die Partition überprüft und der VDR startet, VDR nicht mehr schreibend auf die Partition zugreifen kann, während fsck noch läuft. Ich dachte, upstart mit seiner Parallelität könnte Schuld daran gewesen sein. Auf jeden Fall: Das Problem, dass er nicht auf /video.00 zugreifen kann, ist seit Wochen anscheinend nicht mehr aufgetreten.
    Verweise abschließend sicherheitshalber nochmal auf den ersten Abschnitt des ersten Satzes in diesem Post ;)