luarc rc and telnet port listening bad reporting

Using vlc 1.1.9 and starting vlc using interface "luarc", configuring lua "rc" or "telnet" to listen a localhost port using:

vlc -I lua --lua-intf telnet --lua-config "telnet={host='localhost:0'}"

or

vlc -I lua --lua-intf rc --lua-config "rc={host='localhost:0'}"

Both take a random port from the OS but report:

[0x923670] [rc] lua interface: Listening on host "localhost:0"

Also this reporting does not occur AFTER binding a listening socket to that port but happens BEFORE. Thus there is no "definitive" message about vlc being actually listening a valid port, but possible binding error messages arrive after the announcement:

[0xed0270] [rc] lua interface: Listening on host "localhost:1234". [0xed0270] [rc] main interface error: socket bind error (Permission denied) [0xed0270] [rc] main interface error: socket bind error (Permission denied)

It'd be better if "Listening on ..." message would be printed out AFTER the binding has been successfully done, with the actual port, not configured.

added 1 deleted label

Did you try VLC 1.2.0?

assigned to @linkfanel

Basically the same output with 1.2; functionality is the same for both taken port and random port (localhost:0).

vlc does not exit immediatedly if main interface fails to load (which would be great) -- the process remains uncontrollable but playing the playlist. Perhaps another ticket should be filed for a --die-without-interface config item?

Also, should the socket be attempted to be bound twice, or is this just double logged?

./vlc -v -I luarc --lua-intf rc --lua-config "rc={host='localhost:1234'}"

VLC media player 1.2.0-git Twoflower (revision 1.1.0-pre1-4359-g1d9c69bb)

[0x1bd4300] main libvlc warning: cannot read ......./vlc/src/.libs/vlc/plugins/plugins-04081e-7e8.dat (No such file or directory)

[0x1cc8250] [cli] lua interface: Listening on host "localhost:1234".

[0x1cc8250] [cli] main interface error: socket bind error (Permission denied)

[0x1cc8250] [cli] main interface error: socket bind error (Permission denied)

[0x1cc8250] [cli] lua interface error: Error loading script /home/joonas/src/vlc/share/lua/intf/cli.luac: lua/intf/modules/host.lua:199: Cannot listen on localhost:1234

I created [ticket:4752] for the --die-without-interface.

What do you expect from binding a server to an unpredictable port? Clients won't know what port to connect to. Also, this kind of behaviour is not limited to lua interfaces

added Component::Interface: other plugins label

I'd expect it to:

1. bind to random port
2. print out "Listening on host '<ip|name>:'

If binding fails, "Failed to bind to ''". Currently '' is always printed before the binding is attempted.

Client(s) can know the port to connect to from the above message.

Use case for random port binding and reading the actual port from stderr is embedding vlc instance(s) to be controlled from the process that created the vlc (child) process -- without making any assumptions about reserved ports. I think that for this kind of adhoc use of vlc, use of random ports is best practice, removing any chance of random applications taking up the configured port. As such, this will make embedded vlc process controlling setup easier.

Other choice to use random local port with vlc is to somehow guess what port is available, which is nowhere safe compared to vlc just asking OS to select the port and properly output it.

You can control the rc interface with stdin/stdout. You can redirect them from the parent process to control the child vlc with simple pipes, that's probably better than going through a socket. However, binding to an unspecified available port could be useful for automated tests too.

This also concerns at least the HTTP and RTSP server, and behaviour is inconsistent: a port value of 0 sometimes leads to the OS choosing an available port, and is sometimes replaced by a default port value. Not sure what should be done.

Replying to [comment:9 linkfanel]:

You can control the rc interface with stdin/stdout. You can redirect them from the parent process to control the child vlc with simple pipes, that's probably better than going through a socket.

As discussed previously by you and me at #videolan@freenode.net, it was discovered that the rc interface does not work on windows, which is an (unfortunate) requirement for us. So that leaves lua (rc|telnet) as our only multiplatform choice.

That stdin/stdout would be preferred. However I understood that on win32 stdin/stdout problem with lua is in rather indeterminate state and nor does oldrc with --rc-quiet work (vlc cannot receive input from the parent process, only from the command window), so I went on with socket and discovered these problems (this and [ticket:4752]).

However, binding to an unspecified available port could be useful for automated tests too.

This also concerns at least the HTTP and RTSP server, and behaviour is inconsistent: a port value of 0 sometimes leads to the OS choosing an available port, and is sometimes replaced by a default port value. Not sure what should be done.

I've never heard that while selecting a port to bound to zero would mean "default". Perhaps it might be better described by (a) user leaving the port specifier out (b) user giving "default" as port specifier e.g. "localhost:default".

This request is silly. If you want to know the port, you should use a non-zero value. Sure, getsockname() could be added. But there is no point in that. debug messages are meant for debugging not for using the software as such.

If you need to control VLC programmatically from another process, then using stdin/stdout has linkfanel already outlined is the way to go. If you need to control VLC from another host, then use a fixed port number.

And by the way, port 0 just means any. This is a standard feature of the BSD socket API, not of VLC.

added Status::will not fix label

closed