[MPlayer-dev-eng] [PATCH] fix premature end of stream download
trevor-b at ovi.com
trevor-b at ovi.com
Sat Mar 24 00:01:56 CET 2012
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
>
More information about the MPlayer-dev-eng
mailing list