[MPlayer-users] mplayer kills with a broken frame error

Mac Smith macsmith.us at gmail.com
Mon Apr 23 09:00:54 CEST 2012


On 23-Apr-2012, at 11:50 AM, Mac Smith wrote:

> 
> On 22-Apr-2012, at 6:08 PM, Reimar Döffinger wrote:
> 
>> On Sun, Apr 22, 2012 at 02:16:44PM +0200, Reimar Döffinger wrote:
>>> On Sun, Apr 22, 2012 at 05:36:11PM +0530, Mac Smith wrote:
>>>>>> also tried
>>>>>> 
>>>>>> MPlayer SVN-r34870-4.4.3 (C) 2000-2012 MPlayer Team
>>>>>> 
>>>>>> but its the same
>>>>> 
>>>>> Am am really certain it is _not_ the same.
>>>>> That version will try reconnection once (which will fix it if the
>>>>> connection broke due to pausing for a long time), though if that fails
>>>>> it will give up. Retrying and thus hanging possibly forever is rarely
>>>>> a good idea.
>>>>> If it still fails that should mean your sever was down long enough to
>>>>> cause a network timeout and then refuses a reconnect still after that.
>>>>> Well, it could be the code does not handle a orderly server shutdown
>>>>> well since the network timeout does not come into play then.
>>>>> But you should be able to see from MPlayer's output when it tries to
>>>>> reconnect.
>>>> 
>>>> 
>>>> server was not down for a long, to simulate this i just did a "service httpd reload" and i dont see a any message of retying to connect.
>>> 
>>> You might want to try r34871.
>>> However "service httpd reload" does _not at all_ work for simulating a
>>> connection failing.
>>> To my knowledge some Apache versions will incorrectly tell their clients
>>> that the end of the file was reached when you shut down the server.
>>> In that case the behaviour that MPlayer shows is exactly correct.
>> 
>> Actually, for HTTP/1.0 a closed connection means the file was fully
>> transferred, so in that case MPlayer is correct in concluding the file
>> is done and to exit.
>> With 1.1 there _might_ be a content length field which allows to detect
>> the situation.
>> You could try below patch for that.
>> However from my side the conclusion is with HTTP you should either use
>> the graceful shutdown feature of the web server or just pull the plug,
>> doing "service httpd reload" _will_ give incorrect "instructions" to the
>> clients.
>> --- stream/stream.c
>> +++ stream/stream.c
>> @@ -310,7 +310,8 @@ int stream_read_internal(stream_t *s, void *buf, int len)
>> #ifdef CONFIG_NETWORKING
>>    if( s->streaming_ctrl!=NULL && s->streaming_ctrl->streaming_read ) {
>>      len=s->streaming_ctrl->streaming_read(s->fd, buf, len, s->streaming_ctrl)
>> -      if (s->streaming_ctrl->status == streaming_stopped_e)
>> +      if (s->streaming_ctrl->status == streaming_stopped_e &&
>> +          (!s->end_pos || s->pos == s->end_pos))
>>        s->eof = 1;
>>    } else
>> #endif
> 
> 
> Updated to r34872, unplugged the network cable and plugged it back. It retries to connect to the stream 5 time, and if connects the video starts playing again. Its great. After applying the stream.c patch it also reconnects on "service httpd reload"
> 
> 
> But i am facing a new issue. When I do a pause by pressing a space bar it pauses, than again i press space bar it resumes, I repeat this, but third time it does not resumes. when I press right arrow key (forward) it resumes 
> 

I did a msglevel all=9, I don't know if this log is relevant. I have attached the log which is after the video could not play after pause.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: mplayerlog.txt
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-users/attachments/20120423/237d55e0/attachment.txt>


More information about the MPlayer-users mailing list