Lost digital media server

[wdehoog]

On my bananapi mopidy_dleyna.client is losing the connection quit fast:

2016-09-11 18:10:29,117 INFO [5404:MainThread] mopidy_dleyna.client: Found digital media server MiniDLNA Server on OpenMediaVault [uuid:4d696e69-444c-164e-9d41-02450881da25] 2016-09-11 18:12:40,220 INFO [5404:MainThread] mopidy_dleyna.client: Lost digital media server MiniDLNA Server on OpenMediaVault [uuid:4d696e69-444c-164e-9d41-02450881da25]

When refreshing the library (using a curl statment found in https://github.com/mopidy/mopidy-gmusic/issues/21) the dlna server pops up again in the list of Digital Media Servers.

I am running minidlna 1.1.5 and mopidy 2.0.1. on a banana pi running Bananian (jessie).

After the connection is lost and while selecting an album using the MusicBox frontend I get exceptions in the log like:

2016-09-11 18:12:42,553 ERROR [5404:Core-10] mopidy.core.library: dLeynaBackend backend caused an exception. Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/mopidy/core/library.py", line 19, in _backend_error_handling yield File "/usr/lib/python2.7/dist-packages/mopidy/core/library.py", line 236, in lookup result = future.get() File "/usr/lib/python2.7/dist-packages/pykka/threading.py", line 52, in get compat.reraise(_self._data['exc_info']) File "/usr/lib/python2.7/dist-packages/pykka/compat.py", line 12, in reraise exec('raise tp, value, tb') File "/usr/lib/python2.7/dist-packages/pykka/actor.py", line 201, in _actor_loop response = self._handle_receive(message) File "/usr/lib/python2.7/dist-packages/pykka/actor.py", line 295, in _handle_receive return callee(_message['args'], **message['kwargs']) File "/usr/lib/python2.7/dist-packages/mopidy_dleyna/library.py", line 125, in lookup obj = dleyna.properties(uri).get() File "/usr/lib/python2.7/dist-packages/mopidy_dleyna/client.py", line 174, in properties baseuri, objpath = self.__parseuri(uri) File "/usr/lib/python2.7/dist-packages/mopidy_dleyna/client.py", line 219, in __parseuri raise LookupError('Unknown media server UDN %s' % udn) LookupError: Unknown media server UDN uuid:4d696e69-444c-164e-9d41-02450881da25

[tkem]

Looks like correct behavior to me - connection to DLNA server is lost, so lookup raises an error. So, what's the actual issue here?

[wdehoog]

The dlna server is still there running on the same machine as mopidy. MPD can play it's music, android apps can too. The issue seems to me is losing the connection.

[tkem]

Does it stay that way, or will it eventually be "found" again by mopidy-dleyna?

Am 11.09.2016 9:14 nachm. schrieb "wdehoog" notifications@github.com:

The dlna server is still there running on the same machine as mopidy. MPD can play it's music, android apps can too. The issue seems to me is losing the connection.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/tkem/mopidy-dleyna/issues/56#issuecomment-246198258, or mute the thread https://github.com/notifications/unsubscribe-auth/ACs6tQpwF4shelxmPS6UFJC81qKVKIGUks5qpFMCgaJpZM4J6Ctm .

[wdehoog]

It stays that way until mopidy is restarted or until I refresh the library (using the curl statement found in https://github.com/mopidy/mopidy-gmusic/issues/21).

[tkem]

Glad to hear the library refresh actually works; this was added especially for situations like these, but I never was able to reproduce such a setting myself. Since this is actually dleyna-server reporting the lost connection, starting dleyna-server manually should give you more information. Setting GUPNP_DEBUG=1 might also be helpful, IIRC.

[wdehoog]

I do not know how to start dleyna-server manually. I stopped mopidy service and ran mopidy -vvv --config /etc/mopidy/mopidy.conf. It worked and no connection was lost. Then after quiting mopidy I restarted the mopidy service and again no connection was lost. So it seems to work and I should have tried to restart services before adding the issue. Sorry for this.

[tkem]

So this was just a temporary issue?

[wdehoog]

Unfortunately not. It still keeps losing the connection.

2016-09-11 22:42:08,200 INFO [8755:MainThread] mopidy_dleyna.client: Found digital media server MiniDLNA Server on OpenMediaVault [uuid:4d696e69-444c-164e-9d41-02450881da25] 2016-09-11 22:42:36,653 WARNING [8755:MainThread] mopidy.audio.gst: GStreamer warning: gst-stream-error-quark: No volume control found (3) 2016-09-11 22:44:18,700 INFO [8755:MainThread] mopidy_dleyna.client: Lost digital media server MiniDLNA Server on OpenMediaVault [uuid:4d696e69-444c-164e-9d41-02450881da25]

[tkem]

Since connection handling is done by dleyna-server and not by mopidy-dleyna, I think the best you could do is

• shut down mopidy
• start dleyna-server manually with debug output enabled:

GUPNP_DEBUG=1 /usr/local/libexec/dleyna-server-service

• start mopidy as a local user, not as a service
• if server is lost again, have a look at the output of the dleyna-server command and look for clues

[wdehoog]

When I try GUPNP_DEBUG=1 /usr/lib/dleyna-server/dleyna-server-service it aborts without output. using strace I notice connect(6, {sa_family=AF_LOCAL, sun_path="/dev/log"}, 110) = -1 ENOENT (No such file or directory)

[wdehoog]

Even when building dleyna I still cannot get the server to remain running or mopidy to produce debug output. Monitoring dbus shows only normal messages. As if dleyana realy sees the dlna server disappear. Can gssdp be the problem? Is it reasonable to call rescan every minute and then check if a new mediaserver is discovered? (I suppose it is not)

[tkem]

Hmmm... It's been a while since I tried this (https://github.com/01org/dleyna-server/issues/148#issuecomment-90982331), so frankly I can't say if this is still supposed to work. I also never did substantial testing with a DLNA server running on localhost. I'd hate to do a rescan periodically, since I'm not certain about the effect on active connections. Triggering a rescan on "server lost" events might be an option, though.

[wdehoog]

That localhost is probably the problem. I added 'lo' to network_interfaces in minidlna.conf and it seems to help. Have not seen a 'Lost' message yet and it remains visible in MusicBox.

From the minidlna man page: Network interface(s) to bind to (e.g. eth0), comma delimited. This option can be specified more than once. If unspecified or empty, minidlnad binds to all the valid network interfaces (except loopback).

[tkem]

Still puzzled about dleyna-server terminating, but the following should at least write some info to your /var/log/syslog:

export GUPNP_DEBUG=1
dbus-daemon --nofork --session

And then, in another shell, run mopidy as user. Don't know if the --nofork is strictly necessary.

[tkem]

"Except loopback"? So how does this ever get found? Well, just keep me updated how it works now ;-)

[wdehoog]

Propably dleyna broadcasts a request when it starts and minidlna answers that one so it gets discovered. After a while it will become 'lost' since it does not advertises itself anymore.

Anyway my mediaserver is still accessible so this must have been the problem.

[tkem]

One oft these days, I'll look at how SSDP really works... Glad it's working for you now! Feel free to reopen this if this issue comes up again!