Probleme mit Aufnahme auf DBox HD

[TDFKAOlli]

Moin,

ich habe seit version 2.2.6 größere Problem mit der Aufnahme auf die interne HD aber auch mit dem Abspielen von Sendungen. Ich hatte immer gehofft, dass die Probleme mit den nächsten Updates behoben werden, aber anscheinend ist das Problem bei anderen nicht vorhanden.

Ich hatte die HD noch mit den Yadi images in Betrieb genommen und damals aus Performance_Gründen XFS genommen. Nur bei XFS war ich überhaupt in der Lage ARD/ZDF Sendungen ruckelfrei aufzunehmen. Hat noch jemand Erfahrung mit XFS für die DBox?

Bei der Aufnahme gelingt etwa jede zweite bis dritte Aufnahme. Normalerweise rebootet die Box kurz nach Aufnahmestart, so dass ich immer ca. 1,8Mbyte Dateien auf der Platte habe.

Beim Abspielen der Sendungen habe ich häufig reboots, wenn ich nach dem Sendungsanfang suche (z.B. 15 sek, 1Min. 5Min. springen). Sehr nervig, da ich viele Sachen nach einmaligen schauen lösche, zusammenschneiden also nicht lohnt.

Ich nehme mal an, das entweder etwas an meiner Konfiguration nicht stimmt, oder das XFS nicht mehr richtig supportet wird seit 2.2.6.

So, welche Logs soll ich sammeln

Gruß, TDFKAOlli

[jmittelst]

Ein Log der Aufnahme wäre vielleicht mal sinnig... eine geglückte und eine mit Crash.

Aber mal nebenbei: Wann hast Du das letzte Mal einen HDD-Check gemacht? Oder mal die Kabel auf Wackelkontakte gecheckt? In einer Nokia vielleicht auch mal das IF raus nehmen und die Kontakte noch mal mit Alkohol reinigen... oder sowas?

Ich benutze zwar schon ewig ext2, kann mit aber kaum vorstellen, das es generelle Probleme mit XFS geben sollte. Das wäe sicher hier im Forum aufgefallen.

cu
Jens

[eltinax]

Hallo,
nur zur Info.
Da XFS im Setup voreingestellt war, habe ich dieses auch installiert.
Bis jetzt hatte ich noch nie Probleme mit den Aufnahmen.
Das Einzige, dass beim Update auf das neueste Image die Festplatte nicht mit dem bestehenden Filesystem erkannt wurde und ich sie neu einrichten musste.
Vielleicht löst eine neue Formatierung, bzw ein neues Setup derPlatte ja auch Dein Problem.

cu
eltinax

[TDFKAOlli]

Hallo,

Aber mal nebenbei: Wann hast Du das letzte Mal einen HDD-Check gemacht? Oder mal die Kabel auf Wackelkontakte gecheckt? In einer Nokia vielleicht auch mal das IF raus nehmen und die Kontakte noch mal mit Alkohol reinigen... oder sowas?

HDD_Check hab ich glaube ich noch nie gemacht. Macht mein Linux normalerweise von alleine

O.k. aber der Tipp war glaube ich gut. Bei den Scripten "HDD-Check - Ergebnis anzeigen" hat angemängelt, das kein Check durchgeführt wurde. Ich habe dafür kein Script gefunden, aber im Service menu -> Harddsik Setup "HDD-Check" gefunden und das genommen. Des hat ein paar Minuten gedauert und ist mit einem "OK" button zurückgekommen.
Auf dem seriellen Interface sah das bei einem zweiten Lauf so aus:

Code: Alles auswählen

Harddisk Menu 2008-08-02 JTG-Riker V0.39 
[neutrino ide] found mountpoint /hdd
[neutrino ide] unmount /hdd
[neutrino ide] executing /var/tuxbox/config/hddcheck.start
[: missing ]
Phase 1 - find and verify superblock...
        - block cache size set to 512 entries
Phase 2 - using internal log
        - zero log...
zero_log: head block 480 tail block 480
        - scan filesystem freespace and inode maps...
        - found root inode chunk
Phase 3 - for each AG...
        - scan and clear agi unlinked lists...
        - process known inodes and perform inode discovery...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - agno = 4
        - agno = 5
        - agno = 6
        - agno = 7
        - agno = 8
        - agno = 9
        - agno = 10
        - agno = 11
        - agno = 12
        - agno = 13
        - agno = 14
        - agno = 15
        - process newly discovered inodes...
