wrong resource path with multiple Mixxx installations

[Raf Van De Meirssche]

Mixxx 1.12.0
Windows 7 Home Premium 32-bit

I already have Mixxx 1.11.0 installed.

To try out version 1.12.0 I install it in a different folder named C:\Program Files\MixxxTryOut.
The installation happens through our main user which has administrator rights.
Al goes well and Mixxx functions starts up like a charm.
So far OK.

Now I switch to another user.
Mixxx 1.12.0 does not start up.
Note that I have tried this for this user with and without administrator rights, this changes nothing.

The message says:
===================================================
Unable to upgrade your database schema to version 24
Your C:/Program Files/Mixxx/schema.xml file may be outdated.
Click OK to exit.
===================================================

Notice that it searches the schema.xml in the regular C:\Program Files\Mixxx folder, not in the new C:\Program Files\MixxxTryOut folder.
No, I did not mistake myself as you can see in the little piece of log in the attached screen print.
It states well that the applicationDirPatch is C:\Program Files\MixxxTryOut.

If I am the only one affected, this is not so urgent for me.
This PC is not my DJing PC, so I can easily uninstall 1.11.0 and solely use 1.12.0 in its default directory.

[RJ Skerry-Ryan (rryan)]

Could you post your mixxx.cfg in the MixxxTryOut and Mixxx folders?

[RJ Skerry-Ryan (rryan)]

Yea, I think we changed this on Windows in 93369f75b5938b226ad52e4c720225b7d211f2f7. Windows now uses the last resource-path used and if that doesn't exist then it uses the application path.

So maybe we should revert that...

[Raf Van De Meirssche (rafvdm)]

@RJ Ryan: Already deinstalled 11 and reinstalled 12 before I saw this. :-(
I'll try to make time tomorrow to recreate the situation and post both cfg's for you.

[RJ Skerry-Ryan (rryan)]

No worries Raf, I'm 99% certain that what I mentioned was the cause.

On Sat, Nov 15, 2014 at 11:44 AM, Raf VDM <email address hidden> wrote:

> @RJ Ryan: Already deinstalled 11 and reinstalled 12 before I saw this. :-(
> I'll try to make time tomorrow to recreate the situation and post both
> cfg's for you.
>
> --
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
> https://bugs.launchpad.net/bugs/1392854
>
> Title:
> unable to upgrade database schema schema.xml
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/1392854/+subscriptions
>

[jus (jus)]

Ref LP:1225436

[RJ Skerry-Ryan (rryan)]

Fixed in 21c3269be7e918c24c6c5587a683309838ee94cf

[naught101 (naught101)]

I just got this on ubuntu trusty when upgrading from the amd64.deb 02-Nov-2014 to the amd64.deb 18-Nov-2014 from http://downloads.mixxx.org/builds/master/.

Unable to upgrade your database schema to version 24
Your /usr/local/share/mixxx/schema.xml file may be missing or invalid.
Click OK to exit.

The file *IS* missing.

Is there a work around for this? Would prefer not to wharf my database, if possible.

[RJ Skerry-Ryan (rryan)]

Don't worry -- your database is safe regardless. If you'd like you can back up your ~/.mixxx folder to be sure.

Can you list the contents of /usr/local/share/mixxx ?

[RJ Skerry-Ryan (rryan)]

Also, if you could attach your ~/.mixxx/mixxx.cfg that would be helpful.

[RJ Skerry-Ryan (rryan)]

Could you also list the contents of /usr/share/mixxx ?

[RJ Skerry-Ryan (rryan)]

Have you ever run a self-compiled development version of Mixxx?

[RJ Skerry-Ryan (rryan)]

This is likely a workaround for you:

$ mixxx --resourcePath /usr/share/mixxx

Sorry for the mess -- maybe remembering the last resourcePath should only be enabled if you explicitly run with a custom resourcePath.

[Daniel Schürmann (daschuer)]

/usr/local/share/mixxx/

should be the folder where scons install places it files.

/usr/share/mixxx

is reserved for mixxx installed by a rpm or deb.

Does it work like this?

If you install Mixxx with a package, and the build and your own version. The system should use the own version.
If the package version is updated within an update task, it should not change the custom version in /usr/local/share/mixxx/
So once you have a custom version you should stick with it.

I have not checked this, but it looks like have an issue here?

[RJ Skerry-Ryan (rryan)]

@Daniel -- yea, there was a change a little while back to use the config-stored resourcePath (i.e. the resourcePath Mixxx was last loaded with). This has had negative consequences for these default-resource-path cases when the user has run Mixxx from two different locations. My guess is that /usr/local/share/mixxx is the resource path stored in naught101's mixxx.cfg.

[naught101 (naught101)]

`mixxx --resourcePath /usr/share/mixxx` did fix the problem. Got a crap tonne of debug messages,

Yes, I have built Mixxx before, but not for a while, have installed a few of the nightly .debs since then. Guess I must have left some crap lying around, because:

$ ls /usr/local/share/mixxx
controllers mixxx skins
$ ls /usr/share/mixxx
controllers keyboard schema.xml skins translations

Sorry, I didn't check my mixxx.cfg before running that work-around, but now:

$ head ~/.mixxx/mixxx.cfg

[Config]
Version 1.12.0-alpha-pre
Path /usr/share/mixxx/
Locale

[Controls]
Tooltips 1

[Keyboard]

Library scan is taking a while. Next time I upgrade, I will remove /usr/local/share/mixxx before I do.

[naught101 (naught101)]

Maybe the error message could be changed to:

Unable to upgrade your database schema to version 24
Your /usr/local/share/mixxx/schema.xml file may be missing or invalid.
[reset to default] [quit and fix manually]

or something like that? (with some re-assurance that the library is safe, perhaps?)

[RJ Skerry-Ryan (rryan)]

> Library scan is taking a while. Next time I upgrade, I will remove /usr/local/share/mixxx before I do.

Scan takes a while on the first upgrade to 1.12.0 since it scans your whole library for cover art. It won't take that long on re-scan.

The problem wasn't the folder /usr/local/share/mixxx -- it was that your mixxx.cfg had a pointer to /usr/local/share/mixxx when the latest version of Mixxx you installed had its resource files in /usr/share/mixxx.

[RJ Skerry-Ryan (rryan)]

Oh sorry, I'm wrong -- it does test whether /usr/local/share/mixxx exists and in this case it did for naught101.

[RJ Skerry-Ryan (rryan)]

So, I think the solution is to only store the resource path in the config if the user explicitly set it via commandline args?

Or ditch this feature entirely since the only reason we added it was so you could run Mixxx out of a git repository or a build folder and we have specific checks for 'res' and 'XXX_build' existing now.

[RJ Skerry-Ryan (rryan)]

(By "this feature" I mean storing the resource path in the config not the --resourcePath command line flag)

[Daniel Schürmann (daschuer)]

+1 for not storing the resourcePath. This may explain some skin issues I head.

[RJ Skerry-Ryan (rryan)]

Removed in https://github.com/mixxxdj/mixxx/commit/606eadfd6d379ef124a4afef0068032075077e1a

[Raf Van De Meirssche (rafvdm)]

Didn't have the courage yet to try this again, but judging the above communication, I guess this will indeed be solved.

Thank you.

[Swiftb0y (swiftb0y)]

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/7651