GNOME Bugzilla – Bug 700062
Add UPnP Support
Last modified: 2014-05-15 14:03:34 UTC
Created attachment 243766 [details] [review] patch to support grl-upnp sources gnome-music should support UPnP/DLNA for listening to remote ressources, which is part of development "Phase 3". Grilo supports UPnP, and gnome-music already has a lot of grilo stuff for the local library, so it's not too difficult to add some basic UPnP support. I'm attaching a messy patch to use grl-upnp sources as a starting point. It has quite a few problems (see below), so it's probably not fit for inclusion. Also, it might be better to show remote ressources in a seperate UI instead of mixing them with local media. * No longer possible to respect global "offset" for "load more" due to multiple sources * Artist/Album names ordered incorrectly due to parallel loading from multiple sources * "Songs" listing for UPnP disabled on purpose (probably not feasible for large UPnP collections?) * Duplicate albums if they are available from more than 1 source * Crashes in GLib.markup_escape_text for some track names (possibly related to broken UTF8 encoding in grl-upnp/gupnp/..?)
(In reply to comment #0) > * No longer possible to respect global "offset" for "load more" due to > multiple sources One solution could be saving a different GrlOperationOptions per source, where we have the offset. So we would use the proper options for each source, keeping them separately. > * Artist/Album names ordered incorrectly due to parallel loading from > multiple sources Yes, that's a problem because we need to sort the results in the client. And it's a problem because when you press "Load more" could be that a new item appears that should be added before (to keep the sort). So user would need to scroll up/down to see the new elements added. > * "Songs" listing for UPnP disabled on purpose (probably not feasible for > large UPnP collections?) I think that problem could happen also for Albums or Artists. If you have a huge collection of music, with hundred or thousands of Albums, and depending on how fast the server can serve the data, it could be a problem. > * Duplicate albums if they are available from more than 1 source Yes. One way could be filtering (on the client) all the albums (same for artists???) that are already shown. > * Crashes in GLib.markup_escape_text for some track names (possibly related > to broken UTF8 encoding in grl-upnp/gupnp/..?) There are some servers that have problems with UTF-8 content (basically, they return wrong values). Which server are you using? Which title is working bad (and what it's the expected value)?
Another point that I almost forget: query() is not available for all the sources. It heavily depends on the server capabilities. So you need to check if query() is supported or not, before using it.
Created attachment 243797 [details] [review] grilo-upnp support check for upnp search capability.
(In reply to comment #1) > I think that problem could happen also for Albums or Artists. If you have a > huge collection of music, with hundred or thousands of Albums, and depending on > how fast the server can serve the data, it could be a problem. I agree. For that reason it might be a bad idea to start scanning every available UPnP source on start-up. > Yes. One way could be filtering (on the client) all the albums (same for > artists???) that are already shown. It appears to work fine with artists right now, no duplicates for me. > Which server are you using? Which title is working bad (and what it's the > expected value)? minidlna on Raspberry Pi from the raspbian repositories. The title is "Seit ich alles von dir weiß". I noticed it's probably off-topic for this bug, because the same thing happens when I copy the .ogg file to my local hard disk. (print()ing the title works correctly, but markup_escape_text() crashes -- the character appears to be correctly encoded as c3 9f in the .ogg file.) (In reply to comment #2) > Another point that I almost forget: query() is not available for all the > sources. Is (ops & Grl.SupportedOps.SEARCH) enough? If so, the existing check for adding the tracker source could be extended to also check upnp sources. I'm attaching an updated version of the patch. I think you pointed out good ideas to solve the other problems. I don't have enough time right now to improve the patch. Almost zero of my music files are stored on my local hard drive, so I wanted to make upnp work, and now that it works, I'm satisfied. If anyone feels like improving this: thanks. :-)
(In reply to comment #4) > Is (ops & Grl.SupportedOps.SEARCH) enough? If so, the existing check for adding > the tracker source could be extended to also check upnp sources. I'm attaching > an updated version of the patch. > Actually, it would be Grl.SupportedOps.QUERY. > > I think you pointed out good ideas to solve the other problems. I don't have > enough time right now to improve the patch. Almost zero of my music files are > stored on my local hard drive, so I wanted to make upnp work, and now that it > works, I'm satisfied. If anyone feels like improving this: thanks. :-) In any case, I think the patch is very welcomed, as it brings some problems that sooner or later gnome-music will need to solve. One of your proposals, separating content depending on the source it comes, depends on application designers: while I also agree it could solve several problems, the application is designed to aggregate all the content in the same view. Users will see their content, no matter where it's located.
(In reply to comment #4) > (In reply to comment #1) > > I think that problem could happen also for Albums or Artists. If you have a > > huge collection of music, with hundred or thousands of Albums, and depending on > > how fast the server can serve the data, it could be a problem. > > I agree. For that reason it might be a bad idea to start scanning every > available UPnP source on start-up. > > > Yes. One way could be filtering (on the client) all the albums (same for > > artists???) that are already shown. > > It appears to work fine with artists right now, no duplicates for me. We could easily add an extra step to sort out duplicates before adding them to the view. Same can be done for sorting. After we receive the 50 items from Grilo, we sort them filter them, then add them. > > > Which server are you using? Which title is working bad (and what it's the > > expected value)? > > minidlna on Raspberry Pi from the raspbian repositories. The title is "Seit ich > alles von dir weiß". > I noticed it's probably off-topic for this bug, because the same thing happens > when I copy the .ogg file to my local hard disk. (print()ing the title works > correctly, but markup_escape_text() crashes -- the character appears to be > correctly encoded as c3 9f in the .ogg file.) > > > (In reply to comment #2) > > Another point that I almost forget: query() is not available for all the > > sources. > Is (ops & Grl.SupportedOps.SEARCH) enough? If so, the existing check for adding > the tracker source could be extended to also check upnp sources. I'm attaching > an updated version of the patch. > > > I think you pointed out good ideas to solve the other problems. I don't have > enough time right now to improve the patch. Almost zero of my music files are > stored on my local hard drive, so I wanted to make upnp work, and now that it > works, I'm satisfied. If anyone feels like improving this: thanks. :-) Florian you are a hero and thanks a lot for the patch. Would be super cool if you joined us on #gnome-music on irc :D
(In reply to comment #6) > We could easily add an extra step to sort out duplicates before adding them to > the view. Same can be done for sorting. After we receive the 50 items from > Grilo, we sort them filter them, then add them. > For the sorting case, dunno if we can do as you propose, for a usability reason. The point is that when users reach the bottom, they press "Load more" to get more content. And users expect that the new content appears below, so users can continue scrolling down and, eventually, reaching the bottom, where they can press again the button to get even more content. But what users don't expect is that new content can suddenly be added before the button. It's supposed that users already saw the content there, so if new content is added above, it would mean for the users to need to review again all the content, to check if the one they're interested in has appeared there.
Created attachment 243919 [details] [review] grilo-upnp support In spite of what I said about a lack of time, I added the filtering and sorting. Since I disabled the "load more" feature (i.e. I load everything right at the start, which is okay for me), the sorting works fine. That's probably not a general solution though. So now duplicates and bad ordering are fixed. My seminar paper, on the other hand, is still non-existent (oops :D).
Can someone indicate what the state of this patch is? It says reviewed - is more work necessary, or can it be committed?
(In reply to comment #9) > Can someone indicate what the state of this patch is? It says reviewed - is > more work necessary, or can it be committed? Got reviewed a long time ago, we're gonna try to bring this in 3.13.2, setting as assigned to me
This was fixed in https://git.gnome.org/browse/gnome-music/commit/?id=0f1cb8fee59bfb5fe8a7df5e3e2d249f075c1c1e and will be a part of 3.13.2 release
Thanks for taking care of this. I'm using git master right now to test this new feature. Trying to use the search drop down and selecting a DLNA share results in a crash:
+ Trace 233604
view = stack.get_child_by_name('search')
Same crash if I just type something into the search bar. I guess this bug is already known since it's quite obvious. If it stays like that for a few days I'll report a new bug to make sure it doesn't go unnoticed by devs, maybe it's something special with my python setup. Are remote albums supposed to be shown in the "Albums" view? I only see local tracker albums in there. It's probably difficult / stupid to show Jamendo albums in that place because there are just too many Jamendo albums. But how about showing DLNA albums right next to local albums? IIRC, my old javascript patch did exactly that. The "list all containers of type album" search query had pretty good performance, so I don't see a reason why that should not be done. (I can't find a similar UPnP query in query.py, so I assume it's not implemented.) Same for artists. There are some special cases of course, like having the same album locally and in a remote DLNA share. Unless someone suggests this feature is not wanted for whatever reason, I'll create a new bug report / feature request for this as well.
(In reply to comment #12) > I'm using git master right now to test this new feature. > > Trying to use the search drop down and selecting a DLNA share results in a > crash: > I guess this bug is already known since it's quite obvious No, its not: doesn't happen to me, though I'm using a local DLNA server (rygel). Could you open a new issue on that (and attach the output of 'gnome-music -d' there)? >But how about showing DLNA albums right next to local albums? We have changed the search concept - see bug 724021.