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 >1. A - 20:10 - 45 >2. B - 20:10 - 5 >3. 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
