opening second MSCZ file causes "previous session quit unexpectedly"
I use MuseScore 3.6.2 portable on Win10. I configured my portable MuseScore to open MSCZ files on double click by "open with", navigating to my portable MuseScore and checking "always use this program" (or the like, my environment is German so the wording in English might be slightly different).
When I double-click an MSCZ file it opens correctly in MuseScore 3.6.2 portable.
As soon as I double-click another MSCZ file "The previous session quit unexpectedly. Restore session?" pops up. In case I click "No", two instances of MuseScore 3.6.2 portable are running, one showing the first and the other one showing the second file. In case I click "Yes" also two instances of MuseScore 3.6.2 portable are running, one showing the first file, the other one showing file1 and file2 in two different tabs.
It is confusing and unclear what has been restored and which files to keep.
Expected behaviour: The second file shall be opened in another tab within the already running MuseScore. No error message shall be displayed.
Comments
In order to assist, we would need you to attach the score that causes the problem.
But, also, I am not sure if the portable app is capable of being opened that way, without multiple instances. Maybe it is, but that could possibly be part of the "sandboxing" that allows the app to run portably.
In reply to In order to assist, we would… by Marc Sabatella
It doesn't matter which score is opened as first or second MSCZ file, it happens with any scores in the same way
In reply to It doesn't matter which… by SqueezeBoxer
It works correctly with MuseScore 2.3.2 portable. The only difference is that I have to use "send to" or "open with" as the double-click action is configured to start MuseScore 3 portable
In reply to It works correctly with… by SqueezeBoxer
MuseScore Portable <3 had the better launcher ;-).
I've reported the same long time ago and found a fix for it (see https://musescore.org/en/node/9036).
MuseScore Portable >3 is using another launcher.
In reply to MuseScore Portable <3 had… by Bart.S
In my case there's nothing special with the TMP directory as you reported in 2011.
But something about temporary session files might be an interesting hint for investigating further.
What's unusual with my environment: there's also a portable Musescore 2.32 in a different location on my computer. To simplify being aware of what's running I installed into a folder MuseScore3Portable (instead of the proposed MuseScorePortable) and renamed MuseScore3Portable\MuseScorePortable.exe to MuseScore3Portable\MuseScore3Portable.exe after installing from the paf.exe. To get it running I also had to rename MuseScore3Portable\App\AppInfo\Launcher\MuseScorePortable.ini to MuseScore3Portable.ini
To make sure that the issue is not caused by my environment I installed a portable Musescore 3.6.2 once again on my wife's notebook where no version of Musescore has ever been used before. And I did not change any file or folder name. The behaviour is exactly identical. So there must be something wrong with Musescore portable or its launcher.
In reply to In my case there's noting… by SqueezeBoxer
That's what Bart.S said. The 3.x PortableApps use a different launcher than the 2.x ones. And it is about that TEMP folder, which does hold the session file. On start MuseScore creates a session file, on exit it removes it. If MuseScore on start finds a session file, it takes this to mean that the previous session crashed.
In reply to That's what Bart.S said. The… by Jojo-Schmitz
That criterion is wrong. An existing session file alone doesn't mean MuseScore crashed. If the session file exists and a MuseScore process is running everything is fine and the existing process should be used. Only if a session file exists and no MuseScore process is running signals that the previous session crashed.
And why is the behaviour different for the portable version and the installed version?
Bart was talking in his 2011 thread about TMP, the standard windows temp directory. He had moved it and had a problem with write access. In my case the session file and some more temporary files are created in PortApps\MuseScore3Portable\Data\settings\ and PortApps\MuseScore3Portable\Data\Temp\
That's within the subdirectories of the portable storage, missing access rights should not be the cause for anything.
In reply to That criterion is wrong. An… by SqueezeBoxer
If the session file exists and a MuseScore process is running that exactly is the problem: how to detect whether another MuseScore is running, esp. in case of a PortableApp
It is possible to run multiple instances of PortableApps, at least for MuseScore 3.x (3.5 and later actually, 3.0 to 3.4 had no PortableApps)
It is, as far as I understand @Bart.S, an issue with the launcher used for 3.x
In reply to If the session file exists… by Jojo-Schmitz
Maybe. But it did work correctly with MuseScore 2.x portable
In reply to Maybe. Baut it did work… by SqueezeBoxer
Maybe. But things changed. And apparently out of our control.
I do like the idea of being able to have multiple PortableApps running at the same time, esp. if these are different versions (e.g. 3.6.1 and 3.5.2). That was not possible in 2.x
In reply to Maybe. Baut it did work… by SqueezeBoxer
Maybe I forgot to mention that I encountered this error message while developing the MuseScore Portable <3 launcher. MuseScore Portable <3 used all binaries from the MuseScore installer (non portable).
My guess is that's a regression due to launcher misconfiguration or new binaries. Can't tell for sure, MuseScore team is creating MuseScore Portable >3 themselves. Things changed ;-)
In reply to Maybe I forgot to mention… by Bart.S
It would be OK if double-clicking the second MSCZ file opened it in a second instance of Musescore. That's how e.g. LibreOffice Calc behaves when I double-click two xlsx files. Just avoid the error message and avoid the situation that the same MSCZ file is opened twice.
Can I help clarifying something? If yes, what should I investigate?
It might help to add this bug / regression to the issue tracker. I'm not sure if developers are reading this thread.
In reply to It might help to add this… by Bart.S
They sure are, sill an entry in the issue tracker is better, once a bug got confirmed
This is true for me as well. Opening a score started a new session. I switched to the normal version a couple of weeks ago, mainly for this reason.