diff options
author | James Courtier-Dutton <jcdutton@users.sourceforge.net> | 2004-05-16 21:45:24 +0000 |
---|---|---|
committer | James Courtier-Dutton <jcdutton@users.sourceforge.net> | 2004-05-16 21:45:24 +0000 |
commit | edff8fd5744069608128007d840ae9b23dc32966 (patch) | |
tree | 294de590b51dc34e0dbeb6ad77c48b7de0a77281 /po | |
parent | 885e3817c8b2c0487f4de4f81fb902fdeee64587 (diff) | |
download | xine-lib-edff8fd5744069608128007d840ae9b23dc32966.tar.gz xine-lib-edff8fd5744069608128007d840ae9b23dc32966.tar.bz2 |
From: Reinhard Nissl.
The fix stopps dropping properly received data.
I realized the problem when switching channels in VDR. From time to time, it happend that switching took more than 50 ms (the timeout value used in _x_read_abort()), which caused the select() to timeout.
In the case where 'stream->demux_action_pending' was set, the already received data was dropped due to returning 0. This finally resulted in your demuxer to fail with DEMUX_END, as it couldn't read 6 bytes from the PES header.
So for the case, that there is some data available, it now takes twice the timeout (i. e. 100 ms), before a return 0 happens.
Some more information: as in rare cases switching channels could take even longer than 100 ms, I've also added a loop around _x_read_about() in my VDR input plugin, which returns 0 just after this state lasts for 5 seconds.
CVS patchset: 6557
CVS date: 2004/05/16 21:45:24
Diffstat (limited to 'po')
0 files changed, 0 insertions, 0 deletions