Add a workaround for SlimBugzilla:3824 (TRACKARTIST [and ALBUMARTIST] problems with MusicMagic)

[stuarth]

There's an outstanding defect in the SlimServer 6.5 series documented in  SlimBugzilla:3824 that causes problems with artists when MusicIP is being used. The result is that web navigation for artists doesn't work, and search results will omit albums you'd expect to find.

Whilst this plugin can't do anything about the web or standard search problems it can change its own search methods so that it tries to work around the problem in that bug.

This ticket therefore exists to try to implement such a workaround, and hopefully produce a new minor version of the plugin called 2.3.1.

Note that this problem only seems to affect SlimServer 6.5, and only then when MusicIP is being used - it appears to have been fixed in the 7.0 development trunk.

[stuarth]

I've produced a beta release at source:branches/2.3.1b1.

It's a very ugly and quick fix which attempts to navigate from contributors to albums via the contributor_track table rather than the contributor_album table. That might produce slightly surprising search results, but will hopefully find at least what you were expecting to find.

There are a few things worth trying out:

1. Are the correct artists returned for an artist search, even for various artist albums?
2. If you try to create a mix on one of those found artists does the SlimServer do the expected thing?
3. If you press RIGHT on one of those found artists, are the correct albums listed?
4. If you press PLAY/ADD/INSERT on one of those displayed albums, does the SlimServer do the expected thing?
5. If you try to create a mix on one of those displayed albums, does the SlimServer do the expected thing?

[stuarth]

I've CC'd those from the original Bugzilla bug so they can track and report progress of the workaround here.

Even if it seems to work, I want to clean up the ugly fix in the real 2.3.1 that I'll produce, and I release that I've not actually tested createing a MusicIP mix with this fix in place so that may be broken.

[stuarth]

I should have mentioned, but you'll need to make up a registration to put ticket comments in Trac ( http://hickinbottom.demon.co.uk/lazysearch/register) - I was getting a lot of ticket spam before I enforced that - sorry for the inconvenience.

[stuarth]

Just to clear things up - I was definitely wrong when I said that the problem no longer occurred in 7.0. I've retested it and I see that contributor missing from the contributor_album table just as I did in 6.5.

Rescanning my library with "Use MusicIP" turned off leaves those records in the contributor_album table.

So, if I can workaround this for 6.5 I'll merge the same patch into the 7.0 version of my plugin.

I'll also add this clarification to  SlimBugzilla:3824.

[Dieter]

Just a quick first test report: Artists of compilations are now found, that's the good news.

There are two small issues:

1. If you go right starting from the found artist name you will first see the album but if you again press RIGHT you will see ALL tracks of this album. However, this list should be filtered by the found artist and so only the tracks of this artist should be shown.

2. If you go further and press again RIGHT (on the found track), then scroll down to the ARTIST tag and then press RIGHT again "empty" is shown. I assume that this can't be changed through the lazysearch plugin.

But even with theses issues I would prefer the workaround over the regular version since the artists are at least found (and maybe the first issue can be resolved ;) .

[stuarth]

Thanks, Dieter.

Yes, I see that behaviour too. You're right I can't do anything about the second (well, not without providing my own trackinfo mode, which I'm not too keen on), but I should be able to do something about the first.

An alternative approach that would fix both problems would be for me to rebuild what I think should be in the contributor_album table based on the contents of the contributor_track table as part of the lazification. This would be configurable and you'd be able to turn it on (probably in some hidden way) to enable the workaround. Since the lazification runs after the main database is populated that should mean I get a chance to 'repair the damage'.

I'm not sure if that other approach would have any negative side-effects, though (is there any periodic behaviour that might undo the changes I'd made, for example), but it would have the advantage that I could avoid the messy changes to the searching and browsing that I seem to be heading down at the moment (which I always worry would have other more subtle effects that I couldn't predict). It would also be easier to drop into both the 6.5 and 7.0 versions of the plugin.

What do you think? It probably wouldn't take me too long to try to prototype up this approach.

[Dieter]

Sounds good. Can you ensure that lazfication is really running after all other database creation steps. When I tested slimserver 7.0 I recognized that the MusicIP import was at the very end. Lazification must run even after that.

Since I do not know too much about the different contributor tables I have no idea if there will be side effects, but I will test a new version (and I usually are not bad in testing new features :) I have different "artist constellations". Regular albums having only one artist and no album artist set, compilations having different (track) artists and album artist set to "Various" and the compilation flag set, albums of one artist (artist1) on which only one or a few tracks are duetts (for the duetts the artist is set to "artist1 & artist2" and "&" ist set as separation characater for the "multiple item in tags" option, and album artist is set to artist1 in these cases)...

So you see I have a lot of different cases to test and if your approach works for all of these cases there is a good chance that it's a stable solution.

If the alternative approach could also solve the second issue it would probably also solve the same "track info" issue when reaching the track info page by /browsing/ instead of /searching/. So it would be worth a trial.

Of course, the best solution would be that the bug is solved in slimserver. Do you have any idea why nobody is even responding to the bug report although I have several time asked for a response?

Last question: At the moment I get always two notification e-mails if this ticket changes. One is sent to diptvtv at gmx dot de (probably through the CC entry and the other is sent to dieterp at patente dot de (maybe I used that e-mail address when I originally registered. I would prefer to get only e-mail through diptvtv at gmx dot de but I cannot change (or even see) my e-mail stored with my account. Can you change that and then remove the CC entry?

[stuarth]

Right, I'm having a crack at the second workaround approach since it has the potential of making everything work properly and disturb the 'real' bits of the plugin the least. Work is very busy at the moment, but hope to have something you can try by the end of the weekend at the latest.

I've updated your account - first time I've had to do that with Trac, and not as easy as you'd imagine it would be (I didn't expect I'd have to administer it through an SQL command interface!). Let me know if you're still getting double emails - I'm not sure why that would be the case.

I'm not close enough to the core developers to know if they're doing anything about the real but - development seems very slow at the moment which, I suspect, is an indication that they're very busy on something they're not talking about! I might have a look at the code myself, but I suspect it'll be difficult for an outsider to understand. In the short term, though, I'm pretty confident we can have a usable workaround through this plugin.

[stuarth]

Well, that's saved me the trouble! Dan's committed a change to both the 6.5 and 7.0 branches under  SlimBugzilla:3824 that appears to solve the original problem. On that basis I plan to close this ticket.

[Dieter]

I have to wait until the Windows installation package is available. So I will test it tommorow evening. Thanks again for providing a temporary workaround (even if it is no longer necessary). It seems that our correspondence in bugzilla accelerated the real solution a bit...

[stuarth]

Replying to Dieter:

I have to wait until the Windows installation package is available. So I will test it tommorow evening. Thanks again for providing a temporary workaround (even if it is no longer necessary). It seems that our correspondence in bugzilla accelerated the real solution a bit...

Yes, I think you're right, so it's not been a waste. It's also interesting to look into these things to try to track them down.