Issue 4

Hi,

A few ideas for enhancements:

1) Support searches for items - look at bubbleupnp for an example.

2) Support random play for a set of items in a container (not just the whole list). This is not the same as shuffle of a playlist. The idea is to find all the (unique) items in a container, select a random n and send these to the playlist. When the playlist is running out, add another n. This allows one to sit all day listening to things you don’t normally select, and find unusual contrasts between consecutive items. The normal playlist shuffle facility can’t do this this one would have to send thousands of items to the playlist.

3) Extend (2) to be able to play random groups of items. I don’t know if this is possible for a control point, or whether it may only be possible using minimserver. The idea is that a set of items may comprise a Work (eg a symphony) or a minimserver Group (which might be one act of an opera), or a whole Album, and one would like to play all the items in the group in their correct order, and then move on to another random group. I don’t know whether the Control Point can even see the meaning of such groups, so it may be that this isn’t possible.

As a first progress regarding the above, the current git version now supports search (and multiple directory tabs). See http://www.lesbonscomptes.com/upplay/searching.html for tips about using the search facility. When you’ll have a moment, I’d be quite interested by your feedback about what could be improved. As usual, you should build and install libupnpp, then upplay.

Hi,

I assume I have to rebuild upmpdcli as well. I took sources from the latest git. I have rebuilt and installed libupnpp.

The make of both upmpdcli and upplay fails:

g -std=c0x -g -O2 -o upmpdcli src/avtransport.o src/execmd.o src/netcon.o src/closefrom.o src/conftree.o src/conman.o src/mpdcli.o src/ohinfo.o src/ohmetacache.o src/ohplaylist.o src/ohproduct.o src/ohreceiver.o src/ohtime.o src/ohvolume.o src/renderctl.o src/upmpd.o src/upmpdutils.o -lupnpp -lmpdclient -lpthread src/ohplaylist.o: In function `OHPlaylist::urlMap(std::unordered_map<int, std::string, std::hash<int >, std::equal_to<int >, std::allocator<std::pair<int const, std::string > > >&): /home/crusty/Programs/upmpdcli-0.8.6a/src/ohplaylist.cxx:665: undefined reference to`UPnPP::ohplIdArrayToVec(std::string const&, std::vector<int, std::allocator<int > >_) collect2: error: ld returned 1 exit status make: _\ [upmpdcli] Error 1

And (sudo make install or sudo checkinstall):

g++ -m64 -o upplay .obj/ContextMenu.o .obj/GUI_Player.o .obj/GUI_PlayerConnections.o .obj/GUI_PlayerControls.o .obj/GUI_PlayerCover.o .obj/GUI_PlayerMenubar.o .obj/GUI_TrayIcon.o .obj/DirectSlider.o .obj/GUI_Playlist.o .obj/PlaylistItemDelegate.o .obj/GUI_PlaylistEntryBig.o .obj/GUI_PlaylistEntrySmall.o .obj/PlaylistItemModel.o .obj/PlaylistView.o .obj/CSettingsStorage.o .obj/Helper.o .obj/Style.o .obj/application.o .obj/dirbrowser.o .obj/cdbrowser.o .obj/Playlist.o .obj/PlaylistAVT.o .obj/PlaylistOH.o .obj/upputils.o .obj/upplay.o .obj/moc_ContextMenu.o .obj/moc_GUI_Player.o .obj/moc_GUI_TrayIcon.o .obj/moc_DirectSlider.o .obj/moc_GUI_Playlist.o .obj/moc_GUI_PlaylistEntry.o .obj/moc_GUI_PlaylistEntryBig.o .obj/moc_GUI_PlaylistEntrySmall.o .obj/moc_PlaylistItemModel.o .obj/moc_PlaylistView.o .obj/moc_renderchoose.o .obj/moc_CSettingsStorage.o .obj/moc_application.o .obj/moc_dirbrowser.o .obj/moc_cdbrowser.o .obj/moc_rreaper.o .obj/moc_Playlist.o .obj/moc_PlaylistAVT.o .obj/moc_PlaylistOH.o .obj/moc_avtadapt.o .obj/moc_ohpladapt.o .obj/moc_avtransport_qo.o .obj/moc_cdirectory_qo.o .obj/moc_ohplaylist_qo.o .obj/moc_ohtime_qo.o .obj/moc_renderingcontrol_qo.o .obj/qrc_upplay.o -L/usr/lib/x86_64-linux-gnu -lupnpp -lpthread -lQtWebKit -lQtGui -lQtNetwork -lQtCore .obj/application.o: In function `Application::setupRenderer(std::string const&): /home/crusty/Programs/upplay-0.8.6a/application.cpp:124: undefined reference to`UPnPClient::MediaRenderer::ohtm() .obj/moc_cdirectory_qo.o: In function `ContentDirectoryQO::run(): /home/crusty/Programs/upplay-0.8.6a/.moc/../upqo/cdirectory_qo.h:69: undefined reference to`UPnPClient::ContentDirectory::searchSlice(std::string const&, std::string const&, int, int, UPnPClient::UPnPDirContent&, int_, int_) .obj/moc_ohtime_qo.o: In function `OHTimeQO::time(UPnPClient::OHTime::Time&): /home/crusty/Programs/upplay-0.8.6a/.moc/../upqo/ohtime_qo.h:59: undefined reference to`UPnPClient::OHTime::time(UPnPClient::OHTime::Time&) collect2: error: ld returned 1 exit status make: *\ [upplay] Error 1

