Could not install Musescore drumline

• Jun 30, 2018 - 12:26

Hello,
I try to install Musescore drumline, but, after the downlobd, I have this error message:
"Unable to save the extension file on disk"
Musescrore 2.3 was installed on LinuxMint 18.3 with AppImage 64-bit
Thank you in advance for your help…

Comments

• Jun 30, 2018 - 23:22

I also encountered this problem with sufficient storage capacity environment.
The cause was otherthing.

This problem is caused by the default folder name including ":(colon)" letter, for extension packs folder.
Due to Windows NTFS limitation, all of Windows application program can not creat the folder(directory) containing ":(colon)" letter.
So, installing of MuseScore extension pack is fail.

When the language setting to "English(US)", the extension packs folder name is "Extensions"．
But, when the language setting to "日本語", the extension packs folder name is "拡張機能:"．
Please note that the ":(colon)" letter is at the end.
This may be someone's mistranslation or someone's mistransport from transifex string.

Tentatively,
This problem was solved by removing the colon from the folder name for extension packs folder.

For Japanese users, I wrote article that how to workaround it.
http://knoike.seesaa.net/article/460277309.html

Reply

• Jul 1, 2018 - 00:32

@Jojo-Schmitz

https://www.transifex.com/musescore/musescore/translate/#ja/musescore/1…

Location:
../../mscore/preferences.cpp:195
Context:
extensions_directory

I fixed this ts string, so it will be reflected in the default folder name.

[Help] -> [Resource Manager],
[Language] Tab,
[Japanese] Updated.

In Japanese language setting,
I was able to confirm that it was fixed this problem about default folder name.
By resource updated,
The default folder name for extension packs no longer contains a colon in Japanese Language setting.

Reply

• Jul 1, 2018 - 17:37

I think the Japanese found the problem with the solution here. It boiled down to a translation problem where the : was included in the translation of one of the strings and it should not have been included. The translation was fixed and the Japanese no longer have this problem when the translation is updated. If this problem exists in the English language version then there is a bug, otherwise check to see if there is an extra : at the end of the message that tells you there is an error. If this is the case, the translation is the problem.

Reply

• Jul 2, 2018 - 09:21

In the French translations quite a few texts ending with a ":" got translated to end with " :", SPACE COLON, i.e. between the last word and the finale colon a space got added. Is this a French language speciality? In general translations should not add or remove any white space characters. Whether or not this may influence the problem with saving extensions is unclear to me though

Reply

• Jul 2, 2018 - 20:36

The item related to this problem is 4423 on transifex, not 2383.
Item 4423 for fr(french) is "Extensions" not containing ":(colon)", so it is no problems.
Also, It is possible to create folders containing ":(colons)" and " (space)" on almost of the linux file system.

So, I think that the cause of elodreivax's problem is not a mistranslation.

It may be AppImage specific problem.

Reply

• Jul 2, 2018 - 22:10

That the message comes out may be that MuseScore AppImage is trying to write in the protected area.
I think that the cause of elodreivax's problem is not a mistranslation.
It may be AppImage specific problem.

Please tell us following informations.

1/
Full pathname to MuseScore AppImage.
(ex. /home/knoike/MuseScore/MuseScore-2.3.0-x86_64.AppImage )

2/
How do you launch MuseScore AppImage?
Double-click the icon? From command line? or other way?

3/
Full pathname for your home directory.
(ex. /home/knoike/ )

Reply

• Jul 3, 2018 - 00:44

I could reproduced this problem on LinuxMint 19 cinnamon in VirtualBox.
MuseScore succeeded in downloading the extension, but it failed at the time of deployment.

In the terminal:

$ ./MuseScore-2.3.0-x86_64.AppImage -d
-> fail.
(The Message "can't access" is displayed.)

$ sudo ./MuseScore-2.3.0-x86_64.AppImage -d
-> Success.

At this time,
I noticed that a file /tmpmdl.muxt is temporarily created.
This is the ROOT directory where general users can not write.

Is there a way to specify the temporary file creation location for extension installation?
Does anyone know?

Reply

• Jul 3, 2018 - 08:37

I guess it should create /tmp/mdl.muxt instead, a missing "/". Pretty bad...
Does maybe export TMPDIR=/tmp/ prior to starting musescore help?

Culprite line in code seems to be in mscore/resourcemanager.cpp:
QString localPath = QDir::tempPath() + data.split('/')[1];
it may need to be
QString localPath = QDir::tempPath() + "/" + data.split('/')[1];

From the documentation:
On Unix/Linux systems this is the path in the TMPDIR environment variable or /tmp if TMPDIR is not defined. On Windows this is usually the path in the TEMP or TMP environment variable. The path returned by this method doesn't end with a directory separator unless it is the root directory (of a drive).

