-
Notifications
You must be signed in to change notification settings - Fork 19
Unresponsiveness/crash when name is queried on a newly found renderer #156
Comments
Code to reproduce this issue (using dbus-python and python2):
Steps to reproduce: If a DLNA renderer device is already running or started after the script is started results in the Output:
Killing and restarting the script results in all calls to the dleyna-renderer service resulting in the same error. Uncommenting the line which adds time.sleep(1) 'fixes' the issue. |
You can/should delay the signal handler through the mainloop, in Qt you can a use Qt::QueuedConnection for this. otherwise you're deadlocking yourself. dLeyna sends the signal, waits for it to return while you in the signal handler wait do a DBus call to dLeyna which you wait for returning => deadlock |
Although this might be related to the use of gupnp_service_info_get_introspection:
|
If a client listening to the FoundRenderer signal queries the FriendlyName or any other property of the newly found renderer immediately, the renderer dbus service freezes. This and all subsequent calls then result in errors ["org.freedesktop.DBus.Error.NoReply", "Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken."]
I'm testing with my own C++ QtDBus client on Arch linux with dleyna-renderer-0.5.0. The same behaviour is also observed with https://github.com/linuxdeepin/deepin-movie which uses PyQt.
Steps to reproduce:
This results in a crash/freeze
Adding an usleep(1000*1000); after the signal is received, before trying to read the FriendlyName prevents the crash for some reason.
The text was updated successfully, but these errors were encountered: