Leider in der falschen Klasse, ich habe bei mir aus
Codevoid cThread::SetIOPriority(int Priority){ if (syscall(SYS_ioprio_set, 1, 0, (Priority & 0xff) | (2 << 13)) < 0) // best effort class LOG_ERROR;}
folgendes gemacht (wie bei markad)
Codevoid cThread::SetIOPriority(int Priority){ if (syscall(SYS_ioprio_set, 1, 0, (Priority & 0xff) | (3 << 13)) < 0) // idle class LOG_ERROR;}
seitdem ist der VDR richtig smooth - braucht aber auch zig Minuten (!) fürs Schneiden einer SD-Aufnahmen
Ich habe das mal probiert und sage nur, wow ...
Das löst tatsächlich das eine sehr lange schwelendes Problem auf einem meiner VDRs. Auf dem war es nun lange Zeit nicht möglich Aufnahmen zu schneiden ohne das laufende Aufnahmen gestört waren, bei HD Schnitten, war die Störungen eben länger, weil die auch länger dauern, wie auch HD Aufnahmen irgendwie stärker gestört waren. Ausserdem war es im Prinzip undenkbar Aufnahmen während eines Schnittes zu gucken, die waren zwar schnell, aber man mußte warten.
Ich habe nun einige Aufnahmen Test-geschnitten, auch während Aufnahmen, diese blieben Störungsfrei und die Schnitte sind hier nicht wirklich langsamer geworden!
Und ja, das waren Dinge die mit VDR 1.4.7/1.6.0, oder den ersten 1.7.x Versionen nie ein Problem waren, klar SD only zu der Zeit. Dabei setze ich zwar sparsame HW ein, aber keine wirklich schmale wie z.B. Atom-CPUs, siehe Sig.
Diese Anpassung halte ich für eine sehr sinnvolle Eingabe für den Core-VDR, damit wird die hohe Schnittlast effektiv und sinnvoll, hier ohne Einbussen, reduziert, was sicher vielen Installationen entgegenkommt, umso schwächer umso mehr.
Da sie aber nicht von mir ist, werde ich sie nur nutzen und habe sie für alle die verbliebenen yaVDR [0.3][0.4] Nutzern zum Test in testing-vdr gelegt, weil da vermute ich ja einige betagtere HW mit nicht ganz so viel CPU Schmackes ...
Regards
fnu