Martin Wache wrote: > Finally we've been able to track the problem down: > It seems to arise when the softdevices buffers are not full, so that > Poll() doesn't sleep (since the softdevice still can accept data), but > vdr has no more frames to send to the softdevice. > In this case the loop inside of cDevbPlayer::Action will busy loop until > there are frames again. This is a design flaw in the player, but only matters if the disk read data rate is lower than device write rate, but this obviously can have side effects at startup. The correct way to handle this situation would be to also poll the source file handle, but only if there's currently nothing to read. I had the same situation in streamplayer, and there it is more critical, because the source file is a socket, and network buffers will overflow quickly. Cheers, Udo