New to Minimserver - a few questions

[simoncn]

(12-07-2013 11:42)realmassy Wrote:  Can i have something like this with MinimServer? In MinimServer I've have to choose the 'Genre' folder under 'Composer' to display all the genres for examples, which makes the browsing a bit 'convoluted'

(14-07-2013 07:34)Oliviander Wrote:  Hi Simon,
I think you didn't get what realmassy is really looking for.
I think he has the same concern about minimserver that I
had mentionened in my feature proposal of a quickselect path in March:

It seems that my original reply didn't address the OP's request to be able to use a predefined browsing path.

I had some requests for this in the early days of MinimServer, specifically for the case of Artist/Album browsing, which takes one more click with MinimServer than with some other servers (Artist -> artist name -> Album -> album name instead of Artist/Album -> artist name -> album name).

I think this could be added fairly easily by extending indexTags to allow browsing paths as well as single index entries. For example, if indexTags contains the value Artist/Album, this would add the above Artist/Album "quick select" path alongside other index entries.

This is fairly simple to understand and not too difficult to implement, but it doesn't fully satisfy the OP's request, for two reasons:

1) The request is for a longer path: Composer/Genre/Work Title/ArtistWithYear (sorry, but I don't quite understand how the Grouping custom tag comes into play). This longer path would be cumbersome to display in a control point with limited screen size, so some kind of aliasing capability would be needed, such as Classical={Composer/Genre/Work Title/ArtistWithYear}.

2) ArtistWithYear is a combination of values from two different tags (Artist and Date), so this would need an enhancement to the tagFormat property to allow combination index tags to be defined. For example, this combination could be specified as ArtistWithYear.indexFormat={$artist^$date.index^, } together with the tagOptions setting Date.indexValue.yearOnly. This seems like a significant increase in complexity.

Given that something like this is possible, the question is whether the reduction in the number of browsing steps would be worth the extra complexity of adding these new mechanisms. Another question is whether the work needed to support this should take priority over other requested enhancements such as UPnP search, a "recently added" playlist, and automatic rescanning for newly added music. I would welcome any feedback on this.

[realmassy]

Sorry for the late reply, just noticed the answers to my question.

Oliviander is right, I know I can index custom tags, but that's not what I want, I want to browse the library without having to click on the 'container' (genre, artist etc etc).
I have no idea how difficult is to implement but that is something that is possible using JRiver, and I liked the idea MinimServer could do that. Thanks anyway for your replies.

[simoncn]

(14-07-2013 17:37)realmassy Wrote:  Sorry for the late reply, just noticed the answers to my question.

Oliviander is right, I know I can index custom tags, but that's not what I want, I want to browse the library without having to click on the 'container' (genre, artist etc etc).
I have no idea how difficult is to implement but that is something that is possible using JRiver, and I liked the idea MinimServer could do that. Thanks anyway for your replies.

Can you explain how the Grouping tag comes into play? For the third step after selecting the composer and genre, do you want to select Work Title or Grouping? Or do you sometimes want to select Work Title and sometimes select Grouping?

Also, is the Artist/Year combination selection built in to JRiver, or did you do some customisation to create this?

[winxi]

(14-07-2013 16:14)simoncn Wrote:  It seems that my original reply didn't address the OP's request to be able to use a predefined browsing path.

I had some requests for this in the early days of MinimServer, specifically for the case of Artist/Album browsing, which takes one more click with MinimServer than with some other servers (Artist -> artist name -> Album -> album name instead of Artist/Album -> artist name -> album name).

I think this could be added fairly easily by extending indexTags to allow browsing paths as well as single index entries. For example, if indexTags contains the value Artist/Album, this would add the above Artist/Album "quick select" path alongside other index entries.

This is fairly simple to understand and not too difficult to implement, but it doesn't fully satisfy the OP's request, for two reasons:

1) The request is for a longer path: Composer/Genre/Work Title/ArtistWithYear (sorry, but I don't quite understand how the Grouping custom tag comes into play). This longer path would be cumbersome to display in a control point with limited screen size, so some kind of aliasing capability would be needed, such as Classical={Composer/Genre/Work Title/ArtistWithYear}.

This is an interesting idea and would be surely useful in some situations. For reasons of consistency with the other aliasing capabilities which are already implemented, it may be better to use {Composer/Genre/Work Title/ArtistWithYear}:Classical instead of Classical={Composer/Genre/Work Title/ArtistWithYear}.
In this context I would like to suggest again that it would be great to have the ability to move/rename/remove the 'All albums', 'All items', 'All playlists', 'Untagged items' and 'Folder view' selection choices in the browsing tree, too. From the users point of view it is not easily comprehensible why these shouldn't be treated like the regular index tag choices. Maybe they could be added to the special index tags with e.g. #AllAlbums, #AllItems, ...

Quote:2) ArtistWithYear is a combination of values from two different tags (Artist and Date), so this would need an enhancement to the tagFormat property to allow combination index tags to be defined. For example, this combination could be specified as ArtistWithYear.indexFormat={$artist^$date.index^, } together with the tagOptions setting Date.indexValue.yearOnly. This seems like a significant increase in complexity.

This sounds quite interesting, too. However, I agree that this would be way too complicated to set up for most of the users.

Quote:Given that something like this is possible, the question is whether the reduction in the number of browsing steps would be worth the extra complexity of adding these new mechanisms. Another question is whether the work needed to support this should take priority over other requested enhancements such as UPnP search, a "recently added" playlist, and automatic rescanning for newly added music. I would welcome any feedback on this.

My greatest which for possible future enhancements is UPnP search for various reasons. I think that MinimServer in its current state is already a really sophisticated software, I consider all the other mentioned features just as 'nice to have', but not as essential as UPnP search.

[Oliviander]

