You are not logged in.

Dear visitor, welcome to Xtrend Support / GigaBlue Info. If this is your first visit here, please read the Help. It explains in detail how this page works. To use all features of this page, you should consider registering. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

61

Wednesday, January 25th 2012, 9:53pm

Inzwischen hab ich hier auch ein paar Aufnahmen gefunden die einen mehr oder weniger langen Aussetzer am Anfang der Datei Aufweisen, kurz nach Start der Aufnahme. Bislang beschränkt sich das anscheinend auf den Anfang im Vorlauf der Aufnahme, wird also eh rausgeschnitten, aber der Fehler tritt in leichter Form hier inzwischen auch auf. Werde das mal weiter im Auge behalten. (Harddisk intern Seagate ST1000LM010-9YH1 1TB, 2,5" , EXT4 ).

viele Grüße...

hippihoppi
Xtrend ET9000 (OpenAAF - L3.2.2) , Xtrend ET9200 (OpenATV 4.2), Xtrend ET6000 (OpenAAF . L3.3.0)

62

Wednesday, January 25th 2012, 10:33pm

Nur wenn man weiß, dass es auch ohne Anfangshänger geht, möchte man die natürlich auch nicht haben... Ich hatte die auch (und auch mitten in der Aufnahme), seit Umstieg auf ext2 ist alles gut, keine Probleme mehr!

63

Wednesday, January 25th 2012, 10:52pm

Ja, inzwischen hab ich auch in ein paar der Dateien mit Anfangsfreezer mittendrin Freezer gefunden. EXT2 kommt aber momentan für mich noch nicht in Betracht, eine "richtige" Lösung des Problems wäre mir lieber. Nach meinen bisherigen kurzen Tests kann ich aber schon mal sagen, die Anfangsfreezer haben definitiv nichts mit dem Hochfahren der Festplatte zu tun.
Xtrend ET9000 (OpenAAF - L3.2.2) , Xtrend ET9200 (OpenATV 4.2), Xtrend ET6000 (OpenAAF . L3.3.0)

64

Thursday, January 26th 2012, 7:25am

Hi Leute,

Milo hat einen Debug im E2 aktiviert, um den Zeitbedarf (Delay) für das Schreiben anzuzeigen.

Einfach auf das neueste OpenPLI updaten. Rebooten, dann per telnet init 4 ausführen und per Befehl "enigma*" - das * mit 2 ersetzen - die Debugausgabe aus der Konsole starten.
Wenn jetzt Aufnahmen aktiv sind, ist diese Zeile aktiv:

[eFilePushThreadRecorder] write (Anzahl Bytes) bytes time: (Zeit) us)

Vielleicht können die User mit EXT2 Formatierung und die mit Standard EXT4 Parametern ihre Werte hier posten. Z. B. hippihoppi.

Zusätzlich können folgende Parameter (gilt nur für User mit nativer EXT4 Formatierung) deaktiviert werden. Postet dann auch eure Ergebnisse, welchen Zeitbedarf durch die Anpassung eines Parameters erzielt wird und gibt an, ob die Hänger noch immer auftreten.

Quoted


Installation von tune2fs per telnet:
opkg install e2fsprogs-tune2fs

Per "mount" Befehl bestimmen, welchen Devicepfad eure HDD hat. Im Beispiel /dev/sda, damit sind auch eure derzeit aktiven EXT4-Parameter sichtbar!

Unmount der Festplatte, bitte keinerlei HDD-Aktivitäten dabei aktiv haben:

umount /dev/sda1

1. TEST:

Writeback mode setzen:
tune2fs -o journal_data_writeback /dev/sda1

2. TEST:

Journaling von EXT4 deaktivieren:

tune2fs -O ^has_journal /dev/sda1

3. TEST wieder den data_ordered Mode aktivieren. Wobei das Journaling weiterhin deaktiviert bleibt.

Ordered mode setzen:
tune2fs -o journal_data_ordered /dev/sda1


Abschließend den Befehl zum Mounten (nach jedem TESTlauf ) ausführen:
mount /dev/sda1 /media/hdd

65

Thursday, January 26th 2012, 10:37am

Hallo jbader,

