Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Library Eye]

There looks like there is no way to achieve this very simple goal. I have spent a lot of time trying. Maybe someone has an obvious solution I am missing, as it should be an obvious task. If anyone does, thanks in advance!

Here's something I do with other music playback programs, and it is my preferred way to listen to songs from various albums if I am not going to listen to the entire album at a time. Yes, it works in iTunes.

I make either a playlist, or a smart playlist, depending on other variables.

I sort by track number, and then alphabetically by album. That's it

This for me is better than random.

If I have a playlist with 20 albums, it plays the first track from album A, then the first track from album B, etc, and finally after it gets through the first track of album T, it plays the second track from album A, and the second track from album B, etc.

If album C, for instance, has two discs, iTunes will see additional sort by disc number and first play first track from disc one of album C, if disc number is known, then play the first track from disc two of album C, before moving onto first track of album D. If disc numbers are not known, it defaults to alphabetical order within multiple-disc albums.

JRiver insists on sorting entire playlist by disc number, so that no matter what sort order I choose, it first groups everything together by disc number.

All I want is to take my playlist, which is currently 4335 songs, and sort by:

Track # (a-z)
Album (a-z)

I don't particularly care how within that sort JRiver wants to order songs from a multiple disc set, they should just stay together. Discs one thru ten of ten disc album M, for instance, are still tracks from album M and hence when my playlist is playing all track 8's, it should play all the track 8's from that ten disc set, between track eight of album L and track eight of album N!

It would be logical for it to do so by disc number, so first thing i tried and which should logically work is:

Track # (a-z)
Album (a-z)
Disc # (a-z)

But no matter what i try, JRiver insists on first grouping all the albums that have no disc number assigned at top of playlist, and sorting by

Track # (a-z)
Album (a-z)

Then lumping all the disc ones into a chunk, and sorting by

Track # (a-z)
Album (a-z)

Then all the disc twos in a chunk, and sorting by

Track # (a-z)
Album (a-z)

etc

Which is useless to me. This means if there is only one disc eight in the playlist, the whole thing ends up playing in sequence at the end of playlist, instead of its tracks being sorted by track number throughout playlist with all other albums.

I simply want JRiver to follow the data i am entering: sort all songs in playlist by

Track # (a-z)
Album (a-z)

Is there a reason this is impossible? And, a way around it?

[macdonjh]

If the DISC# information isn't important to you, delete those tags.  Then none of your tracks will have disc information and they'll all be in the same group, sorted the way you want it.

For multi-disc sets, I renumber the tracks from 1 through "n" so each track gets it's own track number, even in multi-disc sets.  For example, if I have a double album and DISC 1 has eight tracks and DISC 2 has seven tracks I renumber the tracks 1-15.  Seems like if you did that you'd get the same result as well, since you'd no longer have any albums with more than one "track 1".  Renumbering the tracks is easy with Library Tools -> Fill Tracks from List Order.

[Library Eye]

Thanks. I am not deleting those tags, nor rewriting those tags just to use the very unreliable sync to handheld feature. Almost every time I connect my device, i have to reenter in all my settings as JRiver forgets them. Too bad the built-in iPod Classic sync feature has been broken for so long.
The disc number metadata is very important, just not in context of making playlist for portable device. JRiver handles disc number just fine, except for this strange fluke where it insists on sorting all playlists by disc number before track number.
You're right, that fill tracks from list order feature is very handy! I have used it for tracks missing such data. I only use JRiver for writing tags to library, not to files themselves. I use a dedicated tagging application on the occasion I want to write over actual files.

[RoderickGI]

Good find. You are correct, mostly. You have found a bug! Well, at least some unexpected and unexplained functionality, although someone may have done it deliberately.


The only part I found that I don't think is correct, as evidenced by some testing, is:

But no matter what I try, JRiver insists on first grouping all the albums that have no disc number assigned at top of playlist, <snip>

I didn't get files with no disc number sorting at the top. Those files correctly sorted among the files with a value of "1" in the [Disc #] field. I built a Playlist to test your requirements, with five Albums, two of which have 2 discs, one of which has one disc and the [Disc #] field is set to "1", and two of which have blank [Disc #] fields. See my attached image.

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

