Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lost digital media server #56

Closed
wdehoog opened this issue Sep 11, 2016 · 17 comments
Closed

Lost digital media server #56

wdehoog opened this issue Sep 11, 2016 · 17 comments

Comments

@wdehoog
Copy link

wdehoog commented Sep 11, 2016

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 mopidy/mopidy-gmusic#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
Copy link
Owner

tkem commented Sep 11, 2016

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
Copy link
Author

wdehoog commented Sep 11, 2016

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
Copy link
Owner

tkem commented Sep 11, 2016

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
#56 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACs6tQpwF4shelxmPS6UFJC81qKVKIGUks5qpFMCgaJpZM4J6Ctm
.

@wdehoog
Copy link
Author

wdehoog commented Sep 11, 2016

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

@tkem
Copy link
Owner

tkem commented Sep 11, 2016

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
Copy link
Author

wdehoog commented Sep 11, 2016

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.

@wdehoog wdehoog closed this as completed Sep 11, 2016
@tkem
Copy link
Owner

tkem commented Sep 12, 2016

So this was just a temporary issue?

@wdehoog
Copy link
Author

wdehoog commented Sep 12, 2016

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 tkem reopened this Sep 12, 2016
@tkem
Copy link
Owner

tkem commented Sep 12, 2016

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
Copy link
Author

wdehoog commented Sep 12, 2016

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
Copy link
Author

wdehoog commented Sep 12, 2016

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
Copy link
Owner

tkem commented Sep 12, 2016

Hmmm... It's been a while since I tried this (intel/dleyna-server#148 (comment)), 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
Copy link
Author

wdehoog commented Sep 12, 2016

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
Copy link
Owner

tkem commented Sep 12, 2016

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
Copy link
Owner

tkem commented Sep 12, 2016

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

@wdehoog
Copy link
Author

wdehoog commented Sep 13, 2016

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.

@wdehoog wdehoog closed this as completed Sep 13, 2016
@tkem
Copy link
Owner

tkem commented Sep 13, 2016

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants