[MPlayer-users] Restarting mplayer after Network Trouble

[Martin McCormick]

Is there a way to get mplayer to keep re-trying a session
that chokes up due to network trouble?

There are some radio programs I like to time shift and
too many times, stuff happens and the stream breaks up enough
that mplayer gives up and one misses the rest of the program. If
given the choice between nothing at all and most of the program
with a piece missing, the mutilated show is much better. I am
using the normal record method in which the command starts out
like:

mplayer -noconsolecontrols -nolirc -really-quiet -dumpstream -playlist

followed by the link to the program source.

If a run-out produces a distinctive exit status, I could
probably write some shell script that saves the stream fragment
to a temporary file and then restarts mplayer again until the
time for the show has passed.

The shell scripts I use right now call mplayer to save to
stream.dump and then I background that process with & and then
kill $! after sleeping X number of seconds. If mplayer died
before that time, one just looses everything after that point.

On Friday afternoon, there are 3 programs I save from 3
different sources that all occur during roughly the same time
period Our ISP which is normally quite good must have had some
internet upheaval because all 3 programs were cut short, very
short in some cases. When I checked later, everything was fine so
service returned but mplayer had already given up.

I am certainly not complaining as mplayer works
beautifully when the network does. I simply want to devise the
best and most direct method for trying a restart when there is a
break in the stream. Normally, the stream never ends.

Thanks.

Martin McCormick

[Rasz]

Post by Martin McCormick
Is there a way to get mplayer to keep re-trying a session
that chokes up due to network trouble?

I have similar problem with video played from the network. My use case
is streaming Youtube. I am using this browser plugin:
https://github.com/gantt/downloadyoutube
it generates direct https:/....mp4 links. Browser launches mplayer
with help of a custom handler (like you would for example launch
torrent client on magnet links). Result is instant mplayer playback of
YT videos, no downloading involved.

Problems start when trying to pause video. mplayer has no mechanism
for that and will simply reply with [TCP ZeroWindow] signalling full
buffer. Google web server will probe client(mplayer) with keep-alive
packets for 300 seconds, after which it aborts concluding host
crash/problems. Any attempts to continue playing after 300 seconds
result in RST packet from google file server. Receiving RST makes
mplayer choke for a second and close with no attempt at restarting.

Seeking in the video abandons current connection abruptly _without
properly closing it_ and just starts another one. Quitting mplayer
sends proper RST closing connection. Mplayer also doesnt cope well
with packet loss and again chokes and quits.

At the very least there should be a way of making mplayer restart
failed connection couple of times.
Pausing should result in properly closed connection (maybe after a
decent timeout), unpause should start new one.

[Reimar Döffinger]

Post by Rasz
Problems start when trying to pause video. mplayer has no mechanism
for that and will simply reply with [TCP ZeroWindow] signalling full
buffer. Google web server will probe client(mplayer) with keep-alive
packets for 300 seconds, after which it aborts concluding host
crash/problems. Any attempts to continue playing after 300 seconds
result in RST packet from google file server. Receiving RST makes
mplayer choke for a second and close with no attempt at restarting.

Are you really using a current version?
That is exactly what the MAX_RECONNECT_RETRIES thing was
introduced for in 2012.

Post by Rasz
Seeking in the video abandons current connection abruptly _without
properly closing it_ and just starts another one.

Huh? What made you conclude that? MPlayer calls closesocket on the
old connection before opening the new one.

Post by Rasz
At the very least there should be a way of making mplayer restart
failed connection couple of times.

There is, by default, 5 times.

Post by Rasz
Pausing should result in properly closed connection (maybe after a
decent timeout), unpause should start new one.

I don't exactly see the point.
A lot of servers might be perfectly happy with keeping
the connection open as long as it takes, why should
the client add an arbitrary timeout?

[Rasz]

Post by Reimar Döffinger
Are you really using a current version?
That is exactly what the MAX_RECONNECT_RETRIES thing was
introduced for in 2012.

tried those:
MPlayer Redxii-SVN-r37448-4.9.3 (x86_64) (C) 2000-2015 MPlayer Team
MPlayer sherpya-r37802+g666e2ed-5.3.1 (C) 2000-2016 MPlayer Team

Post by Reimar Döffinger

Post by Rasz
Seeking in the video abandons current connection abruptly _without
properly closing it_ and just starts another one.

Huh? What made you conclude that? MPlayer calls closesocket on the
old connection before opening the new one.