Specifically:

Another consideration for integer fields is that when sorting, a 1 value can sometimes sort indistinguishably from an empty value. The Integer type disc # field is typically empty when an album consists of only one disc, and as such, Media Center will sort the disc # values of empty (0) and 1 identically.

There is more about Zeros and Ones under Comparison Operators in the Search Language Wiki article: https://wiki.jriver.com/index.php/Search_Language#Comparison_Operators

[Disc #] is an integer field, so that above should apply to it. Particularly when the Wiki uses [Disc #] as an example! The Disc # field tag in files is stored as characters, but MC should save the value as a numeric (integer) field in its Library.


I noted a couple of issues with the Playlist sort.

1. MC sorted the Playlist first by [Disc #], then [Track #], then [Album], even though I only sorted by [Track #], then [Album], as you can see by the sort markers in the View columns. I even tried creating a Sort Preset that sorted only by Track # (a-z), Album (a-z), but that made no difference.
2. I did not sort by Seq(uence) number, and yet MC shows a third sort by Seq in the column heading. (Note that I had run "Update Order" on this Playlists after sorting it as shown, so the Seq numbers are actually in sequence, rather than their original sequence numbers based on how I built the Playlist.) That is a bug as well, as far as I am concerned.


That looks like something that should be fixed to me.

[blgentry]

I just tested this.  The trouble report is correct.

I suspect that, like a lot of MC views and constructs, there is "magic formatting" going on behind the scenes.  It's treating Track # and Disc # specially and sorting them according to some internal rules.

So, how to get around this?  Easy Peasey Lemon Squeezey:

Make a new library field called "Tracknum" that is calculated data.  In the calculated data area, just put:

Code: [Select]

[Track #]
This field [Tracknum] is now a synonym for Track #, except that it doesn't follow the magic rules.

I just did this, and sorted my playlist by Tracknum, Album.  It worked as expected.  I got sorting with track #1 of disc 1 and 2 sequential from the same album.  So something like

album 1 track 1
album 2 track 1 disc 1
album 2 track 1 disc 2
album 3 track 1

etc.

Brian.

[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).

[Magic_Randy]

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.

This is reasonable. Please don't change it.

[Library Eye]

It's counterintuitive that the program presents an option that doesn't actually follow the available setting (that is, we are presented with ability to sort by track number but in reality JRiver forces sorting by disc number). Is this one of those Mac-only JRiver issues? I assume it is same in Windows, but have not checked (I have the universal license, but my main use is Mac, followed by occasional use in Linux - used to be the other way around).

I ask because unfortunately I am having a problem with the workaround that I am guessing would not happen under Windows: my custom "Tracknum" field has disappeared. I created it, I used it to sort a saved playlist like I want to - actually by track number, then album, then disc number - but when I start up JRiver and go back I see the playlist is no longer sorting that way, the custom field is no longer available, and I have  to recreate the custom field.

I recreate the custom field, resort the same playlist, and everything seems fine.

I quit JRiver, restart, and immediately playlist is no longer sorted as needed (defaults to something else under "edit"), and the custom field has again vanished.

So, the workaround doesn't really work.

But, i assume that Custom Fields are supposed to work, and persist, and not just vanish.

Any suggestions?

[Library Eye]

I think I figured out the vanishing custom Library field.

I was logged in to my main library via Media Server.

If I add custom field to a local library, the custom field seems to persist across restarts. If I add it when accessing library via Media Server, it goes away each time.

I can't currently add a custom field directly on the shared library computer due to another recurring Mac problem on that one (inability to open Options, which seem to open offscreen, until settings are reset, documented in other forum posts) but I have been meaning to move away from using Media Server and work with a local library to see how much faster it runs (Media Server is currently on a very slow old machine) anyway.

Thanks

[RoderickGI]

I assume it is same in Windows,

It is the same on Windows, which is where I have been testing.

It is normal behaviour for Library field and View changes made on a MC Client (what you call via Media Server) to be lost when the Client is restarted. As you noted, you must make the changes on the MC Server.