Unravelling of datagrid entries in Album sort mode...

[colinjones]

Sorry to bring this subject up again! It has been discussed numerous times by people like me and Totallymaxed, etc... but I cannot recall what the status of this bug was, and I get mixed up as to exactly when it happens... I just came across it again so I thought I would put it down in writing as a line in the sand.

When browsing audio media in Album sort mode, albums that consist of tracks that come from more than one artist (eg compilations, dance music, classical, etc) each artist has its own Album tile in the Album sort mode, when you click on one of these identical "Album" tiles it takes you to a datagrid of the tracks attributed to that artist. Only once you click on a track do you get any indication of which artist it is.

Clearly, the Album sort should group together all album titles into a single unique instance for each. Then I would propose that under this either all the tracks are listed if all have the same Artist attribute, or if there are at least 2 Artists, then an additional datagrid layer be added between the Album datagrid and the track datagrid that lists/groups the artists together.

The first part of this (the symptoms) are looking for a bug fix, the latter (conditionally adding an extra datagrid layer) is, of course, looking for new functionality - I should have made that clear.

Either way, I'm sure that this has been fixed in the past (there maybe other sorts/instances where this behaviour occurs) but it seems to be back - I vaguely recall Andrew mentioning that it was fixed in an earlier version (perhaps b3 or b4) but came back in rc2 - my question is, has this been resolved and included in the 0810 alphas? (the bug, not the extra functionality)

The other point, that I believe Thom backed as well, was to add a little extra in the datagrid views in the way of indicating what view you are in and how things are grouped. Personally, I believe that a "bread crumbs" approach would be the most user friendly, as it would give a clear indication of the heirarchy level and aid it learning how to use sorts more efficiently - this could continue into the feature where when a track it about to be selected, you can click on one of the black attribute boxes to filter as this also obeys the heirarchy and often you need to hit back a few times to capture all of that attribute.

This is starting to get into the question of the nomenclature/labelling of Sorts and filters, so I will leave that to another time


EDIT:

As an example of where this seems to work well - in Performer sort mode, when you have a performer that you have more than one album of, it doesn't display the performer's name in multiple tiles, one for each album. There is one performer tile, then all the albums are listed beneath this when you click. And finally, all the tracks for the album you pick are listed beneath the album tile...

[chriss]

collinjones,

When browsing audio media in Album sort mode, albums that consist of tracks that come from more than one artist (eg compilations, dance music, classical, etc) each artist has its own Album tile in the Album sort mode

I cannot reproduce this behavior on my machine (0710) but I encountered similar problems before: UpdateMedia created separate album entries in the media database for each track (sometimes even several entries per track which ended up in >100 duplicated entries) which showed up as separate albums in the UI later. First thing I fixed was cleaning my media database, I created a patch to merge those duplicated attributes easily (can't find it on trac right now, seems I still have to submit it). You should check if the albums are there only once in webadmin->media browser. However, this does not explain, why those duplicated attributes are created by UpdateMedia...

Personally, I believe that a "bread crumbs" approach would be the most user friendly, as it would give a clear indication of the heirarchy level and aid it learning how to use sorts more efficiently - this could continue into the feature where when a track it about to be selected, you can click on one of the black attribute boxes to filter as this also obeys the heirarchy and often you need to hit back a few times to capture all of that attribute.

Sounds like a great idea to me 

/chriss

[colinjones]

/chriss

That sounds like a different issue - what I'm describing is not an UpdateMedia issue, it is a SQL query issue when the Orbiter creates the datagrids. Essentially (although I haven't looked at the code yet) it is a Group issue from the looks....

[chriss]

yes, the original problem is an UpdateMedia issue but IMHO having the orbiter show all album entries in the media db is not a bug. So my suggestion is to check if you have multiple db records for the album and clean this up.

[colinjones]

sorry chris, you aren't talking about the same thing. This isn't an updatemedia issue...

[chriss]

collinjones, maybe you don't see the point I want to make please don't take this post as an offense, I'm just trying to understand...

First let me tell you again... I'm having tenth of compilations (one album with several performers) which are tagged correctly. All files of an album share the same attribute, i.e., not just attributes with the same title but the same db record. These albums are shown correctly in the datagrids: there is just one entry and if I select one of them, I get a new screen with all tracks belonging to that compilation, where each track has a different title and performer.
To me, this looks like the DB queries, especially the group operation (something like group by PK_Attribute) is working fine.

