Hi,
On Sun, 19 Feb 2012 14:54:48 +0100, Klaus Schmidinger wrote
- Fixed handling the PrimaryLimit when requesting a device for live viewing (reported by Uwe Scheffler).
Refers to the following change in device.c: - if (device[i]->ProvidesChannel(Channel, Priority, &ndr)) { // this device is basicly able to do the job + if (device[i]->ProvidesChannel(Channel, (LiveView && device[i]->IsPrimaryDevice()) ? Setup.PrimaryLimit : Priority, &ndr)) { // this device is basicly able to do the job
With this modification the GetDevice parameter Priority becomes meaningless in case LiveView is true. This should at least be mentioned in the function's documentation in device.h.
Anyway, I think a better way to fix the problem would be to change the priority parameter of the GetDevice calls involved from "GetDevice(channel, 0, true)" to "GetDevice(channel, Setup.PrimaryLimit, true)". There are two calls in device.c and one call in menu.c.
Imagine a two card system with PrimaryLimit 20, a high priority recording (e.g. 50) running on the PrimaryDevice and a low priority recording (e.g. 10) on the second card. With 1.7.24 live TV would not interrupt the low priority recording, as PrimaryLimit priority is only used when checking the PrimaryDevice, but priority 0 is used when checking the second card.
The way 1.7.24 resolves the problem is not wrong as according to MANUAL PrimaryLimit is not meant to affect transfer mode. IMHO it should, as the intention of this parameter is prefering LiveTV to low priority recordings. I'm still hoping to get a more priority driven device selection. BTW: Any update on this related issue: http://www.mail-archive.com/vdr@linuxtv.org/msg14166.html?
Regards, Frank