packet captures (tshark)

to reproduce get http://youtube-dl.org/
this gives you direct YT mp4 link: youtube-dl.exe -g

-f 22

mplayer "https://r6---sn-f5f7ln7l.googlevideo.com/videoplayback?mn=sn-f5f7ln7l&ip=31.178.207.150&mm=31&sparams=dur,id,initcwndbps,ip,ipbits,itag,lmt,mime,mm,mn,ms,mv,nh,pl,ratebypass,requiressl,source,upn,expire&mv=m&pl=16&mt=1458650654&requiressl=yes&ms=au&mime=video/mp4&dur=1185.866&id=o-AOiH9NxO6ngTh-HIdrRZtpyfe37tTWSWMPmlQtutChxJ&initcwndbps=2678750&expire=1458672459&sver=3&key=yt6&signature=013B6E4725C8FCB171453F248FC843A8E5903E18.A879FC3907909B8952CF2F9AEAB6EF5BDA6F56AF&source=youtube&ratebypass=yes&nh=IgpwcjAyLndhdzAyKgkxMjcuMC4wLjE&upn=v9nYiAvjU5c&itag=22&ipbits=0&fexp=9405972,9416126,9417580,9420452,9422596,9423661,9423662,9423923,9424134,9424580,9425790,9427036,9427902,9428010,9428668,9428983,9430817,9431012,9431237,9432032,9432387&lmt=1458612933224741&title=Getting%20ideas%20out%20as%20a%20small%20business%20owner%20means%20tossing%20the%20idea%20of%20perfection"

pause and watch network traffic, try unpausing after 300 seconds

