Stefan_Salewski

no, there is no fix for this issue yet

Some more details for Vu+ DUO, OpenPLI 3.0:
Currently I am recording ZDF-HD, and I can watch BR-alpha (non HD) on german Astra 19.2. But I can not record BR-apha -- conficting timer is reported. So problem seems to be not related to Tuners itself.

Here in a Dutch thread the same issue: http://openpli.org/f...timer-conflict/

Similar problems with two VU+ DUO boxes, one updated yesterday, one today. OpenPLI 3.0.
Recording of two overlapping recordings of the same channel (RTL) was not possible -- which should work even with only one tuner. (I have two tuners available, working fine with OpenPli 3.0 before.) The problem occurs also with different channes, but for some combinations it seems to work with no conflicts.

Das war eine ernsthafte Frage.
Was bringt der Kernel 3.2 gegenüber 3.1?

The 3.2 kernel supports large block allocation, which increases performance for large files.

See post of MiLo:

http://openpli.org/f...799#entry255799

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#

I can confirm that the first dd command after reboot is much slower. I have formated the partition with ext4 and mounted ext4. This is a Vu-Duo box, with latest Pli software update and SAMSUNG HD204UI disk. I did echo "test" > test.txt to ensure that the disk is not in standby. (I have only minimal Ruckler/Hänger/Glitches.)

root@vus:/media# echo "test" > test.txt
root@vus:/media# ls
hdd net sda1 sda2 sda3 sda4 test.txt
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.445641 seconds, 22.5MB/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, 1.890970 seconds, 52.9MB/s
root@vus:/media# rm 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.706991 seconds, 58.6MB/s
root@vus:/media#
root@vus:/media# tune2fs -l /dev/sda4
tune2fs 1.42 (29-Nov-2011)
Filesystem volume name: <none>
Last mounted on: /media/hdd
Filesystem UUID: e4708530-2fb0-449b-b887-10368af19717
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 100999168
Block count: 403968022
Reserved block count: 20198401
Free blocks: 320526603
Free inodes: 100998724
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 927
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
Flex block group size: 16
Filesystem created: Wed Feb 1 15:16:03 2012
Last mount time: Thu Jan 1 01:00:04 1970
Last write time: Thu Jan 1 01:00:04 1970
Mount count: 34
Maximum mount count: 29
Last checked: Wed Feb 1 15:16:03 2012
Check interval: 15552000 (6 months)
Next check after: Mon Jul 30 16:16:03 2012
Lifetime writes: 523 GB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: 729ae560-aaa9-4794-9c11-8fd8d99ea7cb
Journal backup: inode blocks
root@vus:/media# cat /etc/fstab
rootfs / auto defaults 1 1
proc /proc proc defaults 0 0
devpts /dev/pts devpts mode=0620,gid=5 0 0
usbfs /proc/bus/usb usbfs defaults 0 0
tmpfs /var/volatile tmpfs defaults 0 0
/dev/sda4 /media/hdd ext4 defaults 0 0
/dev/sda1 none swap sw 0 0
root@vus:/media#
I hope the echo "1" > /sys/block/sda/queue/iosched/slice_idle will help, and I will reformat the disk for large blocks when kernel 3.2 is available for Vu-Duo.

Best regards,

Stefan Salewski