More > JRiver Media Center 25 for Mac

Can't sort a playlist by track number without it restarting the sort per disc#

<< < (2/3) > >>

RoderickGI:
That would fix the issue, but when a using explicit sorting in a View, any View which is a simple file list, MC shouldn't use "Magic Sorting" behind the scenes, I would think.

After all, before applying specific sorting to a Playlist, you can just drag and drop or use the "Move Up" and "Move Down" buttons to resort Playlist tracks manually.

I see the standard Album View uses the "Magic Sorting" behind the scenes as well. I can't sort just by Track # in that. But it uses Grouping and "Sort inside Group" functionality. If you set Grouping to "None" then you can sort by [Track #] alone, without the "Magic Sorting". Same with the standard Files View. Playlists don't use Grouping, so you can't turn it off to fix the observed problem.

I think this one should be fixed in standard MC functionality, without the workaround.

blgentry:
Just to be clear:

1.  My use of the phrase "magic formatting" or "magic sorting" is only intended to show that I do not know how it works and it is hidden.  It's not meant to be disparaging in any way.  It's magic.  :)

2.  I think this probably should be fixed, but I don't have a very strong opinion.  That's why I offered my workaround.

Thanks,

Brian.

Matt:
A sort by track number does insert disc number in front of the track number.  I think that's a pretty reasonable thing.  That way disc one comes before disc two instead of mixing them together.

RoderickGI:
Thanks Brian. I didn't think your comments were disparaging, and neither are mine meant so.

Honestly Matt, sorting in MC Views has often left me confused and wondering what on earth MC is doing. This explains some of the reason why. Having a sort applied that is not visible to a user is very confusing. See attached image. No [Disc #] sort visible in the columns. No [Disc #] sort visible in the "Set rules for display". If a sort on [Disc #] is inserted, it should at least be displayed in the column headers and in the View rules. I would think that would be reasonable.

I have been meaning to put some time aside to try to understand View sorting, particularly if Grouping is being used, but haven't gotten around to it.

There are a whole bunch of other anomalies I won't go into at the moment. But one I will mention is that on several Views, selecting Default sort and trying to work out what that actually is can become a bit of an adventure. It isn't shown in the View definition. It isn't shown in the View sort selection menus. See second image. Then while usually it is shown in the column headers, that doesn't always seem to be correct. Again, see the second image, which is Default sorted within Groups, and the Group is sorted by Name. The View is obviously Grouped by Album and sorted within that group by [Disc #] then [Track #], but the column headers show a sort by [Name]+{unknown}+[Album]+[[Disc #]. I have no idea what the second sort is. I would have to add columns until I found one with a "2" in the header.


I prefer to have control over the sorting used. I can accept that MC inserts the Disc sorting before Track number when items are being sorted in a Grouping, and the Default sorting is being used, hence already being managed by internal logic. Well, sort of accept it. It isn't really consistent with the control users have over MC Views otherwise. At worst, I think the sort applied should be shown in the column header as if a user had clicked the Disc column first and then shift-clicked the Track column. Then at least what MC was doing would be visible.

But given that a user can sort as they please, and sort by Disc+Track easily, I don't really think it is reasonable without making it obvious what MC is doing.

I understand why the [Disc #] sort insertion is being done. This is a consumer product after all. I knew it did it within Views that used Grouping. But why a Playlist, or any simple list type View?

Changing the functionality now and removing the automatic [Disc #] sort may be a hard pill to swallow, because a lot of people's Views probably rely on it. But I think it would be the right thing to do. Particularly in a Playlist, as in the OPs case.

Library Eye:
Thanks, all, for your replies and interest in this.

RoderickGI, you are of course correct. Disc # [empty] and Disc # [1] sort together, as well they should I believe. That's what i saw at first. At some point when I kept messing around trying to get result I wanted, I saw or thought I saw different behavior. I was probably just tired and happened to look at a chunk of playlist where a bunch of empty disc numbers was followed by a bunch of discs one that was followed by a set of disc twos. Either way, I really do think the logical default behavior for sorting is that empty disc field is same as disc one, and as you note ...
"The sorting of Zeros and Ones is described under the heading "Field Values: Empty, 0, and 1" in the Expression Language Wiki article: https://wiki.jriver.com/index.php/Expression_Language "

blgentry, your maneuver works. Thanks! Now, if for some horrible reason I want to ruin the sequence of Lamb Lies Down on Broadway by playing track one of disc two right after first track of disc one and confuse an already unclear plot line, I can! Or, more likely, I would use this sort as I describe: to play a wide selection of music without using "random" and get through a set of albums that maybe I don't ever intend to listen in their entirety in a single sitting.

The workaround works, though I was finding it very surprising that sorting didn't work as expected since JRiver presents these fields as sortable yet clearly kept doing something I did assume was an understandable intentional design / coding decision (forcing disc numbers to group together) when that's not what I wanted. And I don't think I would have expected that a custom track number field would sort differently than the built-in field; maybe eventually I would have tried it, though I would not have known the proper way to format it (as calculated data).

Navigation

[0] Message Index

[#] Next page

[*] Previous page