I wonder if this is due to library locations? I see libupnpp installed to /usr/local/lib (not /usr/lib).

Regards

Tim

On 09/11/14 15:53, Jean-Francois Dockes wrote:

##

email: tim@tim-passingham.co.uk

No, you don’t need to rebuild upmpdcli, it is not needed at all in relation with upplay now that I separated the library. So it’s:

I just checked on a virgin host that this worked.

The error that you are getting above seems to indicate that the new lib was not installed to /usr. Maybe you configured without the --prefix ? Maybe check the dates under /usr/include/libupnpp.

My bash history:

I just found a bug with the right click menu. Not quite ready yet… I’ll be fixing this shortly. But for now this is only good for testing the search…

The popup should be fixed

Thanks.

I use upmpdcli, so I assumed I have to rebuild it when I get a new libupnpp and build it myself. Is that not so?

I have previously never added the /usr prefix, and it seemed to work. I’ve now tried with it and it seems OK now - thanks. Note that on the upplay qmake I get:

Oops. Sorry, I thought that you had installed upmpdcli just as a side-effect of using upplay. Yes, you need to rebuild it then. Hopefully one day this lib will get a stable ABI, but it’s not quite there yet…

I’ll fix the "duplicate" message, it is of no consequence.

All up and running on one PC. I’ll now install on my laptop, try it out for a day or two and then post some comments here.

I’ve tested this with minimserver. It’s excellent. I have a few very minor comments.

On the search itself: - the server search works from where you are in the hierarchy, which is very useful - somewhat to my surprise the artist search includes all types of artist, including composer, conductor and band – that’s really good - the searches are very literal requiring an exact match to the whole string, and the string doesn’t need to be at the start of the text – this is OK for me but some may complain. - accented characters need accented input (e.g. from the character map) – again OK for me but some may expect an e to find é (etc) as well which can be challenging when all European scripts are included. - the local search on what is on display works well - if you search the server, click on a selected item and then go back, the search results are lost, so you have to repeat the search.

On the display in Dark mode: - the box on the left of the search server is not ticked when selected on one of my PCs - the search category (Artist etc) is right aligned in the list and slightly truncated with a tick on the left of the selected item (in normal mode it is left aligned with no tick)

One other comment is that having opened a new tab in the in the library list it would be useful to be able to close it.

About the search features: the UPnP interface for search is rather primitive, and, as far I know, there is no way to specify case or diacritics sensitivity, and I think that many details are left up to the server. So I guess that simoncn knows much more about what you can search for than I do. I am just passing a "prop name" contains "string" to Minim. For searching artist names, "prop name" is upnp:artist, and I guess that Minim expands this to all artist-like fields.

So, matching e to é would be something that Minim could do, not me. I could do it for the local search though, but it would be a bit complicated because I am currently letting webkit do the hard work, and I don’t think that it has an option for diacritics insensitivity.

Something which would be quite useful on the server side would be to allow for anchored searches (e.g. let the user search for ^begin-of-title if they want), because free substring matches are not always best. I don’t think that anything in UPnP prevents the passing of this kind of thing.

I have noted the issue with back, and I’ll fix it. This makes me think that I need to implement middle-click to open in new tab (this should be easy enough). Or an entry in the popup.

You can use ^W to close a tab. Don’t try it with the last tab, I just did, and it’s not a good idea :) This needs fixing too… And it would be nice to have a tab-closing button on each tab like firefox.

