Sometimes this happens:
MPlayer sherpya-r38203+gb51b9bbd42-10-win32 (C) 2000-2020 MPlayer Team
Playing ***.mkv.
CACHE_PRE_INIT: 0 [0] 0 pre:251658 eof:0
Cache fill: 0.00% (0 bytes)
libavformat version 58.64.100 (internal)
libavformat file format detected.
CACHE2_SEEK: 0x0 <= 0x6AF010DF (0x8000) <= 0x120000
Out of boundaries... seeking to 0x6AF01000
Seek done. new pos: 0x6AF01000
CACHE2_SEEK: 0x6AF01000 <= 0x3605 (0x6AF0137E) <= 0x6AF0137E
Out of boundaries... seeking to 0x3000
Seek done. new pos: 0x3000
cache_stream_seek: WARNING! Can't seek to 0x3605 !
CACHE2_SEEK: 0x3000 <= 0x6AF0137E (0x3000) <= 0x3000
Out of boundaries... seeking to 0x6AF01000
Seek done. new pos: 0x6AF01000
[matroska,webm @ 01b0c540]File ended prematurely at pos. 1794118526 (0x6af0137e)
[matroska,webm @ 01b0c540]Could not find codec parameters for stream 0 (Video: h264, none, 1920x1080): unspecified pixel format
After that, mplayer ends gracefully, without playing anything.
(the used build is somewhat old, due to every newer builds having each own set of bugs hitting my usage, e.g. non-working-at-all or broken MPEG2 or broken Vorbis or something. I can't have it updated still.)
I'm suspecting a race in stream/cache2.c between
cache_stream_seek_long() resets [cache_data]->eof=0; // !!!!!!!
cache_fill(), running at eof, overwrites [cache_data]->eof every now and then
which would let cache_read() abort the loop immediately and fail hard.
Due to the nature of the problem, it hardly reproduces on reasonably fast filesystems. I usually get hit by this problem when playing a file on network drives over mildly-choked WiFi.
@rdoeffinger any ideas?
Sometimes this happens:
After that, mplayer ends gracefully, without playing anything.
(the used build is somewhat old, due to every newer builds having each own set of bugs hitting my usage, e.g. non-working-at-all or broken MPEG2 or broken Vorbis or something. I can't have it updated still.)
I'm suspecting a race in
stream/cache2.cbetweencache_stream_seek_long()resets [cache_data]->eof=0; // !!!!!!!cache_fill(), running at eof, overwrites [cache_data]->eofevery now and thenwhich would let
cache_read()abort the loop immediately and fail hard.Due to the nature of the problem, it hardly reproduces on reasonably fast filesystems. I usually get hit by this problem when playing a file on network drives over mildly-choked WiFi.
@rdoeffinger any ideas?