[MPlayer-users] Issue with slave mode and playlists
Reimar.Doeffinger at gmx.de
Tue Mar 16 23:58:36 EET 2021
On Fri, Mar 12, 2021 at 07:59:01PM -0800, Alec Bennett wrote:
> I'm trying to use slave mode with a playlist, but the slave instance
> doesn't advance to the next track in the playlist.
> Using version "MPlayer SVN-r38198-7 (C) 2000-2020 MPlayer Team"
> I'm running the master with the command:
> mplayer -udp-master -udp-ip 127.0.0.1 -playlist ~/playlist_test.m3u
> The slave instance is:
> mplayer -udp-slave -udp-ip 127.0.0.1 -playlist ~/playlist_test.m3u
> The playlist is simple:
> When video1.mp4 finishes, the master window starts playing video2.mp4. But
> the slave window plays video1.mp4 again...
> Interestingly when I test with an old version of mplayer (version "MPlayer
> 1.3.0 (Debian), built with gcc-7 (C) 2000-2016 MPlayer Team") it works...
> Is this a known issue?
I am afraid that this only ever worked by pure chance...
The UDP synchronization protocol can only do 2 things:
- say which time position of the video to play
In particular, there is no "advance to next video" mechanism,
so the second instance has no way of knowing it should play
the next video at position 0 and not the current one.
It is not in principle hard to add a send_udp command to say
to advance to the next video, however it is not ideal to do so
since UDP might lose messages.
Also navigating e.g. backwards in the playtree would still completely
It's not impossible to support this use-case, but it would require
a bit of thinking and work.
For example it might be possible to instead send a playtree entry
index together with the timestamp to ensure both instances stay
in sync not only on timestamp but also file played.
I attached a quick-and-dirty patch, but it would need a lot
of testing, and it is very limited in what it can support.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 5271 bytes
Desc: not available
More information about the MPlayer-users