[MPlayer-dev-eng] [PATCH] fix premature end of stream download
trevor-b at ovi.com
trevor-b at ovi.com
Wed Mar 28 12:03:48 CEST 2012
> though errno is not thread-safe
It's complicated, but for some time POSIX has required that errno is thread safe.
There's an interesting discussion here ---> http://stackoverflow.com/questions/1694164/is-errno-thread-safe
This doc ---> http://www.mplayerhq.hu/DOCS/README requires that MPlayer is built on a POSIX compatible system.
Does this include a POSIX compatible errno?
> On the other hand, then it is EAGAIN it might be better to
> retry regardless who often we retried before.
good idea
> Anyway it might also be a good idea to check the async_quite_request
> variable inside such a loop.
is this because errno might not be thread-safe?
> However since your non-working patch "fixed" the issue there is the
> question if there was any real issue with the MPlayer code or if the
> server/network connection was just having issues that nothing could
I did more extensive tests and have now posted the results.
They show that there is an issue, it is fixable, and similar issues may exist in other parts of the program..
(I believe that the non-working patch was a build but forgot to install issue.
In that case, the tests I ran might have with an older build that just tested for len<0 in the while condition)
----- Original Message -----
> From: "trevor-b at ovi.com" <trevor-b at ovi.com>
> To: "mplayer-dev-eng at mplayerhq.hu" <mplayer-dev-eng at mplayerhq.hu>
> Cc:
> Sent: Friday, 23 March 2012, 23:01
> Subject: Re: [MPlayer-dev-eng] [PATCH] fix premature end of stream download
>
> correcting my previous email ...
>
>> recv is not allowed to return EAGAIN
> yes, you are correct, len is not set to EAGAIN - errno is
>
> maybe the while statement in the patch should be ...
> + while( len <= 0 && errno == EAGAIN && nr_tries-- > 0
> );
>
> I'll do some more tests and post again in a couple of days time.
>
>
>
>
> ----- Original Message -----
>> From: "trevor-b at ovi.com" <trevor-b at ovi.com>
>> To: "mplayer-dev-eng at mplayerhq.hu"
> <mplayer-dev-eng at mplayerhq.hu>
>> Cc:
>> Sent: Friday, 23 March 2012, 22:12
>> Subject: Re: [MPlayer-dev-eng] [PATCH] fix premature end of stream download
>>
>>> ... when recv returns 0, the other side closed the connection.
>> what if recv returns < 0? In my case, the call to perror prints
> "read
>> error:: Resource temporarily unavailable"
>>
>>
>>> recv is not allowed to return EAGAIN
>>
>> Are you sure? Perhaps this is a windows vs linux/unix/posix difference?
>>
>> This is taken from the man page for recv ....
>>
>> ERRORS
>> These are some standard errors generated by the socket
> layer.
>> Additional errors may be generated and
>> returned from the underlying protocol modules; see their manual
> pages.
>>
>> EAGAIN or EWOULDBLOCK
>> The socket is marked nonblocking and the receive operation
> would
>> block, or a receive timeout had been
>> set and the timeout expired before data was
> received.
>> POSIX.1-2001 allows either error to be
>> returned for this case, and does not require these constants
> to
>> have the same value, so a portable
>> application should check for both possibilities.
>>
>> ...
>>
>>
>>
>>
>> ----- Original Message -----
>>> From: Reimar Döffinger <Reimar.Doeffinger at gmx.de>
>>> To: mplayer-dev-eng at mplayerhq.hu
>>> Cc:
>>> Sent: Friday, 23 March 2012, 17:29
>>> Subject: Re: [MPlayer-dev-eng] [PATCH] fix premature end of stream
> download
>>>
>>> On Fri, Mar 23, 2012 at 09:59:17AM -0700, trevor-b at ovi.com wrote:
>>>> Hi all,
>>>>
>>>> I have been listening to a BBC program, but mplayer nearly always
>
>> aborts
>>> before finishing the download with this error message:
>>>>
>>>> read error:: Resource temporarily unavailable3% 1%
>>>> pre-header read failed
>>>> Stream not seekable!
>>>>
>>>> In the sample output below, you can see the error occurred 11
> mins
>> into a 2
>>> hr program.
>>>>
>>>> From the eror message, I'm guessing the problem happens
> because
>> the
>>> data doesn't arrive fast enough,
>>>>
>>>> so mplayer gives up.
>>>>
>>>> The corresponding code is in stream/asf_mmst_streaming.c, in
> function
>>> get_data():
>>>>
>>>> len = recv (s, &buf[total], count-total, 0);
>>>> if (len<=0) {
>>>> perror ("read error:");
>>>> return 0;
>>>> }
>>>>
>>>>
>>>> So it does give up as soon as there is no data available.
>>>
>>> No it does not, when recv returns 0, the other side closed the
>>> connection.
>>>
>>>
>>>> --- stream/asf_mmst_streaming.c 2010-09-10 22:42:13.000000000
> +0100
>>>> +++ stream/asf_mmst_streaming.1.c 2012-03-22
> 22:51:36.000000000
>> +0000
>>>> @@ -191,11 +191,14 @@
>>>> {
>>>> ssize_t len;
>>>> size_t total = 0;
>>>> -
>>>> + int nr_tries;
>>>> +
>>>> while (total < count) {
>>>>
>>>> - len = recv (s, &buf[total], count-total, 0);
>>>> -
>>>> + nr_tries = 10;
>>>> + do
>>>> + len = recv (s, &buf[total], count-total, 0);
>>>> + while( len == EAGAIN && nr_tries-- > 0 );
>>>
>>> That doesn't make sense, recv is not allowed to return EAGAIN
>>> (-1, 0 and number of bytes are the only allowed values),
>>> thus either the recv implementation is broken or your
>>> change does not do anything at all.
>>> _______________________________________________
>>> MPlayer-dev-eng mailing list
>>> MPlayer-dev-eng at mplayerhq.hu
>>> https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
>>>
>> _______________________________________________
>> MPlayer-dev-eng mailing list
>> MPlayer-dev-eng at mplayerhq.hu
>> https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
>>
> _______________________________________________
> MPlayer-dev-eng mailing list
> MPlayer-dev-eng at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
>
More information about the MPlayer-dev-eng
mailing list