196 replies to this topic

[MiLo]

In your case, it allocated 20 buffers of 188k each (about 4MB total). During the recording, every time that a buffer is sent to the disk, the program counts how many buffers are still "on the way" to the disk. "0: 1516" means that in 1516 cases the buffer was already returned to the program before counting them. "2: 44" means that in 44 cases, there were 2 buffers in use. Which basically means that your recording never used more than 2 buffers of the 20 available, of 10%. Which means that the system is performing excellent - the lower the number of buffers spent, the better.

If you see "20: .." listed, it means that all buffers were full, and that there is a risk of overflowing the demux buffer (which is ~4 buffers in size itself) which would cause a glitch in the recording.

If you start some heavy disk traffic or if you run lots of simultaneous recordings, of if the media you record to is very slow (e.g. an old USB stick), you can get into the higher regions.

[dvboxer]

This is my result

[eDVBRecordFileThread] buffer usage histogram (10 buffers of 188 kB)				  
	  1:    110																	   
	  2:    104																	   
	  3:	  3																	   
	  4:	  1																	   
	  5:	  1																	   
	  6:	  1																	   
	  7:	  1																	   
	  8:	  1																	   
	  9:	  2																	   
	 10:	  4																	   
[eFilePushThreadRecorder] THREAD STOP												 

40 seconds of HD recording (with freshly mounted hdd to avoid that my workaround kicks in). As one would expect, there are glitches.

[kubrick]

Wow! This may be truly helpful...
Thanks MiLo, I really appreciate your help.

[dvboxer]

And this is the result for the second recording (same station 44 seconds):
[eDVBRecordFileThread] buffer usage histogram (10 buffers of 188 kB)
0: 2
1: 143
2: 140
[eFilePushThreadRecorder] THREAD STOP

[hd-tester]

hi,
hier eine Nachricht von Linus "Linux" Torwald,
ev. hilft das ja bei dem Problem

Linux-Kernel 3.3 freigegeben

Linus Torvalds hat den Linux-Kernel 3.3 veröffentlicht, der unter anderem einige Probleme beseitigen soll, die gelegentlich zu Systemaussetzern beim Schreiben auf langsame Datenträger führen. Dutzende neuer und überarbeiteter Treiber verbessern die Hardware-Unterstützung; so gibt es Fortschritte bei den Open-Source-Treibern für AMD-, Intel und Nvidia-Grafik. In den Staging-Bereich für "unreife" Treiber sind eine Reihe Android-spezifischer Treiber zurückgekehrt, die vor zwei Jahren rausgeflogen waren, weil sich niemand darum gekümmert hatte.
Software-RAIDs unterstützten jetzt Hot Replace, sodass nach dem Austausch einer Platte kein Rebuild-Lauf mehr nötig ist. Auch der RAID-Support in Btrfs wurde verbessert. Das Netzwerk-Subsystem erhielt einige neue Funktionen und Erweiterungen, darunter einen virtuellen Switch, der auf den Layern 2, 3 oder 4 arbeiten kann. Linux 3.3 bietet bereits Basis-Unterstützung für das neue ACPI 5.0.


Quelle: heise.de
http://www.heise.de/...en-1467641.html

Edited by hd-tester, 20 March 2012 - 13:07.

[dvboxer]

hi,
hier eine Nachricht von Linus "Linux" Torwald,
ev. hilft das ja bei dem Problem

Nach dem Changelog zu urteilen eher nicht.

[littlesat]

eDVBRecordFileThread] buffer usage histogram (10 buffers of 188 kB)

Strange... as I would expect you should have 20 buffers???

[dvboxer]

eDVBRecordFileThread] buffer usage histogram (10 buffers of 188 kB)

Strange... as I would expect you should have 20 buffers???

in demux.cpp:

static int determineBufferCount()
...
    else if (megabytes > 100)
	    result = 10; // 256MB systems: Use 2MB demux buffers (dm8000, et5x00, vuduo)

I have a vu duo

[littlesat]