danke fuer Ihre Anmerkungen, leider ist eine Information falsch.

Damit das E2 diese Zusatz Debugausgabe anzeigt, muss ein spezielles E2-Build erstellt werden, in der die Option "SHOW_WRITE_TIME" aktiviert wurde.
Im normalen E2-Build von OpenPLi ist dieses standardmaessig nicht aktiv.
Ihr Xtrend Support Team

66

Thursday, January 26th 2012, 2:31pm

Quoted


3. TEST wieder den data_ordered Mode aktivieren. Wobei das Journaling weiterhin deaktiviert bleibt.

naja, und im Test 3 soll data-ordered aktiviert werden (wohlgemerkt ein Journalmodus), wobei "Journaling weiterhin deaktiviert bleibt". Erklär bitte mal, wie Du das machst...

This post has been edited 1 times, last edit by "Bonsai Baum" (Jan 26th 2012, 5:09pm)


67

Thursday, January 26th 2012, 3:00pm

Hallo Bonsai Baum,

sollte etwas nicht passen, dann bitte ich um Berechtigung, wenn du auf dem Thema ein ausgewiesener Experte bist, dann kannst du dein Wissen gerne mit uns (der Community) teilen...

Quellen:

http://linux.die.net/man/8/tune2fs
http://git.kernel.org/?p=linux/kernel/gi…ystems/ext4.txt

-o [^]mount-option[,...]
Set or clear the indicated default mount options in the filesystem. Default mount options can be overridden by mount options specified either in /etc/fstab(5) or on the command line arguments to mount(8). Older kernels may not support this feature; in particular, kernels which predate 2.4.20 will almost certainly ignore the default mount options field in the superblock.
journal_data
When the filesystem is mounted with journalling enabled, all data (not just metadata) is committed into the journal prior to being written into the main filesystem.
journal_data_ordered
When the filesystem is mounted with journalling enabled, all data is forced directly out to the main file system prior to its metadata being committed to the journal.
journal_data_writeback
When the filesystem is mounted with journalling enabled, data may be written into the main filesystem after its metadata has been committed to the journal. This may increase throughput, however, it may allow old data to appear in files after a crash and journal recovery.

has_journal
Use a journal to ensure filesystem consistency even across unclean shutdowns. Setting the filesystem feature is equivalent to using the -j option.


Data Mode
---------
There are 3 different data modes:

* writeback mode
In data=writeback mode, ext4 does not journal data at all. This mode provides
a similar level of journaling as that of XFS, JFS, and ReiserFS in its default
mode - metadata journaling. A crash+recovery can cause incorrect data to
appear in files which were written shortly before the crash. This mode will
typically provide the best ext4 performance.

* ordered mode
In data=ordered mode, ext4 only officially journals metadata, but it logically
groups metadata and data blocks into a single unit called a transaction. When
it's time to write the new metadata out to disk, the associated data blocks
are written first. In general, this mode performs slightly slower than
writeback but significantly faster than journal mode.

* journal mode
data=journal mode provides full data and metadata journaling. All new data is
written to the journal first, and then to its final location.
In the event of a crash, the journal can be replayed, bringing both data and
metadata into a consistent state. This mode is the slowest except when data
needs to be read from and written to disk at the same time where it
outperforms all others modes.

68

Thursday, January 26th 2012, 3:03pm

naja, und im Test 3 soll data-ordered aktiviert werden (wohlgemerkt ein Jornalmodus), wobei "Journaling weiterhin deaktiviert bleibt". Erklär bitte mal, wie Du das machst...

vielleicht mal die Linux-Manuals lesen... Aber das hat ja jbader schon ausführlich beschrieben :-)
Moderator im Boardrebellen-Forum

69

Thursday, January 26th 2012, 3:57pm

Hallo Bonsai Baum,

sollte etwas nicht passen, dann bitte ich um Berechtigung, ...

Welche Berechtigung brauche ich denn dafür?
Aber vielleicht hier die Nachfrage: was testest Du denn mit dem 3. Testlauf?

This post has been edited 2 times, last edit by "Bonsai Baum" (Jan 26th 2012, 4:47pm)


70

Thursday, January 26th 2012, 4:17pm

