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.
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.
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?
I don't change the splash screen. It's deactivated. And I use another one.
Other apps are easier to handle.
Btw, there is a separate issue for the splash: https://musescore.org/en/node/8637
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\.
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...
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?
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.
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.
Comments
Seems a result of ff749fd29, to fix #99236: AppImage factory reset and initial execution initializes Soundfont path with temp dir that will be invalid in future executions
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.
No need to install 2.0.2. Just feed MuseScore 2.0.3 with an old ini. ;-)
Btw, do not expect a fix in the close future. Any fix will come in MuseScore 2.0.4 and that could be months away.
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?
Would the portable app ever read an ini from another version?
Sure, if you do an upgrade (install to same location as old version).
See http://portableapps.com/support/portable_app#upgrading for more information.
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.
Sourceforge is your friend:
https://sourceforge.net/projects/portableapps/files/MuseScore%20Portabl…
Older ones aren't official and the server which hosted the development tests isn't available anymore. I have them in my collection of course. ;-)
thanks
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".
Well I'm thinking should have been a
s.setValue("mySoundfontsPath", mySoundfontsPath);after the update code, at this line: https://github.com/musescore/MuseScore/blob/2.0.3/mscore/preferences.cp…
so that gets the MuseScore2.ini mySoundfontsPath gets written with updated value, even if user doesn't go into preferences.
Would a patch on top of 2.0.3 be enough for you Bart.S ?
Well, I don't compile MuseScore myself.
I just use/repackage the binaries of the Windows installer.
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?
Also how do you change the splashscreen if you repackage the binary as it ?
I don't change the splash screen. It's deactivated. And I use another one.
Other apps are easier to handle.
Btw, there is a separate issue for the splash: https://musescore.org/en/node/8637
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\.
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)
I guess 3.0 would never read 2.0 settings. But we may want to fix it for 2.0.4
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"?
Marc is correct...this is nothing more than a temporary glitch...worst case someone has to re-add their custom soundfont path.
Although it is not a big deal, I say the fix should be put in the next release.
@shoogle, the portable app as well as any other build always looks in "$mscoreGlobalShare/sound" path in addition to the custom mySoundfontsPath . So even with a bad or nonexistent mySoundfontsPath, user will still get the default soundfont.
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?
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.3, commit 4be5f35a58
Merge pull request #2524 from ericfont/104936-atomic-sfPath-update
fix #104936 atomic update sfPath->mySoundfontsPath
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.
Automatically closed -- issue fixed for 2 weeks with no activity.