Bug in stream\cache2.c

[visenri@…]

Hello, I'm Visenri, the programmer or MPUI-Ve.

I've been using mplayer for a long time, but i was using r29851, because some bugs in newer versions, this is the most annoying.

Finally i decided to get the source code and try to find a solution, and i've succesfully compiled a version without the problem.

When seeking (in slow media,cdrom or dvdrom) you get many times this message:
"Cache not responding! [performance issue]"
and it takes several seconds (10-15s, with a cache of 3000kb) to resume playback of video file.

Without cache everything is ok.

It was introduced around version > r31170.

In function cache_do_control (stream\cache2.c) there is a loop to wait for cache (in version > r31170):

################## code ##################

cache_wakeup(stream);
while (s->control != -1) {

if (sleep_count++ == 1000)

mp_msg(MSGT_CACHE, MSGL_WARN, "Cache not responding! [performance issue]\n");

if (stream_check_interrupt(CONTROL_SLEEP_TIME)) {

s->eof = 1;
return STREAM_UNSUPPORTED;

}

}

################ end code #################

that in previous versions was (as old as r31170):

################## code ##################

while (s->control != -1)

usec_sleep(CONTROL_SLEEP_TIME);

################ end code #################

CONTROL_SLEEP_TIME is 0 in both versions

but stream_check_interrupt(CONTROL_SLEEP_TIME) does not call usec_sleep if parameter is 0, here is why:

this function calls : mp_input_check_interrupt(time)
then : mp_input_get_cmd(time,0,1)

then the one that handles time:

read_events(time, paused);

and finally in this function :

if (!got_cmd && time)

usec_sleep(time * 1000);

So, if CONTROL_SLEEP_TIME is 0, no sleep is done and main thread never gives time to cache thread to read.
Changing CONTROL_SLEEP_TIME to 1 solves the problem.

[visenri@…]

I've found this one, seems to be the same problem:

​http://bugzilla.mplayerhq.hu/show_bug.cgi?id=1761

Once you close this bug you should close both bugs.

[visenri@…]

Sorry, message from bug ​http://bugzilla.mplayerhq.hu/show_bug.cgi?id=1761

It's a different one, it's ok, it only shows that reading is really slow.

[reimar]

Code changed according to your suggestion in r35119