After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 707909 - GUPnP-DLNA hangs when no backend is available
GUPnP-DLNA hangs when no backend is available
Status: RESOLVED FIXED
Product: gupnp-dlna
Classification: Other
Component: General
0.20.x
Other Linux
: Normal normal
: ---
Assigned To: GUPnP Maintainers
GUPnP Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-09-11 13:30 UTC by Mark Ryan
Modified: 2019-02-22 06:00 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
Fix hang if no backends are available (1.86 KB, patch)
2013-09-11 13:31 UTC, Mark Ryan 		accepted-commit_now Details | Review

Description Mark Ryan 2013-09-11 13:30:05 UTC 
The trick is that it only hangs the second time a process uses it to guess a profile.  The first time an error is returned.  So you won't notice this problem with gupnp-dlna-info-2.0.  It can be easily reproduced with dLeyna though, using the dLeyna-renderer/test/cap.py test tool to push a file to a renderer.  

To reproduce:

1. Remove your backend, e.g., sudo rm /usr/local/lib/gupnp-dlna/libgstreamer.so
2. Start ./cap.py
3. Draw a little picture.
4. Push the picture to a renderer
5. Click push again

The second push attempt will hang.

The problem seems to be caused by load_metadata_backend which passes an incorrect value to g_once_init_leave.
Comment 1 Mark Ryan 2013-09-11 13:31:48 UTC 
Created attachment 254678 [details] [review]
Fix hang if no backends are available

Here's patch that should fix this issue.
Comment 2 Jens Georg 2013-11-19 08:46:24 UTC 
Review of attachment 254678 [details] [review]:

Sorry, that one went under the rader. Looks good.
Comment 3 Jussi Kukkonen 2013-11-26 09:17:57 UTC 
Attachment 254678 [details] pushed as ca60c81 - Fix hang if no backends are available