Christian Wieninger schrieb:
Hi,
I'm currently working on a tool that checks for timer conflicts and became aware of the following problem:
Suppose you have the following 3 timers on a system with two DVB cards:
nr. transponder - start - priority
- A - 20:10 - 45
- B - 20:10 - 5
- C - 20:11 - 50
A,B,C are different transponders. VDR will start recording from transponder A at 20:10 with device 2. The same for transponder B with device 1. At 20:11 we have a conflict and IMHO VDR should stop timer 2 and start timer 3 on device 1. But when I check the logs the following occures: VDR first stops timer 1 on device 2 and starts timer 3 on device 2. Then it recognizes the pending timer 1 with higher priority than the running timer 2 and stops this one. So in the end all is fine, but there is a small break about 1-2 seconds in recording 1. The problem is, that cDevice::GetDevice handles the two devices in this case with the same priority and therefore returns the device with the highest number. I think one could fix this with a small change (patch against 1.4.0 is attached), but the whole thing is really complicated and I do not have a real deep insight in the side effects ;-) , so perhaps you could give a comment on this.
Was this the case also with older VDR-versions? I always thought that VDR behaves the way you also expected and avoids interrupting a recording ...
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). Is that right, or am I missing something here? But why does VDR stop both timers?
Bye, Andreas Brugger