196 replies to this topic

[dvboxer]

No it doesn't. Tested it yesterday although not with dd but with recording from ARD HD which had glitches/freezers.

[dvboxer]

No it doesn't. Tested it yesterday although not with dd but with recording from ARD HD which had glitches/freezers.

I always had these freezers only in the first few seconds of a HD recording when there hadn't been any recording before that since booting. So I assume that my problem never has been scheduler related. That's also what I heard from most others. A few dm-users had problems continuously which turned out to be a hdd-standby problem. We fixed this by adding the option to use hardware standby (hdparm -S x) instead of the soft standby offered by e2

[kubrick]

I can confirm dvboxer's and stefan's issue regarding freezers in recordings which had been made the first time after (re)booting the box (et9000, ext4, no journal, writeback-tuning, only the first few seconds, hdd isn't in standby).

[Stefan_Salewski]

MiLo wrote:
>You realize you did not write that "test.txt" to the harddisk

Sorry -- tested again after reboot, the file /media/hdd/blanks2 was still existent from yesterday.
Again, the first dd is slower.

root@vus:~# reboot;exit

Broadcast message from root (pts/0) (Sun Feb 19 13:26:24 2012):

The system is going down for reboot NOW!
Connection to vus closed.
stefan@AMD64X2 ~ $ ssh root@vus
root@vus's password:
root@vus:~# cd /media/
root@vus:/media# cat /sys/block/sda/queue/iosched/slice_idle
1
root@vus:/media# echo "test" > /media/hdd/test.txt
root@vus:/media# cat /media/hdd/test.txt
test
root@vus:/media# dd if=/dev/zero of=/media/hdd/blanks2 bs=1024k count=100
100+0 records in
100+0 records out
104857600 bytes (100.0MB) copied, 4.064899 seconds, 24.6MB/s
root@vus:/media# dd if=/dev/zero of=/media/hdd/blanks2 bs=1024k count=100
100+0 records in
100+0 records out
104857600 bytes (100.0MB) copied, 2.397190 seconds, 41.7MB/s
root@vus:/media# rm /media/hdd/blanks2
root@vus:/media# dd if=/dev/zero of=/media/hdd/blanks2 bs=1024k count=100
100+0 records in
100+0 records out
104857600 bytes (100.0MB) copied, 1.800398 seconds, 55.5MB/s
root@vus:/media#

[dvboxer]

By the way the workaround I use now is to do the dd directly after booting. So I don't have freezers anymore. The following line is put at the end of /etc/init.d/bootmisc.sh

(sleep 15; if (mount | grep -q media/hdd) ; then dd if=/dev/zero of=/media/hdd/blanks2 bs=1024k count=100; rm /media/hdd/blanks2;fi)&

Edited by dvboxer, 19 February 2012 - 15:55.

[stb155]

Ich habe vor ein paar Tagen online Update gemacht und dann die Festplatte auf ext4 umgestellt und neu formatiert/initialisiert.
Geändert hat sich nichts, nach wie vor kann ich kaum eine Aufnahme fehlerfrei abspielen.
Immer wieder kleine Freezer/Hacker in Bild und Ton.
Mehrmals pro Aufnahme bleibt es nicht bei einem kleinen Freeze sondern es kommen immer mehr Artefakte und Tonstörungen bis ich kurz zurückspule und dann weider starte.
Scheint ein reines Abspielproblem zu sein, denn wenn ich zurückspule läuft die Stelle dann zu 99% Störungsfrei.

Weitere Probleme bei denen ich nicht weis ob sie die selbe Ursache haben oder nicht:
ca.1x pro Woche friert das Bild bei normaler Wiederghabe ein und die Box reagiert auf nichts mehr von der Fernbedienung (hilft nur Telnet reboot oder Power OFF)
Gestern habe ich eine Aufnahme angesehen (2Aufnahmen liefen in Hintergrund) habe dann bei einer Werbung versehentlich statt 3x "rechts" 3x auf "oben" gedrückt. (Box hätte also ins Aufnahmeverzeichniss gehen müssen)
Ergebniss war aber ein Greenscreen mit Reboot, dann lief wieder alles normal weiter.

Box ist bei mir eine VU+DUO mit 1TB.
Problem betrifft Aufnahmen von allen Sendern und ist je nach "Tagesform" unterschiedlich stark.
Mal muss ich alle 5 Min. zurückspulen, mal läuft es 1h stabil.
Reboot hilft manchmal aber nicht immer.

[pieterg]

Mal muss ich alle 5 Min. zurückspulen, mal läuft es 1h stabil.

this sounds more like a playback problem to me, not a recording problem.
This thread is about ext4 write latency problems, which of course only affect recording.

There are other threads about your particular problem, (almost?) all VU+DUO users do have this problem since VU+'s 3.x driver release.

[stb155]

Danke.

Wie es aussieht habe ich beides.
Bei mehreren Aufnahmen von den letzten Tagen habe ich kleine Freezer die auch nach zurückspulen oder reboot wieder an der selben Stelle kommen.

[kubrick]

@dvbboxer: thank you!


I just did some tests:

root@et9000:~# (if (mount | grep -q media/hdd) ; then dd if=/dev/zero
of=/media/hdd/blanks2 bs=1024k count=100; rm /media/hdd/blanks2;fi)

