Christian Wieninger schrieb:
I don't have a in depth look into this code either, but shouldn't cDevice::GetDevice already only prefer device 1 (the one recording timer 2). As it loops through the devices it should give device 1 the priority 5 and as it comes to device 2 it should evaluate it to priority 7, as Priority of the device 2 is not smaller than the Priority of device 1 (which is one of the conditions for priority 5).
With 'Priority' you probably mean the variable 'pri' used in GetDevice?
Yes thats right.
In the case described before, GetDevice (1.4.0) sets 'pri' to 8 for both devices: The first loop for device 1 has no previously selected device ('d') and so 'pri' is set to 8, since device 1 is receiving. In the second loop device 2 has priority bigger than device 1 and so again 'pri' is set to 8. So device 2 will be returned resulting in a short break of recording 1 with priority 45.
The idea of my patch is to stretch the pri-value to MAXPRIORITY+1 and to add the current priority of the receiving device in this case. Perhaps it would even be a better approach to add the device priority in any case if a device is currently receiving.
Oh, that was a stupid misinterpretation from me. You are right of course. I think there is the general problem of the cDevice::GetDevice-Routine that in the first run there is no selected device. This should effect all the conditions where there is a check for d != NULL, so maybe the easiest fix is to set the Device in the beginning of the routine to one of the devices (first or last):
- cDevice *d = NULL;
- cDevice *d = device[0]; // or device[numDevices]
So the two timers should evaluate to different priorities.
Any thoughts on that? Do I miss something again?