So indeed setting TMPDIR to /tmp/ might help (or maybe not, if QDir::temPath() strips that again)

Edit: no, the TMPDIR workaround does not help. And it is not just AppImage, but the fiull Depiab package too, presumably all Linux version and possible also on Mac

Reply

• Jul 3, 2018 - 15:15

@Jojo-Schmitz

Thanks.
I tried a method to specify temporary directory by set environment variables.

$ export TMPDIR=/tmp/
$ echo $TMPDIR
/tmp/
$ ./MuseScore-2.3.0-x86_64.AppImage -d

-> failed at the time of deployment.

I also tried the following settings.
But they all failed as well.

$ export TMPDIR= (not defined status. this is the default at LinuxMint 19.)
$ export TMPDIR=/tmp
$ export TMP=/tmp/
$ export TMP=/tmp
$ export TEMP=/tmp/
$ export TEMP=/tmp

Reply

• Jul 2, 2018 - 02:01

I don't know if you got it to work or not, but I had the same trouble, and found that my antivirus was blocking MuseScore from accessing the folder that it needed to in order to install. Once I told my AV to allow access, it worked.

Reply

• Jul 2, 2018 - 23:30

I am using Windwos 10 and I have installed Musescrore 2.3 and everything is fine. When I install the Musescore drumline and try to start Musescore 2.3, I can not start it. I only see the start screen locked and the use of computer memory increases to very high values. Then I must use the task manager to kill the task...

It could be interesting two versions of Musescore. A full version with the included extension packages and a lite version without extension packages.

Reply

• Jul 3, 2018 - 01:05

I think that it is better to load it on demand instead of at startup.
If MuseScore does not adopt this mechanism, it will be a problem "take a quite long time at startup" when the number of extension pack increase.

The current mechanism of loading everything at startup is not good.

Reply

• Jul 3, 2018 - 08:19

Once started, you can prevent MuseScore to load the sfzs at startup by removing them from Display > Synthesizer > Zerberus, and press "set as default". Obviously, if you do so, you will have no sound when you use the MDL templates and instruments unless you load the sfzs again, which will take "quite a long time".

Reply

• Jul 3, 2018 - 13:43

@lasconic

"quite a long time" is an advice to @lucanor81.
In my environment, it startup in about 30 seconds.
Thank you for worry.

The solution lasconic propose is also a solution.
As an another solution, there is "Install/Uninstall MDL extension if necessary".
I think that this is better under the present implementation.

Although there are workarounds,
I think that a mechanism of on-demand loading is necessary.
Perhaps, it is essential mechanism.

Reply

• Jul 3, 2018 - 14:01

IIRC it took a minute for me, some 2 weeks ago, absolutely unacceptable, I'm starting musescore way to often to be willing to cope with this delay. Esp. as I have no need at all for MDL, so installed it just for curiosity

Edit: tested again: 75 seconds! And this is not exactly an old or week machine, i7 @ 2.8GHz, 4 cores + HT, 8GB Ram, 256GB SSD (it builds musescore master from scratch in 10 minutes).
Startup time without MDL is less than 7 seconds!

Reply

• Jul 4, 2018 - 08:53

This opens up an interesting point of discussion in further development of extensions. Maybe we should have a pre-defined limit to the max size of total extensions that a user can install?

As the extensions will likely vary in size, it could be theoretically possible to have multiple small ones installed, but not necessarily so for larger ones.

How I imagine this is if there was a maximum size threshold determined and a user decided to install an additional extension that would push the limit past this size, they would receive a warning that this extension exceeds the size limit and to uninstall one or more extensions to continue.

Reply

• Jul 4, 2018 - 09:13

In fact, this is not the right solution. It would be a workaround. The proper solution would be to no load the sfzs in memory entirely but load them only on demand during playback. If you score only feature on crash cymbal hit, you don't need to load this hit entirely at at startup, you can load just the few bytes of it and load it entirely while you are playing these bytes... It's the basis of the PR here https://github.com/musescore/MuseScore/pull/2782 but it's not yet ready for prime time.
Loading only the first bytes is fast and require less memory so no need for any limit.

Reply

• Jul 4, 2018 - 09:16

I think that the problem is timing to load, not size.

EDIT:
Yes, I almost agree @lasconic.
(He was earlier than I write.)

EDIT2:
> during playback
or "before playback if that score needs load no-default soundfonts"

I think that it is better to dynamically load extension pack themselves, not only just soundfonts.
When loading the score, load the extension required by that score.
(For that, need to change the current implementation greatly.)

Reply

Do you still have an unanswered question? Please log in first to post your question.