100+0 records in
100+0 records out
104857600 bytes (100.0MB) copied, 125.103376 seconds, 818.5KB/s (-> first write attempt after reboot (!))

root@et9000:~# (if (mount | grep -q media/hdd) ; then dd if=/dev/zero o
f=/media/hdd/blanks2 bs=1024k count=100; rm /media/hdd/blanks2;fi)

100+0 records in
100+0 records out
104857600 bytes (100.0MB) copied, 2.082380 seconds, 48.0MB/s (-> second write attempt after reboot)

Those tests basically confirm the issue I already wrote about.

Edited by kubrick, 3 March 2012 - 14:33.

[dvboxer]

Wow, 818.5KB/s, you are much worse off than me.

[MiLo]

I have no idea (yet) about the first write being so slow.

However, after today's changes, I could not get the 9x00 to overrun on a ext3 disk mounted with the ext4 driver with all the "bad" things (delalloc, data=ordered) while running 6HD and 2SD recordings simultaneously.

(to determine if you get an overrun, just run enigma2 in foreground, if you see the text OVERRUN appear, you've hit the jackpot...)

[Topfi]

Moin,
an diejenigen, die diese extrem kleinen Werte haben: Habt Ihr zufällig eine WD Platte mit "Advanced Format Technology" im Einsatz?
Damit kommt es unter Linux unter bestimmten Umständen zu Problemen.

[dvboxer]

Hi Topfi

Moin,
an diejenigen, die diese extrem kleinen Werte haben: Habt Ihr zufällig eine WD Platte mit "Advanced Format Technology" im Einsatz?
Damit kommt es unter Linux unter bestimmten Umständen zu Problemen.

Ne ich nicht: Harddisk (ATA(SAMSUNG HD103SI))

[Topfi]

Hi dvboxer,
Deine Platte hat AFAIK aber auch 4k Sektorengröße.
Guck mal mit fdisk -u -l ob Deine Partition bei einem Vielfachen von 8 beginnt.
Wenn nicht, könnte das die Ursache Deines Problems sein.

[dvboxer]

root@vuduo:~# fdisk -u -l
 
Disk /dev/mtdblock0: 123 MB, 123731968 bytes
255 heads, 63 sectors/track, 15 cylinders, total 241664 sectors
Units = sectors of 1 * 512 = 512 bytes
 
Disk /dev/mtdblock0 doesn't contain a valid partition table
 
Disk /dev/sda: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors
Units = sectors of 1 * 512 = 512 bytes
 
Device Boot	  Start		 End	  Blocks  Id System
/dev/sda1	   8   1953520064   976760028+ 83 Linux

8 ist ein Vielfaches von 8

Edited by dvboxer, 17 March 2012 - 13:41.

[Topfi]

root@vuduo:~# fdisk -u -l
 
Disk /dev/mtdblock0: 123 MB, 123731968 bytes
255 heads, 63 sectors/track, 15 cylinders, total 241664 sectors
Units = sectors of 1 * 512 = 512 bytes
 
Disk /dev/mtdblock0 doesn't contain a valid partition table
 
Disk /dev/sda: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors
Units = sectors of 1 * 512 = 512 bytes
 
Device Boot	  Start		 End	  Blocks  Id System
/dev/sda1	   8   1953520064   976760028+ 83 Linux

8 ist ein Vielfaches von 8

Jo, dann liegt's wohl nicht daran.
Komisch. Hast Du schonmal eine andere HDD ausprobiert?

[dvboxer]

Ne hab ich nicht. Ich komme ja gut klar mit meinem Workaround oben.

[kubrick]

Hi Topfi,
ich hab zwar eine Advanced Format-Festplatte WD EARS 2TB, habe sie aber geeignet formatiert:

Device Boot Start End Blocks Id System
/dev/sda1 56 3907016959 1953508452 83 Linux
Auch ich habe seit dem Einbau des Workarounds von dvboxer die Probleme nicht mehr.

[MiLo]

Something that may be interesting: If you run enigma2 in the console, it now outputs a "histogram" of the buffer usage during recording after the recording ends. That way you can quickly get a feeling for how "stressed" the system has been while running for example 8 HD recordings. It also outputs a "warning" message immediately when things are getting really tight.

Edited by MiLo, 19 March 2012 - 19:16.

[kubrick]

Thanks MiLo!


[eDVBRecordFileThread] buffer usage histogram (20 buffers of 188 kB)
0: 1516
1: 7655
2: 44

Could you tell us what do the numbers mean?