I have also duly noted the display issues with dark mode.

While working on the back() function in relation to search, I have come up with a question. I am going to include the searches in the context path at the top of the screen, but searches are not nested: you can’t search inside a search. When there is an intermediary directory listing (you clicked on search, then on a directory, then another search), it’s reasonably clear that the second search is not within the first one. However, when performing a search from a screen already displaying a search, it is quite tempting to believe that the second one is within the previous, when actually it is not, it is done within the last directory back in the path. I could avoid some of the confusion by refusing to store several searches at the end of the path (a new search replaces the last element if it is already a search). On the other hand, storing all searches means that you can go back to any of them, which has some limited value (it’s not a full search history because you lose the tail of the path when going back).

So I’m wondering. But the "fully stacking" version is done anyway, and maybe it would be better that you try it before we take a decision (it’s easy enough to switch, this could even be a run-time option).

Using git pull and executing ./configure again, I get a permissions problem with stamp.h1 which seems to be owned by root. This contains just "timestamp for libupnpp/config.h" I’ve changed the permissions, but it seems strange. Any thoughts?

Probably it was created by the last "make install" for some reason. This is a temporary file, you can just remove it. I just pushed the "curpath" changes, but I’m not quite sure that this is stable enough for testing, maybe you’d better wait until I’ve played with it a little more if you don’t want to lose time.

Ok, seems to work reasonably…

Since you say search within search is not available, I think I would slightly prefer that there was only one search stored and shown at any one time, with the appropriate directory preceding it, otherwise I will tend to forget and think I’m nesting the searches when I’m not. If I want to perform, and keep, multiple searches I can use a separate tab for that. On my library I am unlikely to need that level of sophistication. However, although I am not too bothered either way we are all different and some will be puzzled. Either way if it is written up clearly it will be OK for me.

It’s good to have a close tab option.

Now the trivia :-)

The Artist/Album etc look-up is still behaving differently in normal and dark modes. In Normal mode it’s still left justified without a tick, and in Dark right justified (but now not truncated) with a tick to the left. Also, on my main PC it doesn’t always show the whole list in one go. Since there are only 4 options it would be good if the list shown was always at least 4 long.

The latest version should fix the following: - Search lost on "Back" - Search server checkbox tick in dark mode - Search category dropdown truncated: should be better but it still sometimes glitches on me, reason unknown, I’m not too good with Qt styles.

I kept the Search stacking as it is for now (out of time). I think I’ll make it an option. I changed the separator between 2 search indicators in the path as a slight reminder that they are not nested.

In addition: - You can middle-click on any container link or any element of the path at the top (including searches) to open them in a new tab. - You can save/load local playlists. - You can move playlists from renderer to renderer.

Forgot: you were right to open another issue. I think it would be best to have one GitHub issue per feature or defect, it will make it much easier to keep track of what’s done or not.

The random playing ideas at the top of this issue sort of got drowned in other stuff.

The first one seems to be a consequence of an OpenHome renderer not being able with a few thousand entries in a Playlist ? Neither upplay on a decent PC (for local playlist handling with UPnP renderers), nor upmpdcli/mpd have trouble with this. Maybe the hardware ones are more difficult ?

About the second idea: do the "works" you are mentionning appear as containers in the Minim tree ? It should be possible to select random containers with tracks in them and play the tracks (but not the subcontainers) in order, then skip to some other. Not quite simple, but probably feasible in principle.

I could create 2 new issues if convenient? 1. Playing random tracks.

If I just want to play anything at all, loading all my tracks is taking dozens of minutes as I write, I have a reasonably quick server and a very quick desktop running upplay, and am using upmpdcli as a renderer on the server. Whether this delay is partly due to the container structure beneath the top level items, and duplicate checks, I don’t know. However it is not a practical solution for me.

I’ve stopped it now after waiting for over 20 minutes and it’s not half finished yet. 1. Playing random works.

This is a little complicated to explain, and may depend a lot on the server. Many of my works have multiple performances. When showing a set of works in the library list the multiple performances are shown only when you open the work and select an album, artist or whatever that distinguishes them. I don’t quite want to randomise at this level since work can hide multiple performances, so I would end up playing multiple versions of the same piece consecutively.

However, minimserver also supports group containers. These are sets of tracks. Most of my works are also groups, although in some cases a work may consist of several sections, which are separate groups. When I just show a list of items in the library I get a list of groups, and this is what I’d like to randomise. Is that possible?

