GNOME Bugzilla – Bug 766723
Default ports generate errors in rhythmbox
Last modified: 2017-06-27 02:40:33 UTC
Because rhythmbox starts both DAAP and DACP, libdmapsharing generates errors. Maybe it shouldn't generate errors unless the port was not the default. Thread 1 "lt-rhythmbox" hit Breakpoint 1, 0x00007ffff29c22e0 in soup_server_listen_all () from /lib64/libsoup-2.4.so.1
+ Trace 236268
(lt-rhythmbox:22516): libdmapsharing-WARNING **: Unable to start music sharing server on port 3689: Could not listen on address 0.0.0.0, port 3689: Error binding to address: Address already in use. Trying any open IPv6 port
Filed bug 767055 against libsoup.
Still seeing this. (lt-rhythmbox:13528): libdmapsharing-WARNING **: Unable to start music sharing server on port 3689: Could not listen on address 0.0.0.0, port 3689: Error binding to address: Address already in use. Trying any open IPv6 port dev@unstable:~/source/git/rhythmbox$ shell/rhythmbox --version rhythmbox 3.4.1 libdmapsharing / 2.9.36
Created attachment 354520 [details] [review] dmap-share: Use idiomatic way of checking for errors Use the retval of the API, instead of assuming that the API will always set the error (it'd be a bug, but at least we'd go down the correct branch).
Created attachment 354521 [details] [review] dmap-share: Don't throw warnings during normal operations DACP (_touch-able._tcp) and DAAP (_daap._tcp) on macOS use the same default port, 3689, to advertise both services. A single server likely implements both protocols, and internally routes the requests. This is not the case with the libdmapsharing, with each protocol getting its own server running on the port (both in IPv4 and IPv6). When an application like rhythmbox would launch both possible types of share, the first one would go without a hitch, the second one would only be accessible via IPv6 on a different port. This doesn't make much difference as: - which port is used is ultimately unimportant as the port is advertised in mDNS - the port already being used might mean we're sharing music with another application on the same machine and none of those are programming or configuration errors. Ideally, services with the same port would share a single SoupServer, but until then, this change will not make any difference in terms of interoperability.
Merged and pushed to master. I hope to test and push a new release tonight.
Fixed in 2.9.39.