Reinhard Nissl wrote:
But for any reason, "r == 0" happens still without the FIFO beeing
closed.
Can someone tell me, how to handle this situation properly?
It shouldn't be possible to read zero bytes from a file descriptor unless it's been set to nonblocking mode.
In my opinion FIFOs are evil relics from stone age... Have you looked at networking patch for xine plugin? What it basically does is it replaces FIFOs with sockets. When xine is run on the same machine as VDR, then there's really not much difference between the FIFO behaviour (except that sockets do behave little nicer in my opinion), but it also allow you to run xine on a different machine than VDR.
Anyway, in the xine-network version it was possible to get into deadlock depending on which part of code was running as the connection to xine was broken. I fixed it with this patch:
http://tvr.dy.fi/xine-0.7.2-network-DeadLockFix.diff
I could assume the same deadlock happens with FIFOs also unless read()=0 is handled.
What do you think about integrating network -patch into xine-plugin?
Teemu
Hi,
Rantanen Teemu wrote:
Anyway, in the xine-network version it was possible to get into deadlock depending on which part of code was running as the connection to xine was broken. I fixed it with this patch:
http://tvr.dy.fi/xine-0.7.2-network-DeadLockFix.diff
I could assume the same deadlock happens with FIFOs also unless read()=0 is handled.
This fix addresses the same lines of code, that show the problem in the FIFO case. At the moment it looks like it's xine that closes the FIFOs and that's why the read returns 0.
This typically happens when moving cutting marks, and I'm investigating this already.
What do you think about integrating network -patch into xine-plugin?
Expect it for 0.8.0, but the next release will still be 0.7.3.
Bye.
-
Rantanen Teemu -
Reinhard Nissl