Upgrade to 2.0.3 eats settings: custom soundfont path is lost

• Apr 6, 2016 - 09:40
Reported version
2.2
Type
Functional
Severity
S4 - Minor
Status
closed
Project

After an upgrade to 2.0.3 MuseScore reads old ini setting "sfPath" and deletes it. However, it doesn't save paths to new "mySoundfontsPath". On the next launch old setting is lost and MuseScore creates default.


Comments

Mmm that shouldn't happen.

https://github.com/musescore/MuseScore/blob/2.0.3/mscore/preferences.cp…

We read sfPath (and set it to a default if not found). Then we delete it from preferences to make sure sfPath is not rewritten again. Then in case we read something, we remove the default path because it's no more part of the preference but hard coded. We end up with a value in mySoundfontsPath .Then we try to read mySoundfontsPath from preferences, and use the previous value as a default if we cannot find it. So, when MuseScore is closed, and not changes has been done to preferences, we should save the correct mySoundfontsPath.

I guess I will need to install 2.0.2 and upgrade to 2.0.3 to reproduce the problem because I fail to see where the logic fails.

Ok. Do not expect MuseScore Portable 2.0.3 soon.
Without an upstream fix I'll have to write custom upgrade code. MuseScore Portable uses custom paths.

Do you think renaming "sfPath" to "mySoundfontsPath" in the ini is enough or should I try to find the new "hard coded part" and remove it?

Ah, yes, of course. Only so far I never did that, I'd rather have all the version available, next to one another, on the same thumb drive, for testing without the need to reinstall.
BTW: any chance to get the 1.2 portable App? It is is missing in my collection...
Are there older ones than 1.0? If so, These are also missing in my collection.

I'm seem to be able to replicate the failure steps...basically I manually edited MuseScore2.ini, removed any mySoundfontsPath, added sfPath=/tmp, and then start MuseScore appimage. Here's the interesting part: if don't go into Preferences from menu and shutdown, then I've lost both sfPath, as well as I don't see any mySoundfontsPath (even a default). If I instead were to start musescore and go into preferences, then I will see the /tmp in the soundfont path. However, if press cancel and exit MuseScore, then when I inspect MuseScore2.ini, then I don't see any sfPath or mySoundfontsPath. BUT, if I were to instead go into Preferences and press "Apply" and "OK", then when I exit MuseScore, then I do see that the /tmp has been properly migrated from sfPath and saved into mySoundfontsPath.

So it seems the update to preferences ini is not completed if don't go into preferences and do "Apply"/"OK".

OK. That was not clear for me.
Related question, is there a way for an application to know it's running as portable app? An environment variable or something?

MuseScore Portable doesn't set an extra environment variable.
It only sets "TEMP" to "TEMP\MuseScorePortable" for easier cleaning.
See MuseScorePortable.nsi for details.

Talking about environment variables:
Is there a list somewhere which variables MuseScore reads?
Once upon a time there was an ini setting "workingDirectory" but it is gone.
Are there environment variables instead?

MuseScore doesn't read any environment variable itself (AFAIK). However you can pass a number of command line flags https://musescore.org/en/node/38301

Not sure any of these helps but now I gather that to make Portable apps for MuseScore 2.0.3, you would need
* this bug fix
* A new MSI

To make PortableApp easier in the future, you would need
* The splash screen path reads from the (preference) ini file or a command line flag (any preference?)
* A proper solution for https://musescore.org/en/node/105066 (see this thread)

Is there anything else? Can you link to MuseScorePortable.nsi? Maybe we should put it under our git ?

To make a MuseScore Portable 2.0.3 I need either a bug fix and new binaries or an answer to https://musescore.org/en/node/104936#comment-472241 . I don't want to introduce new regressions in custom upgrade code.

A new setting or flag for the splash? hmm, your decision.
Easiest way to change a splash would be:
-Musescore.exe
-MusescoreSplash.png (or other file format)
The splash is not integrated in the executable, every packager could replace MusescoreSplash.png with his own.

MuseScorePortable.nsi is part of every MuseScore Portable package. You can find it at MuseScorePortable\Other\Source\.

Status (old) active patch (code needs review)

The fatal flaw of the update code is that the removal of "sfPath" from settings

s.remove("sfPath");

needs to occur when

s.setValue("mySoundfontsPath", mySoundfontsPath)

so that the update is performed almost in an atomic manner:

https://github.com/musescore/MuseScore/pull/2524

Unfortunately, this fix is too late for users with a custom sfPath who have already used 2.0.3 without applying preferences. But at least if accept now into 2.0.3 now, then any newly compiled 2.0.3 builds will get the fix...

MuseScore Portable 2.0.3 has been released with custom upgrade code.

The longer you wait with your fix, the more useless it is for other users.
(because it can't restore lost settings)

Maybe I'm missing something, but I don't see anything but a temporary glitch. That is, if there had been a customization to the soundfont path, it is lost on first run of MuseScore 2.0.3 if you don't happen to view Edit / Preferences, but then as soon as you notice it is lost, you can go back and set it back to what you wanted, and all is well. So it's a one-time minor annoyance - not the sort of thing I can see any reason to rush a patch out the door for. Again, maybe I'm missing something; if so, could someone explain the problem in more detail (not a a code level, from a user level).

Perhaps the portable app (since it can be moved and put in a non-standard location) relies on the custom soundfont path to have any sound at all? If that's the case, couldn't the portable installer just look for the INI file and do a regex replacement of "sfPath" with "mySoundfontsPath"?

Losing the settings path is maybe a minor annoyance.
Creating default paths due to missing setting without asking the user on every machine you run Musescore on is more annoying. And a show-stopper for portable apps.

I guess I'm not familiar enough with how portable apps work to understand the issue. Could you please explain exactly, from a user persepctive, what goes wrong, and in what situations it goes wrong?

Status (old) patch (code needs review) fixed

Fixed in branch 2.0.3, commit 7ae9bb6383

fix #104936 atomic update sfPath->mySoundfontsPath

If user opens 2.0.3 for first time, but never goes to Preferences and clicks OK/Apply, then previous 2.0.3 code unintentionally removed sfPath from .ini, but did not write update of newer mySoundfontsPath, effectively eatting that setting. This fix performs the removal of sfPath and write of mySoundfontsPath occur at consecutive lines, in an atomic manner, so that sfPath is only removed when mySoundfontsPath is written.

Fixed in branch 2.0.4, commit 6bfa2105ba

fix #104936 atomic update sfPath->mySoundfontsPath

If user opens 2.0.3 for first time, but never goes to Preferences and clicks OK/Apply, then previous 2.0.3 code unintentionally removed sfPath from .ini, but did not write update of newer mySoundfontsPath, effectively eatting that setting. This fix performs the removal of sfPath and write of mySoundfontsPath occur at consecutive lines, in an atomic manner, so that sfPath is only removed when mySoundfontsPath is written.