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?
