Announce: Material Skin

[dpotts]

So just to be 10% clear:

1. Use Material's search field and enter artist name
2. Click on artist, list of albums is shown
3. Click on (+) icon that is shown when hovering over an album

If that is correct, then all Material asks lms to do is add the album using its ID. I've just tried,and it seems to work for me. I have noticed that Material also sends "sort:yearalbum" - which is the sort I use for albums under an artist. Perhaps this is messing things up? As noted in my sig, you can use Material's debug to see what commands are sent to LMS.

Thanks for your reply.

It's hard for me to read the debug log, but it looks like the response to "cmd:add" employs "sort:album".

I have found another album that exhibits the problem. The key seems to be that the album has been ripped from multiple disks. For example, the second album doing this is a two-disk set with seven tracks per disk. If I click on the artist's name and then click (+) on the album, the tracks are queued in the order: 1,8,9,2,3,10,4,11,12,5,13,6,7,14. It's going in order, but with the two disks interleaved somehow. But again, if I click the (+) directly without first clicking on the artist's name, the problem goes away.

In the tags, the tracks are numbered sequentially, 1–14. There is no discnumber tag. But the filenames have not been changed from what the ripper produced. The format is "01 [artist name] - [track title].flac". So there are two files whose name starts "01", two that start "02", etc. Could that make a difference somehow?


UPDATE: I renamed the files to be sequential, "01 [artist name] - [track title].flac", "02 .....", rescanned the database, and the problem disappeared.
Also, in the case where I click (+) directly without clicking on the artist's name, the "sort:album" tag does not appear in the log.

So, it looks like that's the source of the trouble somehow. I don't know if this problem can be fixed. I have a lot of multi-disc sets!

[dpotts]

How to produce the multi-disc track order problem

You can make any album produce the bad-track-order-queue problem by changing the track numbers of the file names.

Here is an example. Below is the original file listing for an album.



The track numbers are in sequential order. Search for the artist, click the artist name, and then play the album that appears in the album list for the artist. The tracks are in the proper order, as below.



To produce the bad queue, rename the files by duplicating some of the track numbers. In the example below, I renamed "04", "05", and "06" to be "01", "02", and "03".



You can see, for example, that in the screenshot above, the second circled file name has "01" as the track number, but it's the fourth movement of the symphony.

Now rescan the database, search for the artist name, click the name, and play the album from the list that appears. The following was my result:

[cpd73]

I have found another album that exhibits the problem. The key seems to be that the album has been ripped from multiple disks. For example, the second album doing this is a two-disk set with seven tracks per disk. If I click on the artist's name and then click (+) on the album, the tracks are queued in the order: 1,8,9,2,3,10,4,11,12,5,13,6,7,14. It's going in order, but with the two disks interleaved somehow. But again, if I click the (+) directly without first clicking on the artist's name, the problem goes away.

[Edit] In the first case a "sort:" parameter is added, but not in the second. I've now updated the code for 2.4.6 to remove this "sort:" parameter, which should resolve the issue.

[carsten_h]

In the tags, the tracks are numbered sequentially, 1–14. There is no discnumber tag.

I also tried to reproduce it, but here everything is played in the correct order.
The difference is that I always have the
TRACKNUMBER/TRACKTOTAL
DISCNUMBER/DISCTOTAL
correctly set for all of my albums. The filenames are set like this (this is automatically done by the Music-App on my Mac (iTunes before) when the tags are set correctly):
<TRACKARTIST>/<ALBUM>/<DISCNUMBER>-<TRACKNUMBER> <TRACKTITLE>.mp3

[d6jg]

I also tried to reproduce it, but here everything is played in the correct order.
The difference is that I always have the
TRACKNUMBER/TRACKTOTAL
DISCNUMBER/DISCTOTAL
correctly set for all of my albums. The filenames are set like this (this is automatically done by the Music-App on my Mac (iTunes before) when the tags are set correctly):
<TRACKARTIST>/<ALBUM>/<DISCNUMBER>-<TRACKNUMBER> <TRACKTITLE>.mp3

I totally agree about using discnumber in the file name and have dbpoweramp set up accordingly. I can't remember the example but I once lost a track from Disc 1 of a multi disc set as there was an exactly similar named track on Disc 2 which overwrote it.

[slartibartfast]

I totally agree about using discnumber in the file name and have dbpoweramp set up accordingly. I can't remember the example but I once lost a track from Disc 1 of a multi disc set as there was an exactly similar named track on Disc 2 which overwrote it.

I generally rip each disc of a multi disc set into a separate sub folder.

Sent from my Pixel 3a using Tapatalk

[dpotts]

[Edit] In the first case a "sort:" parameter is added, but not in the second. I've now updated the code for 2.4.6 to remove this "sort:" parameter, which should resolve the issue.

Okay. Sorry for being unclear.

[dpotts]

I generally rip each disc of a multi disc set into a separate sub folder.

Sent from my Pixel 3a using Tapatalk

It is amazing to me that the filenames have any effect whatever. I would have supposed the track order—and everything really—is determined exclusively by the tags, as scanned into the database.

[cpd73]

Okay. Sorry for being unclear.

Actually, you weren't that unclear - just me being stoooopid

[cpd73]

It is amazing to me that the filenames have any effect whatever. I would have supposed the track order—and everything really—is determined exclusively by the tags, as scanned into the database.

Please, if you haven't already, don't rename your files. I think I have the required fix for 2.4.6 - and it'd be good to know if it really fixes the issue for you. (I'll make a release at the weekend) You should not have to rename files to get a UI to work, especially one that should be using hte metadata! As stated the "sort:" param is not required, so Material should not be adding it where it was.

[d6jg]

@craig
Reporting a buggette.
Artist Bio. If artist or AlbumArtist is multi-tagged the lookup fails with “Fetching..”
This used to work in that MAI would pull all Artist bio’s and these displayed in Material with no issue.
It may be since you added Related Artists which by definition can only work against one artist?

[dpotts]

Please, if you haven't already, don't rename your files. I think I have the required fix for 2.4.6 - and it'd be good to know if it really fixes the issue for you. (I'll make a release at the weekend) You should not have to rename files to get a UI to work, especially one that should be using hte metadata! As stated the "sort:" param is not required, so Material should not be adding it where it was.

Sure, I'll wait.

Is there a way to know when it has updated?

[slartibartfast]

Sure, I'll wait.

Is there a way to know when it has updated?

It will be announced here.

Sent from my Pixel 3a using Tapatalk

[dpotts]

Sure, I'll wait.

Is there a way to know when it has updated?

Fyi, I just had notice of an MS update, which I installed. I don't know if this was intended to include the fix, but the problem is still there and "cmd:add" still has "sort:album".

[slartibartfast]

Fyi, I just had notice of an MS update, which I installed. I don't know if this was intended to include the fix, but the problem is still there and "cmd:add" still has "sort:album".

You probably have 2.4.5. Look in Server Settings/Plugins or Information for the version number.

Sent from my Pixel 3a using Tapatalk