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@xxxxxxxxxxx/msg14166.html?
Regards,
Frank
_______________________________________________
vdr mailing list
vdr@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
