[MPlayer-dev-eng] [PATCH] fix premature end of stream download

[trevor-b at ovi.com]

> ... 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
>