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 682574 - upnp browsing problems with new grilo 0.2 rb-plugin built from git r2313d70 on 20120823
upnp browsing problems with new grilo 0.2 rb-plugin built from git r2313d70 o...
Product: rhythmbox
Classification: Other
Component: Plugins (other)
Other Linux
: Normal normal
: ---
Assigned To: RhythmBox Maintainers
RhythmBox Maintainers
Depends on:
Reported: 2012-08-23 22:02 UTC by Greg Miller
Modified: 2014-05-20 17:34 UTC
See Also:
GNOME target: ---
GNOME version: ---

Possible(?) fix for this bug (1.18 KB, patch)
2014-05-13 18:05 UTC, Florian Will
none Details | Review
bad behaviour debug log (3.43 KB, text/x-log)
2014-05-18 14:28 UTC, Florian Will

Description Greg Miller 2012-08-23 22:02:00 UTC
upnp audio files served by Mediatomb fail to appear in the latest rhythmbox built from git r2313d70 on 20120823 with the new grilo v0.2 library and plugins

The directories and sub-directories of the Upnp can be seen but the audio MP3 files in the directories do not appear in the rhythmbox right hand pane.

This problem exists both on rhythmbox built on i386 (Debian testing) served by Mediatomb from Debian stable on armel and on rhythmbox built on amd64 (Debian testing) served by Mediatomb running on the same amd64 (Debian testing) host.

Instead of the files appearing, only "..." appears temporarily under the name of the directory, indicating perhaps that the uPnP browser functionality is trying to access a sub-container and just ignores the file contents of the current container.

Since both gupnp-av-cp and grilo-test-ui 0.2 can navigate the directories successfully and show the container contents viz the MP3 audio files, this would tend to indicate a problem with the rhythmbox rb-plugin for grilo.
Comment 1 Greg Miller 2014-01-24 23:52:31 UTC
Other users are beginning to notice this bug.

From <>


Rhythmbox with grilo (DLNA/UPnP) support 

The grilo plugin adds UPnP/DLNA/Jamendo support.

As of Ubuntu 13.10, the rhythmbox grilo plugin appears to be unable to browse my miniDLNA share, only the DLNA search feature and Jamendo etc. work.

Comment 2 Jonathan Matthew 2014-01-26 22:55:36 UTC
Great, maybe one of them will be able to fix it then.
Comment 3 Florian Will 2014-05-13 16:07:20 UTC
The bug I was talking about in my PPA description quoted above was actually a missing feature in miniDLNA (@parentID search support). It was added within hours of reporting it to miniDLNA, so miniDLNA (or ReadyMedia as it is called officially) 1.1.2 now works fine with grilo.

This bug is about the grilo integration in rhythmbox. Greg, can you confirm that contents of a container are displayed correctly when NOT expanding that container? Otherwise I'm experiencing a different bug.

In my case this works:
1. Start rhythmbox
2. Select my DLNA share
3. Expand "Ordner durchsuchen" (browse directories)
4. Expand "Absolute Sleep Music"
5. _DO NOT_ expand "Rain Sounds for Sleep and Relaxation"! So don't click the small arrow/triangle, just click the item text.
6. Album contents are shown (actually just 1 title in that "album") and the small arrow/triangle next to the album title disappears in tree view

This fails:
1. Start rhythmbox
2. Select my DLNA share
3. Expand "Ordner durchsuchen" (browse directories)
4. Expand "Absolute Sleep Music"
5. Expand "Rain Sounds for Sleep and Relaxation"
6. The small arrow/triangle next to the album title disappears, but no album titles are shown in the right-hand pane
7. Click the album title "Rain Sounds for Sleep and Relaxation". Still no titles are shown, the right-hand pane stays blank. There appears to be no way to access the album's titles without restarting rhythmbox and be careful next time.
Comment 4 Florian Will 2014-05-13 18:05:36 UTC
Created attachment 276468 [details] [review]
Possible(?) fix for this bug

