Skip to main content


If you are using a Hotmail or Outlook email address, please change it now, as Microsoft is rejecting all email from our service outright.
Topic: Library Tree (Read 38653 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: Library Tree

Reply #75
^ That report is for v2.1.2. The issue should be fixed in the current version (v2.1.3).

Re: Library Tree

Reply #76
Thanks for this very nice script!
It works really well, however I've noticed that there seems to be an issue with sorting in "View by Folder-Structure" (using v2.1.3):
  • if I drag-and-drop an album with more than 10 tracks to a playlist using "View by Album" the resulting sort-order
     with respect to the track-numbers is fine, e.g.         1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13 ...

  • if I do the same thing with "View by Folder-Structure", i get:  20, 10, 11, 21, 01, 02, 22, 12, ....

Re: Library Tree

Reply #78


I suspect its because the track number isn't padded in the filename.
i.e. they're 1, 2, 3, 10, 11 etc as opposed to 01, 02, 03, 10, 11 etc
I could see the issue. DUI album list behaves the same way.

The order is determined by OrderByRelativePath() which I have no control over.

%tracknumber% that's used in view by album automatically pads.

Library Tree also does a display sort for displayed text strings which has full numeric handling and so all displays in the actual tree correctly. But using that string sort on the whole library instead of OrderByRelativePath() doubles the initialisation time and likely wouldn't be compatible with the condensed style that OrderByRelativePath() produces.

I always pad track numbers in filenames.


Thanks. It looks nice!

Re: Library Tree

Reply #80
Well I reproduced it with 1.3.1 beta...

Re: Library Tree

Reply #81
@WilB, osenboz's problem was the following: 10, 11 ... 20, 21 was sorted as 10, 20, 11, 21 ..., which was caused by a bug in SMP v1.2.3 that resulted in the first character of path to be ignored during sort.
`OrderByRelativePath` (bugs aside) uses the same algorithm as Windows file explorer (hence the usual 1, 10, 11... problem).

[EDIT]: Judging by the bug report, osenboz actually has a proper padding for track numbers, so they won't be affected by Windows sorting problem either =)

Re: Library Tree

Reply #82
@TheQwertiest @WilB
Thanks a lot for your updates! (since my file-namings are properly padded, updating to SpiderMonkey Panel v1.3.1 solved the problem!)

Re: Library Tree

Reply #83
Thank you for this component, it's very fast! I love the now playing filter feature.

Feature idea/request: allow specifying multiple tags at the same branch level that will create multiple entries. This is a feature of Facets. For example the first tree level could be %<artist>%OR%<album artist>%, where OR is some divider. Then under the The Beatles node, for example, you will see albums where album artist = The Beatles, and also any tracks where artist=The Beatles from other albums (without duplicate entries where album artist == artist == The Beatles)

Re: Library Tree

Reply #84
Hi @WilB , testing Library Tree right now :)
So far so good, but I have noticed a glitch maybe :
In Panel Properties, if I change _CUSTOM COLOURS/FONTS : USE from False to True, all results disappear, regardless of what I put in _CUSTOM COLOURS/FONTS : EMPTY = DEFAULT (e.g. 255-0-0). Playing a new track doesn't solve the issue.

My goal would be to keep the same font, but change its color and make it bold instead of regular. Is that possible ?
Also, I would like to know if I can rename the "All Music" to something else. Thanks !

SimplePortal 1.0.0 RC1 © 2008-2021