AppImage factory reset and initial execution initializes Soundfont path with temp dir that will be invalid in future executions

• Feb 22, 2016 - 09:08
Type
Functional
Severity
S4 - Minor
Status
closed
Project
MuseScore

Reproduction steps:

  1. download nighly AppImage from https://bintray.com/musescore
  2. reset preferences.ini by executing AppImage using any of the following manners:
  • on a system that has never executed a development musescore version, OR
  • execute with factory reset, OR
  • rm -f pathtoMuseScoreDevelopment.ini, OR
  • on a machine that may have dev preferences set already, but goto Preferences->"Reset to Default Settings"
  • observe that the Preferences Soundfont directory contains "/tmp/.mount______/share/mscore-portable-nightly-2.1/sound" where ____ is a random string, and quit MuseScore
  • restart the MuseScore AppImage normally (i.e. without -F), and observe that the Soundfont directory is that /tmp directory from the prior factory reset.

    • Undesired Result: if user is on a fresh system or otherwise doesn't have any soundfonts in ~/Documents/MuseScoreDevelopment/Soundfonts, then user will not have any soundfonts available, so playback will be silent.

    Expected Behavior: User has default soundfont that was included with AppImage always avialable.

    Comments

    • Feb 22, 2016 - 09:20

    See me comments in https://github.com/Musescore/musescore/pull/2398 when I discovered this issue. I notice the problem is that the line that performs initialization of soundfont directory uses mscoreGlobalShare, which is going to be different upon every execution

    Note: none of the other folders in Preferences dialog window show the part containing mscoreGlobalShare.

    I think the solution is to have the Soundfont folderlist be consistent with the other Preferences folders (e.g. Templates & Styles), so that Preferences::sfPath won't contain any mscoreGlobalShare path in the actual stored string. However, whenever sfPath is read, will need to add the default mscoreGlobalShare folder.

    Reply

    • Feb 22, 2016 - 11:53

    Solution could be to make the SoundFont path relative to the default location, and only check outside $GlobalShare/sounds if an absolute path is given.

    Reply

    • Feb 22, 2016 - 12:08

    well the way I've fixed it now is to not even include mscoreGlobalShare/sounds inside the soundfont path string that gets stored. So now soundfont path is like template or style path. So it is just going to always be assumed that mscoreGlobalShare/sounds is always one of the search folders, and there will be no way for user to remove (or modify) mscoreGlobalShare/sounds from the soundfont path. I think that covers what you are saying "make the SoundFont path relative to the default location, and only check outside $GlobalShare/sounds if an absolute path is given".

    Reply

    • Feb 26, 2016 - 08:03
    Status (old) patch (code needs review) ⇒ fixed

    Fixed in branch master, commit ff749fd292

    fix #99236 remove mscoreGlobalShare/sound from soundfont path

    Preferences::sfPath is renamed "mySoundfontsPath", which adheres to same naming scheme for myPluginsPath and myTemplatesPath, and now only stores the user-specified soundfont folders (no longer stores mscoreGlobalShare/sound). Any synthesizers loading soundfonts must make sure to look in mscoreGLobalShare/sound in addition to mySoundfontsPath. Removing mscoreGlobalShare/sound from the stored path fixes a bug with portable AppImages, which use a different temporary directory for mscoreGlobalShare on every execution.

    Reply

    • Feb 26, 2016 - 11:10

    Fixed in branch 2.0.3, commit cd49abf02a

    fix #99236 remove mscoreGlobalShare/sound from soundfont path

    Preferences::sfPath is renamed "mySoundfontsPath", which adheres to same naming scheme for myPluginsPath and myTemplatesPath, and now only stores the user-specified soundfont folders (no longer stores mscoreGlobalShare/sound). Any synthesizers loading soundfonts must make sure to look in mscoreGLobalShare/sound in addition to mySoundfontsPath. Removing mscoreGlobalShare/sound from the stored path fixes a bug with portable AppImages, which use a different temporary directory for mscoreGlobalShare on every execution.

    Reply

    • Feb 27, 2016 - 07:56

    I'm verifying the I get proper update behavior for sfPath->mySoundfontsPath when I run the i686 linux AppImage 2.0.3 nightly for 20160226 4e025g6 (which includes this commit) starting with sfPath filled.

    Reply