View Issue Details

IDProjectCategoryView StatusLast Update
0008740MediaMonkey (current)DLNA/UPnPpublic2013-04-27 10:44
Status closedResolutionfixed 
Product Version4.0.7 
Target Version4.1Fixed in Version4.1 
Summary0008740: Basic Collection sub-node customization
DescriptionWith the addition of DLNA/UPnP (and HTPC mode) navigating large collections can be problematic. If you have single item scroll and 6000 items to scroll through it's impossible to reach the end. Also many DLNA clients show very limited tag information making selections more dificult. A simple solution would be the ability to add an index to the list (like Title has).
1) An effective way to do this would be to allow users to set custom Tree Nodes/Customize Tree Nodes under Tools > Options > Media Tree > Tree Nodes. User should be able to define subnodes <Genre> > <Artist> > <Album> as well as index <Field:1>. The basics for this are already available which is masks. For any more advanced tree customizations like conditions users could still be referred to the Magic Nodes addon (which doesn't work over DLNA).
2) Another way would be a more graphical solution where user can right click on a sub-node and add a sub-node. When adding/editing a sub-node an option to make it an index (ie first letter) should be available. Users should also be able to add new sub-nodes under the main Collection node (or at least edit existing once into index mode).
Additional Information
TagsNo tags attached.
Fixed in build1628


related to 0008741 new MediaMonkey Wishlist Add new Collection sub-nodes 
related to 0008110 new MediaMonkey Wishlist Add additional fields as available Tree Nodes in the Media Tree 
related to 0009264 closedLudek MediaMonkey (current) Media Sharing of custom nodes needed 
parent of 0010590 closedLudek MediaMonkey (current) Remote sync list in MMA/MM8 uses indexes 
has duplicate 0010570 closedLudek MediaMonkey (current) Consolidate UPnP index nodes 
related to 0008742 assignedrusty MediaMonkey Wishlist Customize Tag display over DLNA/UPnP 
related to 0008884 closedLudek MediaMonkey (current) Genre node shows Entire Library's Artist subnodes over UPnP 
related to 0009867 closedLudek MediaMonkey (current) Changes to media server hierarchy / sorting 
related to 0010563 closedLudek MediaMonkey (current) Title node shown over UPnP/DLNA when not enabled in Collection 
related to 0010641 closedLudek MediaMonkey (current) UPnP search functionality doesn't work as expected (regression in 1626) 
related to 0011159 assignedjiri MediaMonkey 5 Tree nodes: Show enhancements 
related to 0011792 closedLudek MediaMonkey (current) Make DLNA server custom sort capable 



2013-02-21 14:38

developer   ~0035032

I would just probably (as short term 4.1 solution) adjust the DLNA hierarchy as follows:

Instead of currrent
Music -> Artists -> ABBA
I would add
Music -> Artists -> All -> ABBA
Music -> Artists -> By Letter -> A -> ABBA

This is hierarchy that most DLNA servers use for easier navigation of large collections.

Assigned to Rusty for revision.


2013-02-21 19:12

administrator   ~0035037

Seems like a good idea. If we go this route it might also make sense to include:
Album > By Letter

BUT I'm not sure if this would cause problems for some devices since it mixes a folder (By Letter) with Albums (or was the problem only when the server returned a mix of Tracks + Albums?).


2013-02-21 21:05

developer   ~0035039

Last edited: 2013-02-21 22:01

View 2 revisions

Sure, this will be available for all person nodes (Artist, Artists, Artist & AlbumArtist, Publisher, Director, Conductor, Composer, Producer, Actor) and the Album node


2013-02-22 18:00

developer   ~0035059

Added in build 1625 as described.

For further content customization the popular Magic Nodes script can be used as it
now works via DLNA too (0009264)


2013-02-25 01:36

developer   ~0035091

Verified 1625


2013-02-25 20:00

developer   ~0035104

Title subnode misses [All] entry (inconsistent with other nodes that now have an index.


2013-02-26 10:13

developer   ~0035114

The [All] node is presented direcly under the Music node, doesn't make sense for me to make it presented also under the Title.

The inconsistency is also debatable, because Title is not a cathegory similar to Artist, Album. Mostly title is specific to only one or several tracks, I don't see much benefit adding this.

Re-closing for now, can be re-opened as another issue, but I don't see it really needed.


2013-02-26 17:42

administrator   ~0035129

I tested the implementation in build 1625 vs 1623, and I find that the new implementation is quite annoying for smaller collections (e.g. < 5000 tracks) as it requires extra steps to gain access to the content.

I would suggest that:
a) MM should only present an index for cases where the number of entries in the categories is > 250
e.g. if there are only 2 composers, the index screen shouldn't be presented.

b) it should be possible to disable the index.
e.g. on the Shared content tab:
[x] Show index for categories with many entries: _250_

