Delete time signature corrupts key signature

Notice: the attached file in first message testkeysigtimesig.mscz
is detected as corrupted.

Yes, the score posted is already corrupt. But I used it as a model to create a new one. I have attached my version below.

I think problems actually start the moment you delete the first time signature change:

1) load attached score
2) click the 4/4 in bar 4
3) delete

Result: the key map is already wrong, as you can see by the accidentals that appear on the B's in the last measures.

But actually, it's worse that that - I think something is amiss the moment you add the time signature change. Try this:

1) new score, treble clef template, key of C, 2/4 time signature
2) drag 4/4 to measure 4
3) add notes to measure 4

Result: it's still 2/4

This happens only if the the 2/4 is added in the wizard, not if the score starts 4/4 then you change the initial time signature to 2/4. So it might not be related - the attached score was initially created as 4/4.

I started investigating this issue and I focus on this point (comment #2):

"I think problems actually start the moment you delete the first time signature change:

1) load attached score
2) click the 4/4 in bar 4
3) delete

Result: the key map is already wrong, as you can see by the accidentals that appear on the B's in the last measures."

The problem is that the behavior changes over time...:(
What I can say for now: there is a significant change on February 17. With this
Nightly, ec8913a
I get a failure (with the appearance of accidentals B and E in the last measures) immediately after the deletion of 4/4 time sig:

After seeing, there is some reasons to think that this Nigthly-commit previously mentionned is possibly involved. To fix this issue: #45601: changing note value can lead to missing accidentals

With the previous Nigthly: 11b49de, the removal of the timesig works as expected:

After Undo also, it's ok:

BUT, after Redo, or after entering notes (from the second quarter note, the first works...), the accidentals B and E appears again:

On Beta2, it fails on the second step (undo the removal time sig)

A reason for hope: I see that on a Nightly around the Beta1, everything works, undo and redo. I'll try to find where it broke.

After verification, and after testing various x Nightlies between Beta 1 and Beta2, I do not see any other major change that on December 22 precisely (day of the release of the Beta2)

With this Nightly: 4a3c98a
I receive a correct result, at all steps: delete,
undo,

redo

(and entering notes)

With the Nightly: 5c9b9da,
the first step (deletion) is ok:

But the second step (undo) fails. And so the following, redo ...

It happened just one hour between these Nigthlies (3:06 p.m. and 4:06 p.m.) So: even I am not very sure, the cause might here? https://github.com/musescore/MuseScore/commit/df7ff007e8ff8536d6ea258b8…
To fix: #39901: Undo of concert pitch produces incorrect transposition

Thanks to check whether I have not forgotten anything.

Other stage of the "rocket", the fix of this issue #42131: Infinite loop on score internal element adding is also involved in January 8: https://github.com/musescore/MuseScore/commit/328503f0a8cdc0fed212dfa3f…
Again, the behavior change. In comparison with the Beta2 (failure at the second step: undo), the failure occurs nows at the third step (redo), but it works again with a new undo, and fails on new redo, and so on...

Thanks as always for the investigation!

The change you mention on December 22 may have exposed the issue - by making the accidentals visible - but I suspect there may have a problem before that as well that might not have been visible until you tried entering notes into that measure?

Anyhow, my understanding is that Werner is working on a fix.

It is possible to have forgotten something, but after rechecking on Nightlies in last August, September, October, November and some others in December, I do not see, after time sig deletion, and undo, a change at the third alternative step (with redo), ie entering notes in 4/4 time sig.
All semble fine for me until the 22 december, and then, other mentionned commits have added their two cents. It is my understanding of this issue in this moment.

Fixed in 787373aa97

Automatically closed -- issue fixed for 2 weeks with no activity.