File is corrupt after changing note length

[petetaxi-test]

Issue type

File corruption

Bug description

After changing the length of a particular note, the file is indicated as corrupt.

Steps to reproduce

1. Unzip and open the attached score.
2. In the Flute II-IV part of the full score, select the bottom note at the start of bar 35
3. Press the half note button to change its length
4. Save the file

Expected:
The file can be saved, and is not corrupt

Observed:
A message indicates the file is corrupt

Ocarina Bug Report.zip

Screenshots/Screen recordings

MuseScore Version

OS: Windows 10 Version 2009 or later, Arch.: x86_64, MuseScore version (64-bit): 4.2.1-240230937, revision: github-musescore-musescore-d757433

Regression

I don't know

Operating system

Windows 11 Pro 21H2

Additional context

No response

[cbjeukendrup]

I investigated this a bit. The problem is in the "Flute II-IV" part score. A quarter rest does get added to the measure, but in voice 2. That is because in the full score, the edited notes are also in voice 2, but in that part score they are somehow in voice 1. That's weird: as far as I know, this "discrepancy" can only be created by making voices invisible in the part score using the Instruments panel, but in this score all voices appear as visible on all staves. I think that is the reason that the voice mapping between full score and part score is broken and thus the rest is placed in the wrong voice.

It would be very useful if someone could find steps to reproduce this from scratch.

Apart from that, a remark: in this score, staves are linked in two different ways. Some staves are linked as "linked staves"; others are linked between the full score and the part score. This should be supported functionality, but MuseScore doesn't seem to handle this very well internally.

If someone wants to research this further: relevant code is in src/engraving/dom/edit.cpp:6370 (set a breakpoint there to see from where it is called). My feeling is that the TracksMapping from staff->score()->excerpt()->tracksMapping() contains bad values, but I'm not sure yet how exactly and if that is the (only) problem.