Crash On Applying Time Signature change from Part View
Reported version
3.5
Type
Functional
Frequency
Once
Severity
S2 - Critical
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
No
Project
Create a new score using the Jazz Big Band Template.
Create all parts.
Go to Part View for a given part.
Drag the Cut Time signature onto the first measure
Observe
Fix version
3.6.0
Comments
Regression vs. what version?
Confirmed, with MuseScore 3.5.2 not with latest 3.x development build though.
Which is strange, as the difference isn't big, see https://github.com/musescore/MuseScore/compare/3.5.2...3.x and there's nothing explicitly fixing this particular issue
In reply to Regression vs. what version?… by Jojo-Schmitz
I tested on 3.5.1, 3.5.0, and 3.4.2. 3.4.2 is the first version where I could not reproduce the issue.
Thanks. Could you also try the latest nightly 3.x build (from https://musescore.org/en/download#Development-builds ?
In reply to Thanks. Could you also try… by Jojo-Schmitz
The specific flow described in the initial ticket is not reproducible in the latest dev build, MuseScoreNightly-202010200415-3.x-6b901e7-x86_64.msi.
However, I am having an issue with this score that seems related - this is how I came across the issue in the first place. Notes and score info has been stripped to keep the score simple.
In the attached score, somehow, the time signatures got out of sync between score and parts. Usually when this happens, I go to the Part, highlight the time signature, and delete it. In the past, this has reset the time sig to whatever the score has. Here, going to the C part and deleting the cut time sig on the first bar just causes MuseScore to crash, even on the nightly.
How the score got to this point, IDK, but it did.
https://www.youtube.com/watch?v=r2UfBuu-ywc&feature=youtu.be
Perhaps this is related to #311695: Edits to system text/tempo marking after save and reload of score do not propagate to all parts. which is included in the latest nightly and fixes some problems between main score and parts.
That fix is part of 3.5.2 already. But if that score had been edited with 3.5.1, such a corruption might have crept in.
Whatever it is with the original issue, it seems fixed even if it is unknown why.
Automatically closed -- issue fixed for 2 weeks with no activity.