Phase 4 - check for duplicate blocks...
        - setting up duplicate extent list...
        - check for inodes claiming duplicate blocks...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - agno = 4
        - agno = 5
        - agno = 6
        - agno = 7
        - agno = 8
        - agno = 9
        - agno = 10
        - agno = 11
        - agno = 12
        - agno = 13
        - agno = 14
        - agno = 15
Phase 5 - rebuild AG headers and trees...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - agno = 4
        - agno = 5
        - agno = 6
        - agno = 7
        - agno = 8
        - agno = 9
        - agno = 10
        - agno = 11
        - agno = 12
        - agno = 13
        - agno = 14
        - agno = 15
        - reset superblock...
Phase 6 - check inode connectivity...
        - resetting contents of realtime bitmap and summary inodes
        - traversing filesystem ...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - agno = 4
        - agno = 5
        - agno = 6
        - agno = 7
        - agno = 8
        - agno = 9
        - agno = 10
        - agno = 11
        - agno = 12
        - agno = 13
        - agno = 14
        - agno = 15
        - traversal finished ...
        - moving disconnected inodes to lost+found ...
Phase 7 - verify and correct link counts...

        XFS_REPAIR Summary    Mon Nov 10 21:04:00 2008

Phase           Start           End             Duration
Phase 1:        11/10 21:00:11  11/10 21:00:12  1 second
Phase 2:        11/10 21:00:12  11/10 21:01:08  56 seconds
Phase 3:        11/10 21:01:08  11/10 21:01:53  45 seconds
Phase 4:        11/10 21:01:53  11/10 21:03:34  1 minute, 41 seconds
Phase 5:        11/10 21:03:34  11/10 21:03:57  23 seconds
Phase 6:        11/10 21:03:57  11/10 21:04:00  3 seconds
Phase 7:        11/10 21:04:00  11/10 21:04:00

Total run time: 3 minutes, 49 seconds
done
[neutrino ide] executing /var/tuxbox/config/hddcheck.end
swapon: /dev/ide/host0/bus0/target0/lun0/part1: Device or resource busy
XFS mounting filesystem ide0(3,2)

msgbox  Message-Box Version 1.66
[controld] VIDEO_EVENT_SIZE_CHANGED 720x576 (4:3 -> 16:9)
[controld] format: 16:9

Wenn ich jetzt das HDD-Check Ergebnis Script ausführe, kommt nur noch ein "OK" button, allerdings keine Ergebnisse.

Danach hab ich das Serielle 0er verbunden und versucht die Kiste zum absturz zu bringen... wie gesagt, versucht. 15 Minuten intensives rumzappen im Moviplayer und die Kiste steht wie eine eins. Scheint auch so, als könne ich jetzt Aufnahmen löschen, ohne Minuten warten zu müssen.

Also war evtl. nur das Filesystem pflegebedürftig. Ich werde das mal weiter beobachten. Aber danke schonmal, vielleicht war es das ja.

Gruß, TDFKOlli

[DrStoned]

Wir haben schon vor einiger Zeit festgestellt, dass wir bei XFS-Check keine Ergebnisse mehr anzeigen lassen konnten, da es dadurch irgendwelche Fehler gab. Deswegen wurde die Log-Funktion für XFS-HDD-Check in eine Datei wieder rausgenommen. Aber wie Du schon bemerkt hast, kann man das immer noch auf der seriellen Schnittstelle anzeigen lassen. Das Anzeige-Plugin ist aber noch im Image, weil die LOG-Anzeige bei HDD-Check per EXT2 und EXT3 noch funktioniert.

Ich persönlich bevorzuge jedoch aus zweierlei Gründen EXT2 als Dateisystem:

1. EXT2 belastet den Prozessor am wenigsten bei der Aufnahme, wie ich mal durch Tests festgestellt habe. Am schlimmsten ist hier EXT3, dann kommt XFS, dann EXT2.
2. Da ich mittlerweile einen USB-Adapter in der Box habe, geht sowieso nur EXT2 und EXT3, zum Auslesen der Platte unter Windows. Siehe dazu auch http://www.jackthegrabber.de/viewtopic.php?f=29&t=11531

[TDFKAOlli]