So it seems the VU Duo has too limited RAM memory?

[MiLo]

Think I need to use a VUDuo for testing. Even the 7025 does better...

And the Duo has about the least available memory of all HD boxes. Even though the machine has 384MB, the decoders use up so much of it that the boxes with 256 installed RAM have more userspace.

[littlesat]

the decoders use up so much of it

Is this the way the drivers are build?

[dvboxer]

So it seems the VU Duo has too limited RAM memory?

I doubt that. Apart from this initial-writing-speed-too-low problem there are no issues (I don't have pay tv, though.) And remember:[list]
[*]writing speed is totally normal after a few dozens of megabytes (about 50Mb/s).
[*]kubrick seems to have the same problem on another machine type (with 20 buffers)
[*]problem doesn't occur with ext2 driver.
[*]problem started after update to 3.x kernel
[/list]

[MiLo]

[list]
[*]kubrick seems to have the same problem on another machine type (with 20 buffers)
[/list]

He does not. Of if he does, he did not mention it here. (the "20 buffers" have only been around for a few days)

[list]
[*]problem doesn't occur with ext2 driver.
[/list]

It still does, it just becomes less noticable if you turn off journalling and delayed allocation.

[dvboxer]

[list]
[*]kubrick seems to have the same problem on another machine type (with 20 buffers)
[/list]

He does not. Of if he does, he did not mention it here. (the "20 buffers" have only been around for a few days)

I was referring to this post:

Auch ich habe seit dem Einbau des Workarounds von dvboxer die Probleme nicht mehr.

Where he says that his problems are gone since he uses my workaround. And that he had these perfect results in the histogram is probably also due to the workaround. I also have this perfect result with my workaround.

[list]
[*]problem doesn't occur with ext2 driver.
[/list]

It still does, it just becomes less noticable if you turn off journalling and delayed allocation.

That may be, I don't know. But it's a fact that the problem I have occurs only at the writing of the first few dozens of megabytes after mounting. Then they are gone. I have a hard time explaining that if it is not related to some initialization of the ext4 driver.

[kubrick]

I just did some tests (ET9000, ext4, no journaling, writeback, WD EARS 2TB HDD, properly formatted)

1. Very first recording after "umount/mount /hdd" (1 minute, Discovery HD):

EMC: [MC] Timer started - add recording
warning, skin is missing element text in <class 'Screens.InputBox.InputBox'>
after:
[<RecordTimer.RecordTimerEntry object at 0x72257cb0>]
PATready
use pmtpid 0063 for service_id 0082
RECORD service event 5
start recording...
RECORD: have 1 video stream(s) (03ff), and 1 audio stream(s) (0403), and the pcr pid is 03ff, and the text pid is 0020
ADD PID: 0063
[TIMER] record event 4
[TIMER] record event 6
[eDVBCAService] add demux 0 to slot 1 service 1:0:19:82:6:85:C00000:0:0:0:
[eDVBCIInterfaces] gotPMT
demux 0 mask 01 prevhash 6301020001
pcr of eit change: e3ae6d41
[eDVBServiceRecord] now running: Der gef&#195;&#164;hrlichste Job Alaskas - Die Serie (2400 seconds)
[TIMER] record event 9
EMC: [MC] LOAD PATH:
/hdd/movie/20120321 0022 - Discovery HD - Der gef&#195;&#164;hrlichste Job Alaskas - Die Serie.ts
action ->  WizardActions ok
stopping recording after 1 minutes.
time changed
Timeout!
[eFilePushThreadRecorder] OVERFLOW while recording
[eFilePushThreadRecorder] OVERFLOW while recording
[TIMER] activating state 3
[TIMER] stop recording
stop recording!
[eFilePushThreadRecorder] stopping thread.
main thread is non-idle! display spinner!
[eDVBRecordFileThread] waiting for aio to complete
[eDVBRecordFileThread] buffer usage histogram (20 buffers of 188 kB)
	  0:	 72
	  1:	364
	  2:	  3
[eFilePushThreadRecorder] THREAD STOP
thread joined 0
loading streaminfo for /hdd/movie/20120321 0022 - Discovery HD - Der gef&#195;&#164;hrlichste Job Alaskas - Die Serie.ts
fixed up e3ae6d41 to 19e31 (offset 0)
[TIMER] record event 5
[TIMER] record event 1
[remove callback]
[eDVBCAService] free slot 0 demux 0 for service 1:0:19:82:6:85:C00000:0:0:0:
demux 0 mask 01 prevhash 6301020003
[eDVBCAService] don't build/send the same CA PMT twice
EMC: [emcRC] REC END for: 20120321 0022 - Discovery HD - Der gef&#195;&#164;hrlichste Job Alaskas - Die Serie
EMC: [MC] Timer ended
ERROR reading PES (fd=56) - Value too large for defined data type
poll: unhandled POLLERR/HUP/NVAL for fd 56(8)
main thread is non-idle! display spinner!
ERROR reading PES (fd=56) - Value too large for defined data type
poll: unhandled POLLERR/HUP/NVAL for fd 56(8)

Resulting file is only 38 seconds long and has glitches (80 MB).

[kubrick]

2. Second recording after umount/mount /hdd:

RECORD service event 5
start recording...
RECORD: have 1 video stream(s) (03ff), and 1 audio stream(s) (0403), and the pcr pid is 03ff, and the text pid is 0020
ADD PID: 0063
[TIMER] record event 4
[TIMER] record event 6
[eDVBCAService] add demux 0 to slot 1 service 1:0:19:82:6:85:C00000:0:0:0:
[eDVBCIInterfaces] gotPMT
demux 0 mask 01 prevhash 6301020001
pcr of eit change: e59a6501
[eDVBServiceRecord] now running: Der gefährlichste Job Alaskas - Die Serie (2400 seconds)
[TIMER] record event 9
EMC: [MC] LOAD PATH:
/hdd/movie/20120321 0028 - Discovery HD - Der gefährlichste Job Alaskas - Die Serie.ts
action ->  WizardActions ok
stopping recording after 1 minutes.
time changed
Timeout!
[TIMER] activating state 3
[TIMER] stop recording
stop recording!
[eFilePushThreadRecorder] stopping thread.
[eDVBRecordFileThread] waiting for aio to complete
[eDVBRecordFileThread] buffer usage histogram (20 buffers of 188 kB)
	  0:	 83
	  1:	450
	  2:	  3
[eFilePushThreadRecorder] THREAD STOP
thread joined 0
loading streaminfo for /hdd/movie/20120321 0028 - Discovery HD - Der gefährlichste Job Alaskas - Die Serie.ts
fixed up e59a6501 to 141ed (offset 0)
[TIMER] record event 5
[TIMER] record event 1
[remove callback]
[eDVBCAService] free slot 0 demux 0 for service 1:0:19:82:6:85:C00000:0:0:0:
demux 0 mask 01 prevhash 6301020003
[eDVBCAService] don't build/send the same CA PMT twice
EMC: [emcRC] REC END for: 20120321 0028 - Discovery HD - Der gefährlichste Job Alaskas - Die Serie
EMC: [MC] Timer ended

Resulting file is 63 seconds long and there are no glitches at all (98 MB)

Edited by kubrick, 21 March 2012 - 02:36.

[dvboxer]

@MiLo: Can you build a debug kernel? Maybe I could use it to get some insight on what's going on.

[MiLo]

There are a few dozen "debug" options in the kernel... which do you want?

[dvboxer]

There are a few dozen "debug" options in the kernel... which do you want?

Everything related to filesystems.

[mblum11]

Hello PLI team,

is there a reason for not provide the ext2 and ext3 modules in actual build with 3.3 kernel ?
The work arrounds (UUID mounts) for the 3.2.2 kernel are now no longer working and the ext2 and ext3 filesystems
mounted with ext4 module. In some recordings since last week the freezers come back...