1.200969 173.194.150.124 -> 192.168.1.10 TCP 1458 [TCP segment of a
reassembled PDU]
1.200970 173.194.150.124 -> 192.168.1.10 TCP 1458 [TCP segment of a
reassembled PDU]
1.200970 173.194.150.124 -> 192.168.1.10 TCP 118 [TCP segment of a
reassembled PDU]
1.200980 192.168.1.10 -> 173.194.150.124 TCP 54 [TCP ZeroWindow]
62372â+'443 [ACK] Seq=1 Ack=684386 Win=0 Len=0
1.431178 173.194.150.124 -> 192.168.1.10 TCP 64 [TCP Keep-Alive]
443â+'62372 [ACK] Seq=684385 Ack=1 Win=253 Len=0
1.431230 192.168.1.10 -> 173.194.150.124 TCP 54 [TCP ZeroWindow]
62372â+'443 [ACK] Seq=1 Ack=684386 Win=0 Len=0
1.886015 173.194.150.124 -> 192.168.1.10 TCP 64 [TCP Keep-Alive]
443â+'62372 [ACK] Seq=684385 Ack=1 Win=253 Len=0
1.886042 192.168.1.10 -> 173.194.150.124 TCP 54 [TCP ZeroWindow]
62372â+'443 [ACK] Seq=1 Ack=684386 Win=0 Len=0
2.790032 173.194.150.124 -> 192.168.1.10 TCP 64 [TCP Keep-Alive]
443â+'62372 [ACK] Seq=684385 Ack=1 Win=253 Len=0
2.790056 192.168.1.10 -> 173.194.150.124 TCP 54 [TCP ZeroWindow]
62372â+'443 [ACK] Seq=1 Ack=684386 Win=0 Len=0
4.589286 173.194.150.124 -> 192.168.1.10 TCP 64 [TCP Keep-Alive]
443â+'62372 [ACK] Seq=684385 Ack=1 Win=253 Len=0
4.589353 192.168.1.10 -> 173.194.150.124 TCP 54 [TCP ZeroWindow]
62372â+'443 [ACK] Seq=1 Ack=684386 Win=0 Len=0
8.181129 173.194.150.124 -> 192.168.1.10 TCP 64 [TCP Keep-Alive]
443â+'62372 [ACK] Seq=684385 Ack=1 Win=253 Len=0
8.181193 192.168.1.10 -> 173.194.150.124 TCP 54 [TCP ZeroWindow]
62372â+'443 [ACK] Seq=1 Ack=684386 Win=0 Len=0
15.356829 173.194.150.124 -> 192.168.1.10 TCP 64 [TCP Keep-Alive]
443â+'62372 [ACK] Seq=684385 Ack=1 Win=253 Len=0
15.356883 192.168.1.10 -> 173.194.150.124 TCP 54 [TCP ZeroWindow]
62372â+'443 [ACK] Seq=1 Ack=684386 Win=0 Len=0
29.702154 173.194.150.124 -> 192.168.1.10 TCP 64 [TCP Keep-Alive]
443â+'62372 [ACK] Seq=684385 Ack=1 Win=253 Len=0
29.702226 192.168.1.10 -> 173.194.150.124 TCP 54 [TCP ZeroWindow]
62372â+'443 [ACK] Seq=1 Ack=684386 Win=0 Len=0
58.383969 173.194.150.124 -> 192.168.1.10 TCP 64 [TCP Keep-Alive]
443â+'62372 [ACK] Seq=684385 Ack=1 Win=253 Len=0
58.384019 192.168.1.10 -> 173.194.150.124 TCP 54 [TCP ZeroWindow]
62372â+'443 [ACK] Seq=1 Ack=684386 Win=0 Len=0
88.392458 173.194.150.124 -> 192.168.1.10 TCP 64 [TCP Keep-Alive]
443â+'62372 [ACK] Seq=684385 Ack=1 Win=253 Len=0
88.392501 192.168.1.10 -> 173.194.150.124 TCP 54 [TCP ZeroWindow]
62372â+'443 [ACK] Seq=1 Ack=684386 Win=0 Len=0
118.400917 173.194.150.124 -> 192.168.1.10 TCP 64 [TCP Keep-Alive]
443â+'62372 [ACK] Seq=684385 Ack=1 Win=253 Len=0
118.400955 192.168.1.10 -> 173.194.150.124 TCP 54 [TCP ZeroWindow]
62372â+'443 [ACK] Seq=1 Ack=684386 Win=0 Len=0
148.410372 173.194.150.124 -> 192.168.1.10 TCP 64 [TCP Keep-Alive]
443â+'62372 [ACK] Seq=684385 Ack=1 Win=253 Len=0
148.410415 192.168.1.10 -> 173.194.150.124 TCP 54 [TCP ZeroWindow]
62372â+'443 [ACK] Seq=1 Ack=684386 Win=0 Len=0
178.419853 173.194.150.124 -> 192.168.1.10 TCP 64 [TCP Keep-Alive]
443â+'62372 [ACK] Seq=684385 Ack=1 Win=253 Len=0
178.419878 192.168.1.10 -> 173.194.150.124 TCP 54 [TCP ZeroWindow]
62372â+'443 [ACK] Seq=1 Ack=684386 Win=0 Len=0
208.428292 173.194.150.124 -> 192.168.1.10 TCP 64 [TCP Keep-Alive]
443â+'62372 [ACK] Seq=684385 Ack=1 Win=253 Len=0
208.428315 192.168.1.10 -> 173.194.150.124 TCP 54 [TCP ZeroWindow]
62372â+'443 [ACK] Seq=1 Ack=684386 Win=0 Len=0
238.436834 173.194.150.124 -> 192.168.1.10 TCP 64 [TCP Keep-Alive]
443â+'62372 [ACK] Seq=684385 Ack=1 Win=253 Len=0
238.436893 192.168.1.10 -> 173.194.150.124 TCP 54 [TCP ZeroWindow]
62372â+'443 [ACK] Seq=1 Ack=684386 Win=0 Len=0
268.446251 173.194.150.124 -> 192.168.1.10 TCP 64 [TCP Keep-Alive]
443â+'62372 [ACK] Seq=684385 Ack=1 Win=253 Len=0
268.446269 192.168.1.10 -> 173.194.150.124 TCP 54 [TCP ZeroWindow]
62372â+'443 [ACK] Seq=1 Ack=684386 Win=0 Len=0
298.456257 173.194.150.124 -> 192.168.1.10 TCP 64 [TCP Keep-Alive]
443â+'62372 [ACK] Seq=684385 Ack=1 Win=253 Len=0
298.456327 192.168.1.10 -> 173.194.150.124 TCP 54 [TCP ZeroWindow]
62372â+'443 [ACK] Seq=1 Ack=684386 Win=0 Len=0
394.822000 192.168.1.10 -> 173.194.150.124 TCP 54 [TCP Window Update]
62372â+'443 [ACK] Seq=1 Ack=684386 Win=1323 Len=0
394.832330 173.194.150.124 -> 192.168.1.10 TCP 64 443â+'62372 [RST]
Seq=684386 Win=0 Len=0