Hallo Bonsai Baum,

sollte etwas nicht passen, dann bitte ich um Berechtigung, ...

Welche Berechtigung brauche ich denn dafür?

Könnte jemand meinen, dass es wieder um die Rechtschreibung geht :-( Aber naja, lieber Bonsai lösche doch lieber mal wieder Posts im eigenen Forum... Ich glaube alle Anderen haben verstanden um was es geht. Leider wurde nichts über die Kenntnisse der Journaling-Fähigkeiten deinerseits hier beigetragen. Ich würde fast mal sagen, dass sind schon wieder provokante und rassistische Posts :thumbsup:
OpenPLi - first choice for Xtrend-STB´s

71

Thursday, January 26th 2012, 5:07pm

Nabend Allerseits...

auch wenn die Frage von "Bonsai Baum" etwas forsch war kann man doch im Ton bitte etwas ruhiger bleiben. Letzendlich war die Fragestellung sachlich. Seitenhiebe auf andere Foren gehören hier doch bitte auch nicht hin.

Vielen Dank! :)

Gruß

Klaus
A common mistake people make when trying to design something completely foolproof was to underestimate the ingenuity of complete fools.

From Mostly Harmless by Douglas Adams

72

Friday, January 27th 2012, 10:29am

Um das auch hier zu posten...

Milo + Pieterg haben sich auch mit dem Thema beschäftigt und können auch Aussetzer beim schreiben auf die Platte feststellen.

Der betreffende Post: http://openpli.org/forums/topic/21926-ex…post__p__249644

Und hier der Text:

Quoted

Did a timing test, which goes like this:

enigma outputs the time it spends in each "write" call. This is typically 2..3 ms to write a 188k data block.

While doing so, i delete a 2G file from the disk, and rewrite it with DD. This causes some delays in the write() call as it has to compete with the other process for harddisk attention.

When the filesystem is mounted as ext4 with "data=ordered", the longest delays I've seen were 2 seconds. That is enough to cause a buffer overrun (the situation is rather extreme, you wouldn't be deleting and writing huge files while recording).

When mounting with "data=writeback", I did not get such extreme delays any more. The longest I got was about 200ms, which can easily be compensated for and doesn't cause an overrun. This option may result in "random" data occurring in files after power loss, but not much else.

Just for the heck of it, I deleted the journal and tried again. This basically turns the disk into sort of ext2. With the journaling disables, I couldn't get it to stall longer than just over 15ms. So that's something to try if you're using ext2 mount now. Note that this also means that you should run a fsck after any unexpected power failure or kernel panic, or you may suffer severe system corruption...

The commands you'll find useful (unmount the disk before using any of these commands, you can re-mount it after that without rebooting):

Install tune2fs:
opkg install e2fsprogs-tune2fs

Disable journal:
tune2fs -O ^has_journal /dev/sda1

Set writeback mode:
tune2fs -o journal_data_writeback /dev/sda1

Set ordered mode:
tune2fs -o journal_data_ordered /dev/sda1
Die (aus meiner Sicht) entscheidende Punkte:

  • ext4 im ordered-Mode führt dann und wann zu Delays von bis zu 2 Sek. Dies kann dazu führen, dass der Buffer von 1.5 MB überläuft.
  • Die Verwendung von ext2 minderr das Problem merklich, es wird aber empfohlen nach jedem Crash einen fschk laufen zu lassen. da nach einem Crash das Dateisystem "korrupt" sein kann.
  • Die Verwendung von ext4 im Writeback-Mode lindet das Problem ebenfalls.
Gruß
Klaus
A common mistake people make when trying to design something completely foolproof was to underestimate the ingenuity of complete fools.

From Mostly Harmless by Douglas Adams

73

Saturday, February 18th 2012, 11:20am

Sehr geehrte Xtrend-Anwender,

bitte updaten Sie Ihr OpenPLi-Image ab Morgen und testen erneut, ob Sie weiterhin die genannten Frezzer-Probleme mit ext4 Dateisystemen feststellen koennen:

Quelle: http://openpli.git.sourceforge.net/git/g…c864c188d1851cf
Ihr Xtrend Support Team

Stigarta

