Skip to main content
Topic: Library Tree (Read 36191 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

@osenboz

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.

@TheQwertiest

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)

 
SimplePortal 1.0.0 RC1 © 2008-2020