All the fixes and improvements this far seem to be working well except….

The artist/album etc selection list is still different in Normal and Dark modes when you display the full list (which does now display all 4 items on both my systems). It’s odd. In Dark mode there’s a tick against the selected item. In Normal there is isn’t. But it doesn’t matter so I will not mention it again!

Hi,

I’m getting back to the Playing Random works thing (I know, long time…). I am trying to get the Minim "group" feature to work, with no success at the moment. I don’t strictly need it, because, as seen from the player a "group" is just another container, but I’m baffled. Before I go the Minim support list, could you please tell me what tag you use for grouping ? I tried with id3v2 TIT1 - CONTENTGROUP in the MinimServer tag mapping table - but no containers appear…

MinimServer uses the Group tag. I have previously used a different tag to group movements together, called Work, but since MinimServer uses Group I have duplicated Work to Group on my flacs. As you say, Group provides a container, whereas my Work can be used for indexing and browsing.

Sequential sets of tracks on an album with the same Group tag automatically appear as one container on my system using upplay. If the same Work appears on an Album (which does happen occasionally) I add a suffix to the Group tag to distinguish them.

See http://minimserver.com/ug-browsing.html#Groups and compositions.

Thanks, what I needed to do was establish an aliasTag from CONTENTGROUP to GROUP

Hi,

I’ve pushed a first version of the "random play" feature to the repository. I sort of remember that you have no issue with building upplay, but, else, I can push a binary version somewhere (you’ll need to remind me of what system you use).

The feature is accessed from the right-click menu over any container in the directory browser.

I prefer to not describe it too much, I’d rather put you in the situation of the normal user who did not read the manual. What you’ll find difficult to understand or discover will need changing. It’s quite basic in any case.

But of course, don’t lose time, and ask me if something is not clear.

The menu entry is "play by albums", but, as it seems that Minim sets the album name to the group name, this should hopefully do what we want. Else, I’ve other ideas about how to segment the list.

Let me know how this works for you !

I’m having some compilation problems (xubuntu 15.10). Do I need to update libupnpp as well? I normally use qmake, followed by sudo checkinstall (which does a proper reversible install). I have been using the master zip each time, having been slightly unclear what I get using git pull, particularly when version numbers change.

On my system, my Minim album names are not the group names. That may be an option somewhere, but my albums are definitely albums in the true sense of the word.

I can easily build some packages tomorrow. What is your machine architecture (uname -m) ?

When you display a list of tracks in the upplay directory browser, and the tracks are part of a group, what do you see in the "album" column ? I am seeing the group name (contentgroup/tit1 in my case).


OK - compilation sorted. I needed to update libupnpp first.

The result of play by albums (please don’t call it that!) is not quite as expected. If I go to a composer, and request this, I get all the versions of one work (group), from all albums, with all the 1st movements 1st, then 2nd, and so on. If I clear the playlist, it goes on to another work.

What the random play should do (in my humble opinion) is play single random instances of complete works, if you get what I mean,

It would make things easier to follow if the playlist included up to n works as well (but bear in mind a work can have 50+ tracks).

However, it’s definitely getting there!

Our posts overlapped.

In response to your query, surely what you see is the track names - album on which the tracks reside - Group - time. Or am I confused (quite possible)

About the groups mixup, obviously it’s not what I intended, I did not see the issue because I have a single album with "works" which I created for trying this, so works are unique, and there is no issue of multiple track X.

I need to properly tag a couple of albums so that I can see how things appear under the different Minimserver views, and how/if I can sort things out.

Currently the grouping is purely done in the "album" column seen in the track listings (the one before the time). If there is a group, it appears that minimserver sets its value in there in place of the album tag found in the file.

Clearly, it’s not enough to group things only from this value (because, as you saw, this will concatenate tracks from multiple albums into the same group).

More thinking is needed. If you have any idea about the question, don’t hesitate :)

I have 4 columns, not 3. I’m puzzled by your definition of album column. I see: 1 - track name 2 - album name 3 - group name 4 - time

This is true on the sample you posted. 4 columns not 3, or am losing my marbles?

Sorry, yes, I have lost my marbles. I was reading your artists as an album name. Sorry.

If you do a search by Album, you get Album names, not Group names. I therefore think minimserver is suppling group instead of album for that column where a group exists. But it definitely isn’t minimserver’s Album name, which still exists.

So it is surely random play by group?

And thanks for getting this far. I think it’s very close.