So, ich habs jetzt eine weile beobachtet. Tatsächlich sind es jetzt deutlich weniger Abstürze durch den Movieplayer und die meisten Aufnahmen funktionieren jetzt auch. Allerdings gibt es immernoch einige wenige Aussetzer. Ich müßte jetzt mal einen im Log erwischen, aber das ist mir noch nicht geglückt und der Laptop steht auch nicht dauerhaft daneben
Grundsätzlich stelle ich mir aber schon die Frage, warum die Abstürze vom hddcheck abhängen. Eigentlich sollte dadurch die Box ja nicht abstürzen. Evtl. werden die Daten halt nicht schnell genug zur Verfügung gestellt, aber das sollte der Treiber doch eigentlich abkönnen. Letztendlich bleiben gelegentliche Abstürze.

Bzgl. XFS hatte ich "damals" dieses als am wenigsten Prozessorlastig ausgemessen und auch nur damit sind mir im Yadi damals störungsfreie Aufnahmen gelungen. Allerdings war das HD-Interface da auch grade erst raus, evtl. war da noch nicht alles so optimal abgestimmt.

[TDFKAOlli]

So,

einige Zeit vergangen, die Probleme immernoch groß. Kurz nach einem HDD check scheint es ein paar Tage gut zu funktionieren, aber dann wirds wieder schlechter.

Ich würde gerne jetzt das hddcheck direkt beim oder vor dem shutdown durchführen. Dann könnte ich das ein paar Wochen beobachten. Letztendlich habe ich aber kein Script mehr gefunden. Es gibt xfs_repair. Mit welchen Parametern wird das denn vom HDD menu aufgerufen? Kann ich das in das shutdown script packen (shutdown.in in /var/tuxbox/config/ ??)

Gruß, TDFKA

[jmittelst]

Dann würde ich mal schauen, was Du da Deinem Filesystem regelmässig antust.

Aktivierter Schreibcache kann z.B. eine Quelle des Übels sein. Wenn noch Daten im Cache sind, wenn die Box abschaltet, können die teilweise nicht mehr geschrieben werden und das Filesystem wird corrupt.

Auch das speichern des EPG bringt nach meiner Erfahrung solche Probleme schon einmal mit sich.

Auch ein Crash der Box oder ein Reset sind mögliche Quellen von Filesystem-Problemen, gerade wenn der Schreibcache aktiv ist.

Aber sinnvoll ist eigentlich nur, die Box mal mitzuloggen und so den Fehler genau zu lokalisieren.


Du könntest zwar einen HDD-Check zum Shutdown ausführen lassen, aber ob das wirklich sinnvoll ist, ist eine andere Frage.
Im Telnet kannst Du mit xfs_repair spielen. Alles, was da geht, geht auch aus einem Skript herraus an Parametern.
Vergiß aber nicht, das das Filesystem erst unmountet werden muß und das eine Unterbrechung des Checks in einer kritischen Phase vielleicht noch mehr Probleme bringen kann.

cu
Jens

[TDFKAOlli]

Der Schreibcache ist aktiviert. Letztendlich habe ich mit und ohne Schreibcache ausprobiert. Das Ergebnis bleibt das gleiche. Die Box stürzt halt öfters mal ab, bei der Aufnahme.

Letztendlich spielt der Festplattencache dabei auch keine Rolle. Das Dateisystem ist eh hin, wenn man nicht Ext3, RiserFS, JFS oder co benutzt. Solange die Festplatte Saft hat, schreibt die ihre Daten aus dem Cache noch raus. (Hat sich jemand mal ext4 bezüglich Performance angeschaut? Google hat zum Thema Vergleich-Prozessorlast nichts sinnvolles gefunden. Spielt für den standard PC vermutlich auch keine Rolle.)

Ergo wollte ich das Dateisystem automatisch reparieren (was jedes Linux system beim Start macht). Da der Check was länger dauert, würde ich das lieber beim Shutdown machen.

Und da xfs_repair kritisch ist wie du sagst, würde ich gerne die gleichen Parameter wie das JtG image verwenden, und nicht mit den Parametern spielen.

Deshalb nochmal meine Fragen: Welche Parameter werden für xfs_repair verwendet? In welches Script muß das für den shutdown gesetzt werden? (Ich habe kein "shutdown.*" in meinem config-Verzeichnis. Ich habe auch weder im Wiki noch hier im Forum einen Hinweis gefunden, wie es wohl heißen muß. Gibt es ein solches script überhaupt?).

Danke für den Hinweis, die HDD erst zu unmounten. Ich könnte mir vorstellen, dass das evtl bei shutdown garnicht durchgeführt wird und dabei das Dateisystem zerrupft?? Müßte auf jeden Fall vor den xfs_repair!

[Jeppdot]

Hallo,

Tante Google wirft zu