Note: this is a 'nice to have'--if too difficult, we can push and hardcode 250.

c) In cases where an index is presented, it should be presented immediately under 'all'. e.g.

Instead of:
By letter

It should show:

d) In cases where an index is presented, it should be presented in a manner that combines similar letters e.g.
À and a, should both appear under 'A'

e) It might be a good idea to combine letters to avoid cases where an index item has only a single track. Ideally, MMW should generate the index dynimically so that each category contains at most X items e.g.

f) I agree with both you and lowlander. 'All' should appear sub to Title, but it shouldn't appear there and as a Top level item. In other words:
We should _move_ [All] as a root level item, as the first entry sub to Title.


2013-02-26 18:52

developer   ~0035130

Last edited: 2013-02-27 17:23

View 3 revisions

b) I agree that both Index and All should be optional. The amount could be an ini setting for now so no new strings are required for translation (and make it an Option in 4.2)

c) Removing steps makes sense and index is small enough to not reduce performance.

d) I'd personally prefer it as suggested, but wonder how this impacts users with large foreign Library.

e) I'd rather have it by letter as this results in a more consistent result (across Collections and changing Libraries).

f) I actually agree with Ludek as I was mistaken that the All node under Artist or Album showed All tracks (it doesn't) whereas under Title it would (it would be redundant to the root All node). As users should be able to disable Title (0010563) the All node in the root should remain.


2013-02-27 17:03

developer   ~0035147

Last edited: 2013-02-27 21:28

View 11 revisions

Re d)
- I would also suggest to group indexes '0','1',..,'9' under '#'
- For categories beginning with chars like '(', e.g. '(Acoustic) Album' use 'A' instead of '(' as index

Items a), b), c), d) are fixed in build 1626.

e) I also (same as Lowlander) don't tend to this approach, so I would not implement it at this stage.

f) This depends on result of 0010563 , but doesn't seem to be a big deal either way.

Resolving to test a,b,c,d in build 1626.


2013-02-27 21:25

administrator   ~0035154

Re. d) sounds good
Re. e) ok
Re. f) The question of whether an all node should appear sub to Titles involves several issues:
i) the fact that similar functionality is spread between root 'All' (which displays all tracks by Title) and 'Titles' node
ii) the fact that some users don't want the Titles node to appear (issue 0010563) if they've disabled it
iii) the fact that [all] isn't really useful when e.g. > 250 titles are in the list

With the above in mind, I would suggest:
i) Retain 'All Tracks' as the first entry, but have it function like all other nodes. i.e. when clicked:
- if < x (250) tracks, it just displays all the tracks
- if > x (250) tracks, it displays
Essentially, this is really the 'Titles' node, but I think that it should always appear, and at least we're only showing 1 node at the root (All tracks), instead of 2 (All & Titles). And this way, if the user wants to enable/disable Titles node, they can (though there's no real purpose to it).


2013-02-28 14:22

developer   ~0035163

Last edited: 2013-02-28 14:24

View 2 revisions

Fixed in build 1626.

Note that I used 'All Files' instead of 'All Tracks' for consistency and because 'All Tracks' is not usable for Video collection.
For 'All Files' and 'Title' nodes I haven't implemented d) as for the other categories, the reasons are:
- to be consistent with collection Title node in MM library
- there is usually a lot of files in library and therefore distinguishing between indexes À, A, 1, 2 makes sense for song titles (unlike artist, album).


2013-02-28 21:26

administrator   ~0035175

Verified 1626.


2013-03-06 23:10

developer   ~0035269

Album navigation fails to show any (on MMA) or shows few Albums (30 on MMW) after selecting Album > index letter


2013-03-06 23:47

developer   ~0035271

Good catch!

Fixed in build 1627.


2013-03-08 16:56

developer   ~0035294

On 1627 all Albums are shown.

I note that Albums starting with The (ignored prefix) are also showing under the index letter (ie. A shows The A.....). This seems unexpected as ignoring prefixes has not been implemented for Albums (but it has been requested by users). Furthermore these Albums are sorted last (as seen on MMW). The Album node in the Library doesn't get the same treatment. Is this intended?


2013-03-13 15:51

administrator   ~0035361

g) Yes--that's a bug. Albums should be sorted like in MM (i.e. until ignore prefix is implemented for Albums, it shouldn't ignore them).

h) Also, having played with the updated UPnP implementation for a bit, there's one case that requires too many clicks. If the number of Albums in a given category is 0, currently [All] is still displayed (e.g. for Artists&Album Artists > <Artist> where for all tracks, Album="" or Album Artist=Various). I would suggest that in such cases, it would be preferable if the server automatically displayed the content in [All] (saving an unnecessary click).


2013-03-13 21:15

developer   ~0035366

Fixed in build 1628.


2013-04-27 10:44

developer   ~0035815

Verified 1634