at this point mplayer closes with
[tls @ 00000000018367a0]Error in the pull function.
[tls @ 00000000018367a0]The specified session has been invalidated for
some reason.
[tls @ 00000000018367a0]The specified session has been invalidated for
some reason.
[tls @ 00000000018367a0]The specified session has been invalidated for
some reason.
[tls @ 00000000018367a0]The specified session has been invalidated for
some reason.
[mov,mp4,m4a,3gp,3g2,mj2 @ 00000000018605e0]stream 0, offset 0x45ebe3:
partial file
[h264 @ 00000000019acf40]AVC: nal size 15870
[h264 @ 00000000019acf40]no frame!
Error while decoding frame!
[mov,mp4,m4a,3gp,3g2,mj2 @ 00000000018605e0]stream 0, offset 0x45ffc9:
partial file

What is even worse Mplayer has no contingency for the event of _not_
receiving any reply at all and will simply hang _unresponsive_ while
looping last buffered xxx ms of audio.

Post by Reimar Döffinger

Post by Rasz
At the very least there should be a way of making mplayer restart
failed connection couple of times.

There is, by default, 5 times.

I cant get it to trigger no matter what I do. Maybe it only works for
plain http/ftp shares? or rtp streams?

Post by Reimar Döffinger

Post by Rasz
Pausing should result in properly closed connection (maybe after a
decent timeout), unpause should start new one.

I don't exactly see the point.
A lot of servers might be perfectly happy with keeping
the connection open as long as it takes, why should
the client add an arbitrary timeout?

might is the key word, in 2016 timing out ZeroWindow quickly is 101 of
ddos resource starvation prevention. Google is very generous with 300
seconds timeout, most CDNs drop you after 10-20 seconds. Can you find
a popular hosting site that wont drop you quickly? I wouldnt suggest
this wasteful method myself either, but even Googles default YT player
does exactly that after pressing pause button (after ~1-2 seconds).

[Reimar Döffinger]

Post by Rasz

Post by Reimar Döffinger
Are you really using a current version?
That is exactly what the MAX_RECONNECT_RETRIES thing was
introduced for in 2012.

MPlayer Redxii-SVN-r37448-4.9.3 (x86_64) (C) 2000-2015 MPlayer Team
MPlayer sherpya-r37802+g666e2ed-5.3.1 (C) 2000-2016 MPlayer Team

Post by Reimar Döffinger

Post by Rasz
Seeking in the video abandons current connection abruptly _without
properly closing it_ and just starts another one.

Huh? What made you conclude that? MPlayer calls closesocket on the
old connection before opening the new one.

packet captures (tshark)
to reproduce get http://youtube-dl.org/
this gives you direct YT mp4 link: youtube-dl.exe -g
http://youtu.be/7srmGug-a44 -f 22

I missed that you said https.
https is implemented via FFmpeg.
What I said only applies to our own implementations
(http, ftp etc.).
It might be caused by bug in how we use it, but at least
the missing close I would expect to be reproducible
with ffplay and thus not MPlayer's fault.
Even the failure to re-open might come from FFmpeg
if it fails to report the closed connection as an
error (as opposed to end-of-file), but I have not
checked.

[Reimar Döffinger]

Post by Rasz
Seeking in the video abandons current connection abruptly _without
properly closing it_ and just starts another one.

If you get that from some capture I suspect it mislead you.
A new connection is opened first and the old one is then
closed shortly after.

[Reimar Döffinger]

Post by Martin McCormick
Is there a way to get mplayer to keep re-trying a session
that chokes up due to network trouble?

Actually, MPlayer does retry, but only a limited number of
times and that is currently not configurable.
Does that retrying not work, or would you just need
to be able to set it to "retry forever"?

Post by Martin McCormick
mplayer -noconsolecontrols -nolirc -really-quiet -dumpstream -playlist
followed by the link to the program source.
If a run-out produces a distinctive exit status, I could
probably write some shell script that saves the stream fragment
to a temporary file and then restarts mplayer again until the
time for the show has passed.

Given your command-line, and that this kind of resuming would
only work with a live stream, isn't a network issue the
only reason that could cause it to exit?
So what would you need the exit code for?

Post by Martin McCormick
I am certainly not complaining as mplayer works
beautifully when the network does. I simply want to devise the
best and most direct method for trying a restart when there is a
break in the stream. Normally, the stream never ends.

Just change the MAX_RECONNECT_RETRIES define to some crazy large
value or if you're comfortable with basic C completely remove
the check for it?