Code: Alles auswählen

man xfs_repair

jede Menge raus.

Das sieht imho interessant aus.

Gruß

[TDFKAOlli]

Hi,

Onkel Wikipedia sagt übrigens

XFS ist ein von der Firma Silicon Graphics (SGI) entwickeltes Journaling-Dateisystem für UNIX-artige Betriebssysteme wie Linux. Das bis Ende 1994 ausschließlich für IRIX entwickelte 64-Bit-Dateisystem überzeugt vor allem durch seine robuste Struktur und hohe Geschwindigkeit.

Dementsprechend ist es auch ein journaling filesystem und sollte eigentlich nicht kaputt gehen. Tja, was man noch so lernt an einem Samstag. Nur leider hilft das bei meinem Problem nicht weiter...

Und Jeppdot, schon klar. Ich wollte halt dieselben Parameter verwenden, die vom JtG Image verwendet werden. Andererseits, ein kurzer Blick in die xfs_repair Options deutet darauf hin, das keine der genannten Optionen gewählt werden muß. Ergo

Code: Alles auswählen

xfs_repair /dev/ide/host0/bus0/target0/lun0/part2

Jemand noch eine Idee wg. des shutdown scripts? Ist es "shutdown.in"?

Gruß

PS.: Bin noch über die neue Option für den Nokia Kabeltreiber gestoßen und hab den auch mal aktiviert. BER jetzt runter von 4000-6000 auf max 100. Vielleicht ist da ja noch ein zusammenhang.

[jmittelst]

Ein Script, was im Shutdown startet, könnte man z.B. in der Start_Neutrino einbauen.

XFS wird in der Dbox2 ohne Journal betrieben, deshalb nicht robust.

Empfangsqualität ist immer wichtig. Wobei viele BER i.d.R. eher darauf hindeuten, das man die Empfangsqualität verbessern sollte (z.B. Ausrichten der Schüssel, Austausch eines defekten LNB, Austausch oder Anpassung des KabelTV-Verstärkers, Austausch der Koax-Verkabelung, Austausch der Koax-Dosen, ...). Je nach Treiber-Version gibt es durchaus andere Werte, die aber nicht zwangsläufig vergleichbar sind. Sprich: ein BER von 1000 ist bei gleichem Treiber schlechter, als einer von 100. Bei unterschiedlichen Treibern muß das nicht so sein. Und soetwas kann eine Quelle für Crashes sein, muß es aber nicht.

Ohne Log ist das alles Stochern im Nebel.

cu
Jens

[TDFKAOlli]

Ein Script, was im Shutdown startet, könnte man z.B. in der Start_Neutrino einbauen.

O.k. ich schau mal.

XFS wird in der Dbox2 ohne Journal betrieben, deshalb nicht robust.

Gut, hat sich das auch geklärt

Empfangsqualität ist immer wichtig. Wobei viele BER i.d.R. eher darauf hindeuten, das man die Empfangsqualität verbessern sollte (z.B. Ausrichten der Schüssel, Austausch eines defekten LNB, Austausch oder Anpassung des KabelTV-Verstärkers, Austausch der Koax-Verkabelung, Austausch der Koax-Dosen, ...). Je nach Treiber-Version gibt es durchaus andere Werte, die aber nicht zwangsläufig vergleichbar sind. Sprich: ein BER von 1000 ist bei gleichem Treiber schlechter, als einer von 100. Bei unterschiedlichen Treibern muß das nicht so sein. Und soetwas kann eine Quelle für Crashes sein, muß es aber nicht.

Ist eine Kabelbox und die Sachen sind alle schon gecheckt. Hausverkabelung ist definitiv in Ordnung.

Der neue Kabeltreiber scheint die Sache stabilisiert zu haben, ist aber erst ein paar Tage alt, also mal schauen.

Ohne Log ist das alles Stochern im Nebel.

Wie gesagt, der Laptop steht nicht daneben die ganze Zeit. Das das Problem sporadisch auftritt, ist das schwer.

Ich hab ein NAS mit Linux im Keller stehen. Wenn ich den Log umleiten könnte, dann könnte ich bestimmt einen Log liefern. Ich hatte mal was übers Umleiten der logs gelesen, allerdings ging das nur mit einem Kommando in der ssh shell (setconsole). Könnte man das automatisieren und von der DBox aus starten, wenn die Box bootet? Oder den Log direkt umleiten? Evtl. ein script auf dem NAS... mal schauen ob ich da was gebastelt bekomme.