Left Side / Cluster Names - Some Columns Show No Data

@outsidecontext … you probably know this one right off :slight_smile: :boom:


These columns are added, what needs to be added to get them to display data?
(Disc Number, Album, Disc Subtitle) … and any others…

I’ve narrowed it down to something in cluster.py?


This area keeps coming up when changing stuff

I imagine there’s a table, list, something, of what to do to what columns when things are changed, and something would need to be added in.

Like how Track Number shows the total tracks when it’s collapsed, but when expanded, the individual track numbers show.

I would think Disc Number isn’t much different, and it shows the disc number in the expanded listing, just not in the collapsed/title line. Though if it were the same routine, it would be telling me how many discs total, which I don’t need to know. It should show Disc Number like it shows the Album Title…

There is a column method in cluster.py (or in any other of the items, such as track, album or file). It gets called with the column name and should return the data to display. See picard/picard/cluster.py at master · metabrainz/picard · GitHub

Most of the time it just returns the corresponding tag from metadata, but it can also do something else. For cluster there is actually an exception and it is hard coded to return an empty string for the album column. Not sure why, probably I thought it would be overly redundant with the title already showing this and usually all the files added to the cluster showing the same.

I’m not sure I understand. So yes, it would behave like the track number column and shows the total number of discs for the cluster. Just that clusters usually don’t have this tag unless you set it. Clusters are really just a grouping, by itself they don’t have many tags. So this probably would need some logic to gather data from the files in the cluster.

1 Like

With regards to the Disc Number vs. Total Discs, what I mean is rather than see the Total Discs in the title line, I’d rather see the same value, just like it shows Album title in the collapsed header, and the expanded lines. As in this case, the Disc Number shows on the Expanded lines.

Like if I changed L243 to be discnumber, if I’m following properly…

Which one, 1, 2 or 3, all of them “1, 2, 3”? :smiley:

So the clusters not showing the album tag is a bug. The intention was to keep this empty for “special” clusters (the “Unclustered Files” would show “Unclustered Files” as album title, which makes not much sense), but the condition logic is wrong.

2 Likes

Well, in the case of the Disc Number, just to see what the Disc Number of that … oh. Wait. I see. If there are multiple discs in that cluster… that’s not going to work so well, yeah. Which, one … or all of them. Okay. For the moment, though, it’s not even showing me how many discs are within that cluster at the moment. On that premise I would take it that the number visible should be the total amount of different discs represented in that cluster, and not simply the %totaldiscs% tag value?

But to see the Disc Subtitle, that should be very similar to how the album title is showing…

Yes, something like this. To display something here it needs some logic to show data from the tracks.

We have an issue about similar situation on the album level. Basically for clusters and albums we could always show the common data of the files for most columns and maybe display “Different across x items” if it differs (as we do in the metadataview).

The problem is a naive implementation would iterate over the tracks/files to gather that data, which probably would kill performance if a lot of data is loaded and many columns being displayed.

At the moment each entity (album, track, cluster, file) has its own metadata object. And this can differ. E.g. you can edit the album tag for the files, but not the cluster they belong to.

To implement this cleanly we would need to maintain a tag summary on the cluster/album, which gets updated on every tag change of a child object and clearly indicates whether all tags are the same or different (kind of what happens in the metadata view).

2 Likes

That actually might be a good compromise because it’s pretty much either going to be all the same, or not.

If it’s got differences in it, then that’s why you’re working with it on the left side there. So you’d see that right away. As in of the Album Subtitle were not all the same, and you know that you’ve got one set loaded, it should be. Alas, similar to the metadata view, except that you can see the date across clusters rather than for just the selected cluster.

Kind of bouncing all over the place with this, but this helps. I see how that routine is supposed to be working now.

Thanks :slight_smile:

(As the current track that is playing, is Germany Calling by Tone Band, from 1982. )