MuseScore 3.1.0 Ubuntu random "vanishes" with Undo
Grr...another problem for my favorite music notation software. I first experienced it with MuseScore 3.1.0 Beta. (Used 2.3.2 and 3.0.5 for quite some time without experiencing this issue.) At first, I figured it was simply a "beta issue", and noticed today that the release version was out. Unfortunately, after downloading and "installing" MuseScore 3.1.0 e26f7c4, I am sorry to report that the issue is still there. (For what it's worth, it seems to me that the release version is "quicker" than the beta version.)
Basically, I'm doing a lot of music inputting, inputting lots of notes...and a few mistakes. A quick Ctrl+Z (or going back to re-enter the note/duration) works MOST of the time. However, after a minute or so of inputting music (interspersed with a dozen or so corrections), one more correction and suddenly MuseScore vanishes. No crash dialog, no warning, nothing. It just completely vanishes--and any work that wasn't saved (auto or Ctrl+S) is lost. When I restart MuseScore, it comes up with a dialog, "The previous session quit unexpectedly..." Restores me right back to where I was, less the work since the last save.
Is there anything I can do to help track down this bug? (I have Autosave set to every 2 minutes.) If I spend the day inputting music, I'll have MuseScore 3.1.0 vanish on me at least six times, if not more. I haven't found an exact step-by-step means of reproducing the bug, though it does seem to have something to do with the time duration since the last save, and the number of "corrections" I've done since then. I've been through several new scores, so it's not an issue with any particular MSCZ file.
TBH it's kind of like the bomb attached to THAT key on the piano in old cartoons. Poke, poke, poke, poke, POOF! Funny on TV...not so funny in the workroom.
OS: Ubuntu 18.04.2 LTS, Arch.: x86_64, MuseScore version (64-bit): 3.1.0., revision: e26f7c4
Comments
The operating system probably doesn't matter, though in this case it may (because it could be a memory management issue). To help track down the bug it would probably require you to start working on a score and keep track of everything you have done leading up to the crash. You, or someone else can then duplicate what you did to see if it crashes for them also. Unfortunately this is not a realistic expectation from what you are describing.
To back up a step, you said you discovered this during beta testing. The reason you beta test is to report problems like this so they don't end up in the final release, though I suspect this bug would have still made it into the final release.
Perhaps you could give us a better idea of what led to the crash. For example, do you always have only one score you are working on in the sessions that crash or do you always see it when you start working on a second or third score? Does auto save always have to kick in? Does it always crash after the nth auto save? Basically, finding any common pattern would give people a target to look for.
This is exactly the kind of bugs for which having a mode in which MuseScore would save all keyboard and mouse inputs in a log file would potentially help to reproduce/understand.
Perhaps there is a linux utility that you could install that would just do that? I mean logging all keyboard and mouse inputs while MuseScore is running ?
There is a utility in a debug mode that would allow for remembering keystrokes. Someone who knows more about it would need to explain how to access it and use it. I forgot abut it until just now.
I guess you mean the Script Recorder, only available in DEBUG (self) builds, so not in any release (nor any development builds IIRC)
Perhaps a @FullSound would be willing to use a self build if someone were to send him a link to a self build from version 3.1 so he can try to make it crash. As long as it's a self build of 3.1, @FullSound would be able to use it like an official release with no fear of losing more data than he is already.
As a programmer myself, I understand how frustrating bugs like this can be! The reason I didn't report it with the beta version, is because I previously created a bug report...only to find that I was several revisions behind, and the problems had been fixed. I also suspected that perhaps it may have had something to do with "beta" features/logging/error reporting, etc. But when it was still in the release version, I realized that it wasn't a "beta bug." FWIW, this problem is new to 3.1.0 Beta; I didn't experience it before then.
Sure, I'd be willing to use a self-build for logging. Anyone using the log would have to laugh at my mistakes ;-). I may be using Linux, but I'm not well versed in the architecture yet (having defected from Windoze two years ago), so compiling MuseScore myself is rather beyond my league.
"For example, do you always have only one score you are working on in the sessions that crash or do you always see it when you start working on a second or third score?" I'm always working on just one score, though I often have two or three others open in the background.
"Does auto save always have to kick in?" Don't know. I could try turning it off--sometimes it's better to rip the Band-Aid off rather than slowly peel it off over two years.
"Does it always crash after the nth auto save?" No clue--there's no flashing light saying, "MuseScore autosaving now", so I don't know if there's a direct connection (i.e. making a change/undo at the exact moment it's trying to autosave).
"Basically, finding any common pattern would give people a target to look for." Yes, I fully agree.
I'll try working with just one score open, disabling Autosave, and just manually saving it. It can sometimes take 15 minutes before it "vanishes" (usually I lose just about 8-20 measures of work)--but this is no one-time-occurence. Will see what that does.
MuseScore just "vanished" on me when I went back to re-enter a note. Autosave was disabled (lost the whole French Horn part...but at least I was only 20 measures down). Guess we can rule that one out...
It seems to have something to do with overwriting an existing note with a new one. Maybe there's some glitch with a particular combination of note durations. I'll try to keep my eyes open--that's difficult, as there's zero warning.
I understand. If ever you think you found a bug and want to discuss it, please use https://musescore.org/en/forum/6 which is the Support and Bug reports forum. I use windows so I can't lead you to a Linux build, hopefully someone will see this and post a link to a 3.1 Linux build.
I can relate to these type of bugs. MuseScore crashes when your not expecting it and you forget the last 5 things you did that might repeat the crash. I suggest you turn autosave back on so you don't loose too much work. If you have several tabs open but don't switch back and forth between them, then I would consider that one score, but the fact that several are open has a slim chance of being a factor in the crash. I wouldn't test that until you can reproduce the crash in your current environment.
Also, if the score isn't some big secret, then post it here and give us an idea of what you were doing the last time it crashed. Knowing what is already in the score could give us a clue to the source of the crash. There are some people around here who can find causes of crashes like it's magic to me.
Starting musescore from the command line may reveal some debug output. Running it with the -d option even more so.
Tried running MuseScore from the command prompt with -d. Perhaps coincidentally, it never crashed. I did get the following output:
$ /usr/local/bin/MuseScore-3.1.0-x86_64.AppImage -d
Jack appears to be installed on this system, so we'll use it.
QApplication: invalid style override passed, ignoring it.
[...nothing from here onwards while I entered music...]
QLayout: Attempting to add QLayout "" to Ms::Mixer "Mixer", which already has a layout [...I opened the Mixer dialog to change the violin patches from "Slow Violin Expr" to "Violin Expr" so I could actually hear the fast notes]
libpng warning: iCCP: known incorrect sRGB profile
I'll try running it from the console when I start another project. BTW with the "vanish" last night, I only had one score open. Generally speaking, I'm not switching back-and-forth between scores when inputting notes--I just have them open so I don't forget about them.
Maybe I'll have to install a screen capture program (to be able to determine what causes the "vanish"), and see if it's reproducible. Might take a little bit of time on that one, though.
No big secrets with my scores--I'm typesetting some James Reese Europe ragtime selections that I found on the Library of Congress website. Turns out that these are the exact scores that the Paragon Ragtime Orchestra plays from. However, as it doesn't seem to be an issue with any one score (more like all of 'em), I don't see how posting the score would help.
EDIT: most of my work today was copy-and-paste from existing parts that I'd entered, with not very much actual note entry--and even less re-entering in notes.
And probably fewer undos which I think you said was the probable culprit.
#303762: [EPIC] Collection of Undo issues
@FullSound Did you run into any further crashes like this using 3.2 and upwards?
In reply to @FullSound Did you run into… by Philzen
@Philzen: I really can't say...because I haven't been arranging music lately (esp. with the latest world events, music is not considered an "essential service"). I'm actually still on MuseScore 3.1.0...will need to upgrade it.