Unregistered

74

Sunday, February 19th 2012, 11:48am

Sehr geehrte Xtrend-Anwender,

bitte updaten Sie Ihr OpenPLi-Image ab Morgen und testen erneut, ob Sie weiterhin die genannten Frezzer-Probleme mit ext4 Dateisystemen feststellen koennen:

Quelle: http://openpli.git.sourceforge.net/git/g…c864c188d1851cf


Hat schon einer der Freezergeplagten getestet, ob das Update geholfen hat?

Stigarta

Unregistered

75

Sunday, February 19th 2012, 12:42pm

Hier die erste positive Meldung:

Ich hatte nie Freezer in laufenden Aufnahmen.
Nur wenn ich eine Aufnahme manuell gestartet habe und die Festplatte aus dem Standby kam, hatte ich einen ganz kurzen Freezer.
Diesen Freezer habe ich nun nicht mehr.
Habe gerade eine Aufnahme manuell gestartet, die Festplatte kam aus dem Standby und es gab keinen Freezer.
Dies habe ich mehrfach getestet.

Danke ans Pli Team und an alle Beteiligten die sich monatelang mit dem Thema auseinandergesetzt haben :thumbsup:

76

Sunday, February 19th 2012, 12:44pm

ich habe gerade mal intensiv getestet. 5 HD-Aufnahmen plus TS. Dazwischen immer mal wieder einzelne Aufnahmen geöffnet , vor- und zurückgespult oder gesprungen. Das Ganze ungefähr 15 Min. Anschließend habe ich die drei Aufnahmen mit der höchsten Datenrate auf den PC gezogen und geprüft. Das Ganze mit ext4 und abgeschalteten Journaling.

Die erste Aufnahme zeigte den typischen Fehler mit dem Freezer ganz am Anfang, der Rest war, wie auch bei den anderen Aufnahmen fehlerfrei.

Es sieht für mich so aus, als sei das generelle Problem mit den Freezern behoben. Muss man aber noch abwarten, was andere berichten. Der Fehler mit der Lücke ganz am Anfang ist noch drin.

Gruß

Klaus
A common mistake people make when trying to design something completely foolproof was to underestimate the ingenuity of complete fools.

From Mostly Harmless by Douglas Adams

77

Sunday, March 11th 2012, 9:45am

Hi,



heute nochmal mit neustem Online



OpenPLI-Update und



danach einen STB-Reboot mal erneut

mit EXT4 Dateisystem testen.
--------------- Xtrend United ----------------------

78

Wednesday, April 18th 2012, 9:20pm

Hi,

pieterg hat die ext2 und ext3-Module wieder verfügbar gemacht. Für diejenigen, die ihre HDD noch auf dem uralten EXT2 haben.

Ab morgen auf dem Feed :-)

http://openpli.git.sourceforge.net/git/gitweb.cgi?p=openpli/openembedded;a=commit;h=4a266bfac95e56aa6e8b5d2a434a159587ee7783
Moderator im Boardrebellen-Forum

79

Thursday, April 19th 2012, 8:20am

Ich habe mir gestern mal eine meiner letzten Aufnahmen angeschaut und mußte feststellen, daß ich plötzlich mittendrin leichte Freezer (ca. 2 sec.) hatte. Kommt das durch die neuen Treiber?...vorher hatte ich dieses Problem schon lange nicht mehr. Ich bin mit den OpenPli-updates immer auf dem neusten Stand.
LG Kuckuck






Receiver: CT ET 9100/ 1TB Samsung ECOGreen ...............Image: OpenPLI 3.0 :thumbsup:

XtrendIM

Administration+Technik+Support

Posts: 3,696

Location: Europa

  • Send private message

80

Thursday, April 19th 2012, 9:10am

Hallo kuckuck,

diese Probleme werden nicht durch die Treiber verursacht. Mit dem neuen Linux-Kernel 3.x ist die Schreibperformance mit EXT4 deutlich verbessert.
Auf welchen Sendern wurden die "Freezer" festgestellt? Sind die Sender FTA? Welche HDD wird verwendet. Wie wurde die HDD formatiert?
Ihr Xtrend Support-Team
eXtrending your vision