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

trevor-b at ovi.com trevor-b at ovi.com
Thu Mar 29 13:57:29 CEST 2012


>>  Anyway it might also be a good idea to check the async_quite_request
>>  variable inside such a loop.

now tried this, but unfortunately, linking fails ...

stream/asf_mmst_streaming.o: In function `get_data':
/home/trevor/rpmbuild/BUILD/MPlayer-1.0rc4_r34818/stream/asf_mmst_streaming.c:200: undefined reference to `async_quit_request'





----- 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: Wednesday, 28 March 2012, 11:03
> Subject: Re: [MPlayer-dev-eng] [PATCH] fix premature end of stream download
> 
>>   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
>> 
> _______________________________________________
> 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