Fehler im XFS
Fehler in dem xfs generell, das will nicht in meinem Kopf. Xfs hat zwei Superblocks, lasse mal die xfs_repair laufen, eine wird schon konsistent sein.
Wie bereits von mir gesagt, ich benutze seit einigen Jahren das XFS-Filesystem für meine Videopartitionen, weil mir das Löschen von großen Dateien (z.B. mehr als 13GB bei langen HDTV-Aufnahmen) mit ext3/4 viel zu lange gedauert hat. Jetzt mit XFS dauert das Löschen einer Aufnahme nur eine oder sehr wenige Sekunden.
Das mit dem löschen von großen Dateien kann nicht nur xfs gut, das ist eine der Stärken von ext4 (gegenüber ext3). 
Albert
Ja, danke.
Es gibt auch nirgends so was wie "getstatus" oder vorallen "setstatus"? Also um z.B. die Uhrzeit oder die existenz/grösse
einer Datei herauszubekommen oder mit dem Filepointer zu jonglieren?
[gs]etstatus() kommt in der VDR-Source nicht vor. Es gibt zwar SetStatus(), aber das hat nichts mit Dateien zu tun.
Zitat
Möglicherweise in einem Plugin...
Das weiß ich nicht.
Zitat
Ist schon seltsam das das löschen einer Datei via VDR-Menu unschöne Spuren im FS hinterlässt, das löschen von der Komandozeile aber nicht.
Wenn in VDR eine Aufnahme im Menü gelöscht wird, dann wird das entsprechende Verzeichnis lediglich von *.rec nach *.del umbenannt, was mittels der Funktion rename() geschieht. Ich kann mir ehrlich gesagt nicht vorstellen, wieso das solche Nebeneffekte haben sollte.
Benutzt du einen "plain vanilla" VDR, oder sind da Patches im Spiel?
Versuch es auch mal ohne jegliche Plugins (bis auf das Ausgabeplugin).
Klaus
Das hört sich für mich nach einem Defekt an der festplatte. Ich würde mal das Hersteller Tool drüberlaufen lassen, ob wirklich alles ok ist.
Das hört sich für mich nach einem Defekt an der festplatte. Ich würde mal das Hersteller Tool drüberlaufen lassen, ob wirklich alles ok ist.
Die Platte ist neu und trägt auch noch Boot/System selbst (in ext2/ext4)
Smartctl hat ja auch nix zu meckern.
auch nicht im "-t short" lauf.
Aber ich suche mal die UltimateBootdisk raus. Ich mag ja auch nicht glauben das da ständig Fehler entstehe.
XFS ist ja nu nicht gerade "experimental-testing"
Benutzt du einen "plain vanilla" VDR, oder sind da Patches im Spiel?
Was er benutzt, das ist ein Mischling aus dem yaVDR Unstable (und wer weiß noch woher), welches mal yaVDR 0.6 werden soll. Das steht in seiner Ausgabe von ctvdrinfo.
VDR : 1.7.33-3yavdr0~precise
Kernel: 3.2.0-35-generic
ABI : vdr-abi-1.7.32-yavdr0
Gegenüber der yaVDR 0.5 Stable ist sein VDR zu neu, Kernel zu alt, ABI weicht ab. Für mich ist das für eine Fehlerquelle mehr als genug!
Albert
deb http://ppa.launchpad.net/yavdr/unstable-vdr/ubuntu precise main
deb http://ppa.launchpad.net/yavdr/unstable-xbmc/ubuntu precise main
Was hat das in der sources.list verloren?
Albert
Was hat das in der sources.list verloren?
Das war das Resultat von Problemen des VDR 1.7.27 beim LNB-Sharing mit mehreren gebondeten Tunern.
Das war das Resultat von Problemen des VDR 1.7.27 beim LNB-Sharing mit mehreren gebondeten Tunern.
Du meinst 1.7.22!? Seine 1.7.33 ist aber nicht das momentan angebotene 1.7.27 von der Stable. Irre ich mich?
Albert
Du meinst 1.7.22!?
Nein, ich meine schon was ich geschrieben habe. Es gab im VDR nochmal Änderungen für die Behandlung mehrere gebondeter Tuner nach der 1.7.27, die wir momentan in stable-vdr haben. Wie und warum er mit unstable-vdr unterwegs ist, steht alles hier: Bild friert ein (decoder buffer empty, duping frame)
Es gab im VDR nochmal Änderungen für die Behandlung mehrere gebondeter Tuner nach der 1.7.27, die wir momentan in stable-vdr haben.
Heißt das, dass 1.7.22 voll betroffen ist, 1.7.27 bondet nur zwei Tuner richtig, wenn man noch mehr Tuner hat, nimmt man besser 1.7.33?
Albert
Mangels Empfangsmöglichkeiten kann ich es hier nicht nachstellen, aber nach den paar Fällen, die ich hier im Forum gesehen habe scheint das zumindest für die yaVDR-Pakete momentan ein möglicher Weg zu sein.
Mangels Empfangsmöglichkeiten kann ich es hier nicht nachstellen, aber nach den paar Fällen, die ich hier im Forum gesehen habe scheint das zumindest für die yaVDR-Pakete momentan ein möglicher Weg zu sein.
Also seit der 1.7.33 bemerke ich keine Probleme mehr, die mit Bonding zusammen hängen könnten.(*)
Danbke dafür! 
root@vdr4:# lspci -nn | grep -i -e "dd01" -e "14f1" -e "13d0"
03:00.0 Multimedia controller [0480]: Digital Devices GmbH Octopus LE DVB adapter [dd01:0003]
04:05.0 Multimedia video controller [0400]: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [14f1:8800] (rev 05)
04:06.0 Network controller [0280]: Techsan Electronics Co Ltd B2C2 FlexCopII DVB chip / Technisat SkyStar2 DVB card [13d0:2103] (rev 02)Das sind 4 HD und 2 SD Empfänger (sat) an 2 Kabeln.(Z.Zt. eher nur als test zuverstehen)
(*) Ok, manchmal stoppt weiterhin die wiedergabe des Live streams obwohl kein Konflikt vorliegt. wenn ein Timer startet.
Das habe ich noch nicht werter untersucht. das hier ist schlimmer.
Wenn in VDR eine Aufnahme im Menü gelöscht wird, dann wird das entsprechende Verzeichnis lediglich von *.rec nach *.del umbenannt, was mittels der Funktion rename() geschieht. Ich kann mir ehrlich gesagt nicht vorstellen, wieso das solche Nebeneffekte haben sollte.
Benutzt du einen "plain vanilla" VDR, oder sind da Patches im Spiel?
Versuch es auch mal ohne jegliche Plugins (bis auf das Ausgabeplugin).
Klaus
Also bis zum umbenennen war ja auch noch alles sauber.
Aber dann habe ich per Menu "nochmal" gelöscht. Dann waren die Files wirklich weg.
(Aber nicht dsa Verzeichnis weilich da ausversehen mit pwd drauf war.)
Und dieses 2. Löschen macht wohl das xvdr plugin?
Leider das ganze nicht wirklich so reproduzierbar wie ich zuerst hoffen wollte.
Ich kann auch nicht ausschliessen, das das FS angeknackst war, als ich einst die Dateien reinkopiert hatte,
Also bis zum umbenennen war ja auch noch alles sauber.
Aber dann habe ich per Menu "nochmal" gelöscht. Dann waren die Files wirklich weg.
(Aber nicht dsa Verzeichnis weilich da ausversehen mit pwd drauf war.)
Und dieses 2. Löschen macht wohl das xvdr plugin?
Von VDR-Seite kann es kein "zweites Löschen" geben, da die Aufnahme beim ersten Löschen bereits aus dem Menü und aus der Liste der Aufnahmen entfernt wird.
Aber selbst wenn ein Plugin einen zweiten Anlauf macht, um ein Verzeichnis umzubenennen, dann sollte das keine so verheerenden Folgen haben. Das klappt entweder, oder es klappt nicht (wenn es den ursprünglchen Verzeichnisnamen, also *.rec, nicht mehr gibt). Im Fehlerfall sollte dann aber eine entsprechende Log-Meldung kommen (falls das Plugin nicht völlig an VDR vorbei arbeitet).
Zitat
Leider das ganze nicht wirklich so reproduzierbar wie ich zuerst hoffen wollte.
Ich kann auch nicht ausschliessen, das das FS angeknackst war, als ich einst die Dateien reinkopiert hatte,
Nach allem, was ich hier so mitbekomen habe, würde ich auch auf ein Filesystem- oder Plattenproblem schließen.
Wie gesagt, als wichtigen Test würde ich es nochmal mit der aktuellesten VDR-Version, ohne jegliche Patches bzw. Plugins (bis auf das Ausgabeplugin) probieren.
Klaus
Also bis zum umbenennen war ja auch noch alles sauber.
Aber dann habe ich per Menu "nochmal" gelöscht. Dann waren die Files wirklich weg.
(Aber nicht dsa Verzeichnis weilich da ausversehen mit pwd drauf war.)
Und dieses 2. Löschen macht wohl das xvdr plugin?
Von VDR-Seite kann es kein "zweites Löschen" geben, da die Aufnahme beim ersten Löschen bereits aus dem Menü und aus der Liste der Aufnahmen entfernt wird.
[/quote]
Naja, das ist dann wohl das nicht so glücklich implemtierte xvdr plugin in?
Ich bekomme ja die doppelte Anzahl an Files angezeigt.
Nach dem 1. "Löschen" (also dem rename) steht die Aufnahme weiterhin in der Liste,nur ohne Laufzeit angabe.
Will ich mir diese ansehen, wird versucht auf .rec zuzugreifen umd die index zu lesen.
Da es index nicht gibt, wird versucht diese neu zu erstellen, was nicht klappt, weil die Aufnahme ja unter
.del zufinden wäre.
Lösche ich diese "Aufnahme ohne länge", so hatte ich, als ich das kaputte XFS den Efekkt, das diese Aufnahme nicht verschwand.
An wen wende ich mich nun?
Das ist nicht das VDR, sondern ein Plugin. Das ja generell zu störungen führt, wie die doppelten einträge.
Zitat
Aber selbst wenn ein Plugin einen zweiten Anlauf macht, um ein Verzeichnis umzubenennen,
Beim "2. löschen" wird wirklich gelöscht und nicht nur umbenannt.
Das ist schon sehr seltsam gemacht.
Frage:
Wenn werden denn sonst die .del entfernt?
Ich schaue mir das mal an. Bisher hatte ich keine Fehler mehr (einzige Änderung: write cache ist aus.
Könnte es sein, dsa yaVDR nicht nur sehr schnell hoch fährt, sondern zu schnell runter ohne die Platten vorher einzeln per Software, nach dem umounten, runterzufahren damit die ihren Cache leeren? Sondern einfach synch und dann den gesamten Saft abdreht?)
BTW: Ich mache kein S3 sondern fahre die Kiste vollrunter.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!