Severe Bug: Inconsistent Behavior in VLC Remote (not documented)

[nonzyro]

Two Major Problems in VLC 2.2.4: This thread is dealing with behavior *only*

Okay, let me try to be brief.VLC has a remote interface (well multiple ones). However they do not behave with *any* consistency. This is sort of a short version of what I've been through the past few weeks...

For standard rc, we'll connect to our local machine via port 1234. Now we'll issue some commands from the VLC documentation:

Code: Select all

$ echo "pause" | localhost 1234 -- Works, pause/play toggles $ echo "seek +2" | localhost 1234 -- Works, no problems $ echo "slower" | localhost 1234 -- FAILS $ echo "faster" | localhost 1234 -- FAILS $ echo "rate 0.5" | localhost 1234 -- Works, but completely UNDOCUMENTED

Okay, we've established that doesn't work so well with a typical network protocol. The problem is easy to fix: Change the VLC documentation. Well, actually it may not be so simple.

Well, okay maybe DBus is the way to go. Yeah, VLC support MPRIS, so that should be easy. I'm new to DBus but lemme give it a shot.

Code: Select all

$ dbus-send --print-reply --session --dest=org.mpris.MediaPlayer2.vlc /org/mpris/MediaPlayer2 org.mpris.MediaPlayer2.Player.PlayPause -- Works, yaay. Cool $ dbus-send --print-reply --session --dest=org.mpris.MediaPlayer2.vlc /org/mpris/MediaPlayer2 org.mpris.MediaPlayer2.Player.Seek int64:"-10000000" -- Works, yay. Cool $ dbus-send --print-reply --session --dest=org.mpris.MediaPlayer2.vlc /org/mpris/MediaPlayer2 org.mpris.MediaPlayer2.Player.Rate double:"0.5" -- FAIL. Method "Rate" with signature "d" on interface "org.mpris.MediaPlayer2.Player" doesn't exist

Okay, maybe I did something wrong, nobody ever got back to me except to say "you're doing it wrong" which was about as helpful as posting, "I is cat, can I haz milk." Well, I double, triple, quadruple, and hex-something-le checked MPRIS spec, don't see none wrong, but I'll stand corrected. Still, couldn't use it so onwards...

Now we'll try using UNIX sockets. It is cleaner than the telnet method and make more sense for a local remote in any case (although DBus seemed the *best* solution). In this case /tmp/vlc.sock will be the socket to create.

Code: Select all

$ echo "pause" | nc.openbsd -U /tmp/vlc.sock -- Works, no errors. Yay, good. $ echo "rate 0.5" | nc.openbsd -U /tmp/vlc.sock -- FAIL, Unknown command. Lol, GTFO user. $ echo "slower" | nc.openbsd -U /tmp/vlc.sock -- Works, no errors, WTH dude?

Great, so the documentation for the remote module *is* right, wait, no, oh, aaaaaargh, slam keyboard... Sooooo....

In conclusion...

Commands, Documentation
Rate:
Dbus(y), Telnet(n), UNIX Socket(n)

Faster/Slower:
Dbus(n), Telnet(y), UNIX Socket(y)

Commands, Reality
Rate:
Dbus(n), Telnet(n), UNIX Socket(n)

Faster/Slower:
Dbus(n), Telnet(n), UNIX Socket(y)

"Reality is string than Documentation" -- nonzyro.

So, that's my report. Don't know what to suggest. Changing the documentation would be easier, but changing the code would probably be for the best. The code need only have functionality added, nothing removed so that compatibility would be maintained.

[Rémi Denis-Courmont]

1) faster and slower commands work fine here (VLC 3.0)
2) MPRIS does not define a Rate property: https://specifications.freedesktop.org/ ... rface.html -> User error.
3) The "old" native RC interface is no longer maintained.

[nonzyro]

1) faster and slower commands work fine here (VLC 3.0)

Glad to hear it's been fixed, I'll trust your word and wait until 3.0 gets a backport to Jessie. Thanks a lot for that!

2) MPRIS does not define a Rate property: https://specifications.freedesktop.org/ ... rface.html -> User error.

Anno, senpai, I'm confused. The manual says this:

Rate — d (Playback_Rate)
Read/Write
When this property changes, the org.freedesktop.DBus.Properties.PropertiesChanged signal is emitted with the new value.
The current playback rate.
The value must fall in the range described by MinimumRate and MaximumRate, and must not be 0.0. If playback is paused, the PlaybackStatus property should be used to indicate this. A value of 0.0 should not be set by the client. If it is, the media player should act as though Pause was called.
If the media player has no ability to play at speeds other than the normal playback rate, this must still be implemented, and must return 1.0. The MinimumRate and MaximumRate properties must also be set to 1.0.
Not all values may be accepted by the media player. It is left to media player implementations to decide how to deal with values they cannot use; they may either ignore them or pick a "best fit" value. Clients are recommended to only use sensible fractions or multiples of 1 (eg: 0.5, 0.25, 1.5, 2.0, etc).

src:https://specifications.freedesktop.org/ ... perty:Rate
I'm sorry if it's not penetrating my ditsy brain, just kinda looks like it does specify that the media play can handle it any way it sees fit, so long as it handles it.

3) The "old" native RC interface is no longer maintained.

And yet its the only interface whose behavior is defined and reliable. "Boys, go fig," -- Dot, Animaniacs. No, really, I'm grateful it isn't maintained because it works so it doesn't need fixing because "it ain't broke" ;P


On a serious note, thanks once again to the Videolan team. You're doing a great job and glad 3.0 is apparently working smoothly via the network interface. Cheers and enjoy the rest of the week (I may be out your hair for a while, a huge project rolled in, over 20 hours of raw work, plus around 4 hours QC and formatting afterwards -- yaay me).

[Rémi Denis-Courmont]

Gah. I mean there is no Rate method; Rate is a property, unlike Seek. So user error anyway.

[nonzyro]

Rate is a property,

Ooops!


Gomen. I thought the Property was "Playback_Rate" (I'm really new to Dbus). The docs aren't super-helpful and there are no examples of usage. I got all the usage code from other sources. Still, doesn't matter. So long as I have sockets, I don't have to worry about DBus (although I probably should learn how to use it at some point, it's apparently very useful and set to deprecate all The Old Ways).