I give my vote for this suggestion. I think that playlist paths should be displayed similar as it is displayed in the Send to menu for last saved playlists with "\" between every nested level.

I do not see how your "horizontal scrolling if many levels of lists" could be an issue in the dialog where it is not an issue already in the menu.

Isn't the same thing and as such it works fine in a menu, but in a list would run into the issue I described for some users.

As I said: the right-click Send to... Playlist menu.

Which menu are you referring to?

> The main issue with this would be horizontal scrolling if many levels of
> lists or long names are used or vertical scrolling if each level is a new line.

Uh, since it is not a problem on the menu, how would it be a problem on this dialog??

The main issue with this would be horizontal scrolling if many levels of lists or long names are used or vertical scrolling if each level is a new line. I actually think that would be a huge negative of this request.

> When user double click on playlist in Track properties -> Classification -> Playlists then MM focuses the Playlist in the Main Explorer Tree.

Single-click, I find.

That's a great feature - thanks - and nice to have as workaround for the original issue but it does not satisfy my needs for full playlist names.

May I ask: would anyone here be unhappy with the list showing the full playlist name in the same way as the right-click Send to... Playlist menu? E.g. parent\child .

Chris, I believe that this http://www.ventismedia.com/mantis/view.php?id=5292 feature satisfies your needs.

i.e. When user double click on playlist in Track properties -> Classification -> Playlists then MM focuses the Playlist in the Main Explorer Tree.

Yes, the full name of a playlist is the full name, not the path. You name a folder on your computer as "Folder 2", that's the name of the folder, not "C:\Some Folder\Some Other Folder\Folder 2", that's the path, not the name. Saying "show the full name" would be relevant if for long playlists, it instead showed "This is a Long Playl..." instead of "This is a Long Playlist Entry"

And to clarify, when I wrote "belongs to," I meant it as that track is/is not in that particular playlist. I can create a manual playlist without a certain track in it, then nest another playlist under that one that does contain that certain track. While this playlist is nested under the first, the track isn't actually in/on that first playlist.

> | Parent Playlist <-- Doesn't belong to this, but it would need to be listed
> | \_ Child Playlist <-- Belongs to this, so it would be listed
> | \_ Another Child Playlist <-- Belongs to this, so it would be listed

The only problem I see there Miz comes from your particular interpretation of "belong to". I see no problem for the program.

What I would like is instead of each entry showing just the base name e.g. Another Child Playlist as currently , it shows a the full name... as a tree, or one line with reserved character separating the segments.

> And the name of a playlist is the name of a playlist.

And the full name of the playlist is the full name of the playlist.

| Parent Playlist <-- Doesn't belong to this, but it would need to be listed
| \_ Child Playlist <-- Belongs to this, so it would be listed
|    \_ Another Child Playlist <-- Belongs to this, so it would be listed

Presently, only playlists that a track belongs to is lists in this window. There isn't a list of all the playlists there, with a simply check to indicate if it's on the playlist or not (the check there is used to remove it from playlists) Thus, if a Tree method was used to indicated which playlist belongs to which parent node, you could end up with playlists in this area that the track does not belong to. Nesting playlists currently doesn't "further filter" the parent node automatically. So I could set up a 'Dummy Playlist' with no tracks added or no auto-playlist criteria simply to use it as a "folder" if you will, for other playlists. So, if a tree is used to display the path to the playlist it's actually on, that top playlist that it doesn't belong to would need to be used.

[code]| Parent Playlist <-- Doesn't belong to this, but it would need to be listed
| \_ Child Playlist <-- Belongs to this, so it would be listed
| \_ Another Child Playlist <-- Belongs to this, so it would be listed[/code]

See, if a tree is used to indicate this, then the purpose of this area would change from showing playlists it's in, to also needing to show playlists it isn't in. If this is done, might as well just duplicate the entire Playlist tree node in the Properties. Also, I believe if it appears several times in a manual playlist, then it's listed more than once in the Properties, so you would be duplicating this tree, because you couldn't simply add a second "Another Child Playlist" to the tree structure already present because that could indicate you have more than one playlist with the same name under that tree structure. Couldn't really use a parenthesis (adding how many times it's in the playlist in parenthesis or something) because then you would lose the ability to uncheck only one instance of that playlist.

And the name of a playlist is the name of a playlist. If I name a playlist "This is the Name", that's the name, if I dump it in a "This is not part of the Name" playlist, that doesn't change the fact that the first playlists' name is "This is the Name".

> The "child name" [i]is[/i] the full Playlist name though.

Well, I'd say not since it doesn't fully ID the list.

> What it seems you're looking for is showing the path, not full name. How do you propose this be done?

The same as it is done in the tree.

> That could involve listing playlists to form the tree that the file actually isn't in.

You've lost me there, Miz. Please explain.

Playlist 1/Playlist 2
Playlist 1/Playlist 2 / Playlist 3

[quote="Zeke129"]Each playlist (including child playlists) could be on their own line, but have the children indented, children of children indented twice, and so forth.[/quote]
[quote="Mizery_Made"]It still presents the issue of having to show playlists in the box that the track may not belong to, which are excluded presently.[/quote]

Well it could either highlight the playlist nodes the tracks is on or only assume the last shown playlist would be the one the tracks in which does leads to duplicate entries like so:[code]Playlist 1/Playlist 2
Playlist 1/Playlist 2 / Playlist 3[/code]
If song is on playlist 2 and 3

I don't like the new line for each node idea though, because one would need to scroll a lot if tracks are on many playlists and one heavily uses subnodes. On the other hand it would probably be the easiest to use.

> I've just checked the moderator logs and I do not see any posts of yours that have been deleted.

Thanks NH - will repost.