Now back to my first posting. Some weeks ago it seemed I had the same problem you are having right now. Albums showed up multiple times in the orbiter and every album contained only one title of the whole compilation. Is this the same behavior you are seeing?
I tracked this down to having multiple entries for the same album (compilation) in my media database. The album title was always the same but there where several rows of data. Once I corrected this, the orbiter showed everything correctly like described above.

What I'm stating now is that the problem is probably not the orbiter query but that UpdateMedia has a bug in populating the database. You can easily verify this by going into the media browser (web admin) and check if the album title is shown multiple times (ff you edit one of the attributes and click 'update', webadmin should ask you if you want to merge the attribute. you can do this several times, until there is only one single database entry left).

If you still think, there is another problem could you explain it further to me so I can understand? Thanks in advance.

br,
/chriss

[colinjones]

chriss

... ok, I think I now understand where you are coming from! Not sure exactly what you are pointing at, but I did use the MySQL Query Browser and looked at the Attribute table and there are certainly many instances of the same Album attribute for this compilation. Obviously, seem a little redundant! But I'm not sure how this effects it - I'm guessing the Group is done by an FK pointer, and as each of these rows has a unique (obviously) PK, then it interprets them as separate albums and lists that as such in the datagrid?

If this guess is correct, then that would seem to imply that UpdateMedia rather than the Orbiter code is at fault. The thing that confuses me is that when this subject has been discussed before (and solved!) one of the devs described this as a grouping issue in the SQL queries.... perhaps I misunderstood?

So my question to you is, if I need to roll up these rows in the Attribute table of the Media database, how do I do that and also correct the files and any other relations so that they all use the same FK pointing to the one remaining, unique Attribute entry? I note that this folder/album has over 1000 audio tracks in it, many by the same artist, so when I look in the Attribute table for the Album name I get 583 instances of the same album!!

[chriss]

then that would seem to imply that UpdateMedia rather than the Orbiter code is at fault.

that's what I was talking about 

The thing that confuses me is that when this subject has been discussed before (and solved!) one of the devs described this as a grouping issue in the SQL queries.... perhaps I misunderstood?

Well, after all it is just a conclusion of mine after seeing the behavior I described above - I haven't looked at the actual db queries.
An example why grouping the album title is no good idea might be the following scenario: imagine having a couple of albums called 'greatest hits' by different performers. If you would group this on the title you would have all those albums merged under a single button 'greatest hits'. This is not what I am expecting when browsing my albums...

So my question to you is, if I need to roll up these rows in the Attribute table of the Media database, how do I do that and also correct the files and any other relations so that they all use the same FK pointing to the one remaining, unique Attribute entry? I note that this folder/album has over 1000 audio tracks in it, many by the same artist, so when I look in the Attribute table for the Album name I get 583 instances of the same album!!

Well, either by updating the album title 538 times like described above or by applying the attached patch.

Regarding the attached patch
Beware: I created this patch, it worked for me but it is not excessively tested. I recommend to make a backup of pluto_media first.
After applying the patch, go to web admin -> media browser, activate the album checkbox and then hit the button "merge all attributes of same name and type". Note: this will merge all album titles of the same name! If you have something like in my greatest-hits-example, be sure to rename those album before (maybe something like "greatest hits (performer)") to not have them merged.

br
/chriss

[colinjones]

Thanks chriss - I will take a look into that. I don't think the "greatest hits" thing will be an issue because most albums like this would be named something like "Queen: The Greatest Hits" or something else that makes them unique, certainly mine seem to be that way, although I acknowledge that it is a possibility.

Your patch sounds good, although I'm thinking that it would need to be run again each time you added a new album like this? In which case, a mod to UpdateMedia is the longer term solution, don't you think?

Either way, I'm hoping that one of the devs that remember this issue can weigh in an clarify what they remember happened with this and where the solution might lie... Andrew, are you reading? I have a feeling I remember you commenting on this in the old mantis database on a ticket I logged...

[chriss]

You are right - this patch does not fix the issue but merely cleans up the symptoms. I think, this is why I haven't submitted it to Trac yet.

Unfortunately I didn't have the time to set up a full blown dev environment to try to fix this issue in UpdateMedia or even track it down to a code segment. I appreciate if one of the devs would comment on this, too.