[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