(15-07-2013 00:16)winxi Wrote:  My greatest which for possible future enhancements is UPnP search for various reasons. I think that MinimServer in its current state is already a really sophisticated software, I consider all the other mentioned features just as 'nice to have', but not as essential as UPnP search.

I'd like to decide too, but actually I don't know what "Upnp Search" is
Can somebody help ?

[simoncn]

(17-07-2013 22:54)Oliviander Wrote:  I'd like to decide too, but actually I don't know what "Upnp Search" is
Can somebody help ?

It allows a UPnP control point to do a text search of the server library contents in addition to using the browse tree.

[Oliviander]

(18-07-2013 07:33)simoncn Wrote:  

(17-07-2013 22:54)Oliviander Wrote:  I'd like to decide too, but actually I don't know what "Upnp Search" is
Can somebody help ?

It allows a UPnP control point to do a text search of the server library contents in addition to using the browse tree.

Huuh, that sounds rather difficult to implement.
And I'm not sure that I even have an occasional use for that feature?
Nice to have, but no priority for me at all.
(I know my Musiccollection )

I would gladly prefer a predefined search tree.
Why ?
Because that would be a significant speedup
all the time I select music.

[stampie]

(08-05-2013 19:27)simoncn Wrote:  

(08-05-2013 12:49)stampie Wrote:  Hi Simon, results as follows:

(Used two albums to test, both with 600*600 art c. 200kb in size)

(Current) FLAC files with embedded art + Folder.jpg = NOT cached
FLAC files with embedded art (NO Folder.jpg) = NOT cached
FLAC files NO embedded art + Folder.jpg = cached
MP3 files with embedded art + Folder.jpg = NOT cached
MP3 files NO embedded art + Folder.jpg = cached

I also tested the same files with no images at all; as expected no images are shown in n-Stream.

I cleared the cache between each test and then re-checked once I had set it all back to confirm original behaviour still occurring.

Hope this helps!?
Nick

As discussed by PM (and posted here for the benefit of other forum readers), this problem is caused by MinimServer creating album art URIs for embedded album art that are longer than some limit imposed by n-stream for caching. I'll contact Naim to see what they say about this.

Hi Simon, now that the latest version of nStream is out, I did a quick check to see if Naim have changed the behaviour of the app - sorry to say that the caching (or not!) of images still acts the same way, so the URI bug we identified is still present.

regards
Nick

[simoncn]

(18-08-2013 18:38)stampie Wrote:  Hi Simon, now that the latest version of nStream is out, I did a quick check to see if Naim have changed the behaviour of the app - sorry to say that the caching (or not!) of images still acts the same way, so the URI bug we identified is still present.

regards
Nick

I'm sorry to hear that. My contact at Naim didn't respond to the email I sent him about this, so it seems Naim are not bothered about issues like this.

The onlly solution is to reduce the length of your folder names and/or filenames until all your paths are under the Naim limit.

Edit: I've sent another email to Naim asking if they have any plans to fix this.

[Oliviander]

(14-07-2013 16:14)simoncn Wrote:  It seems that my original reply didn't address the OP's request to be able to use a predefined browsing path.

I had some requests for this in the early days of MinimServer, specifically for the case of Artist/Album browsing, which takes one more click with MinimServer than with some other servers (Artist -> artist name -> Album -> album name instead of Artist/Album -> artist name -> album name).

I think this could be added fairly easily by extending indexTags to allow browsing paths as well as single index entries. For example, if indexTags contains the value Artist/Album, this would add the above Artist/Album "quick select" path alongside other index entries.

This is fairly simple to understand and not too difficult to implement, but it doesn't fully satisfy the OP's request, for two reasons:

1) The request is for a longer path: Composer/Genre/Work Title/ArtistWithYear (sorry, but I don't quite understand how the Grouping custom tag comes into play). This longer path would be cumbersome to display in a control point with limited screen size, so some kind of aliasing capability would be needed, such as Classical={Composer/Genre/Work Title/ArtistWithYear}.

2) ArtistWithYear is a combination of values from two different tags (Artist and Date), so this would need an enhancement to the tagFormat property to allow combination index tags to be defined. For example, this combination could be specified as ArtistWithYear.indexFormat={$artist^$date.index^, } together with the tagOptions setting Date.indexValue.yearOnly. This seems like a significant increase in complexity.

Given that something like this is possible, the question is whether the reduction in the number of browsing steps would be worth the extra complexity of adding these new mechanisms. Another question is whether the work needed to support this should take priority over other requested enhancements such as UPnP search, a "recently added" playlist, and automatic rescanning for newly added music. I would welcome any feedback on this.

Hi Simon,
after having ripped all of my SACDs I am back to play around with MinS.
After looking up the indexFormat property in the user guide it
left me puzzled. So i searched the forum and landed here.
So my question is this feature actually implemented by now ?
And how does it work exactly ?
Or is it just a proposal as there is nothing useful in the manual.

And that reminds me of reminding you of your promise you mad in
http://forum1613.minimserver.com/showthr...p?tid=1162
Thanks very much for your thoughtful comments and observations. I will not attempt to continue the discussion here. Instead, when the next release is out, I will revisit the documentation sections relating to the points you have raised and I will do my best to provide better explanations and clearer terminology for everything that you have listed as being baffling. This feedback is extremely useful, and I am very grateful that you have taken the time to provide it.

And with that I would very much appreciate an introduction to the logical structure of MinS and more examples:
For instance I have no idea what
TagOptions: Date.indexValue.yearOnly
actually does because that what the description says
is exactly the behaviour that I would expect
as default.
It would be very helpful if you added to all examples
in the manual
not only how to use it but actually explain the effect
by comparing:
How does it work with the option and how without.

Btw
THX for the great MinS