This fixes my problem described in the last comment. I'm not entirely sure the fix is correct but didn't notice any problems when testing it.

I'll update my PPA linked above by Greg Miller to use this patch for Ubuntu 14.04 so if you're on Ubuntu you can help testing.
Comment 5 Jonathan Matthew 2014-05-18 01:02:38 UTC
That doesn't look quite right.  I'll have to think about how this should really be handled.
Comment 6 Jonathan Matthew 2014-05-18 11:25:02 UTC
current rhythmbox works with mediatomb 0.12.1 from fedora 19 as far as I can tell.
Comment 7 Florian Will 2014-05-18 13:54:51 UTC
Thanks for taking a look at this!

I can reproduce this using current git master (eeee2912). No ubuntu or other patches applied, just cloned and ./, …, make install'ed to /tmp/… prefix. The various rhythmbox deb packages are no longer installed on my system to make sure I'm not loading plugins from /var/lib/… (required XDG_DATA_DIRS to be adjusted so rhythmbox finds some settings schema).

I noticed it's the same issue with Jamendo, so it's probably not even related to the UPnP content directory service software in use.

Maybe this could be related to the grilo version?
I'm using Ubuntu Trusty with these grilo[-plugins] versions from the repository:
grilo-plugins-0.2:amd64 0.2.12-2
libgrilo-0.2-1:amd64 0.2.10-1

Is Fedora on a newer grilo release?

I'll re-add some tracing to the rb-grilo plugin now and post another comment to outline what's going on that causes this bug. Maybe you can find a better way than my patch to prevent this from happening.
Comment 8 Florian Will 2014-05-18 14:28:12 UTC
Created attachment 276727 [details]
bad behaviour debug log

This is what happens:
* When clicking the small arrow next to an album (in this case, "Simple Exercice" by "Both" on Jamendo), maybe_expand_container is called.
* maybe_expand_container calls expand_from_marker, which in turn calls start_browse to start browsing at position 0.
* grilo_browse_cb is called 7 times, once for each song, with "remaining" ranging from 6 to 0.
* since GRL_IS_MEDIA_BOX returns true each time, the browse_got_media variable is set to TRUE repeatedly

* Once grilo_browse_cb is called with remaining=0, the browse_got_results is TRUE, thus the second case in the 3-way if is chosen.
* The CONTAINER_GIVE_UP_POINT is not reached yet, so control continues into the "else" branch
* The current browse position of 7 is stored in the tree store and maybe_expand_container is called
* maybe_expand_container calls expand_from_marker, which in turn calls start_browse again, but this time with a parameter of position=7
* This is where bad things happen: start_browse resets browse_got_media to FALSE

* This time, grilo_browse_cb is called without valid media and just once with remaining=0, so neither browse_got_media nor browse_got_media are set to TRUE.
* The first if-branch in the 3-way-if is chosen, and set_container_type is called with FALSE to set the current container to CONTAINER_NO_MEDIA.
* subsequently clicking the container in the browse tree does nothing, because it has CONTAINER_NO_MEDIA.

So.. maybe grilo changed its callback-calling behaviour in a newer/older version? Which part of the sequence above is actually wrong?
I'm attaching a debug log of the sequence described above with the tracing rb_debug calls I added for debugging.
Comment 9 Florian Will 2014-05-18 14:31:21 UTC
Sorry, just noticed two typos:

s/GRL_IS_MEDIA_BOX/GRL_IS_MEDIA_AUDIO/ for the 4th bullet point in the first section

s/browse_got_media/browse_got_results/ for one of the variables in the first bullet point of the 3rd section
Comment 10 Jonathan Matthew 2014-05-20 12:32:11 UTC
commit b22af11 fixes the cases I've seen
Comment 11 Florian Will 2014-05-20 17:34:33 UTC
Many thanks Jonathan. The commit works for me.