Score saved in a MuseScore nightly causes a newer nightly to quit unexpectedly

• Jul 11, 2014 - 08:24
Type
Functional
Severity
S4 - Minor
Status
by design
Project

I created a score in a MuseScore nightly from about a month ago. I have since discarded that nightly. When I attempt to open the file in a current nightly (or an older one I still happen to have), MuseScore instantly quits ("unexpectedly"). This is on Mac OSX; the error traceback provided by the Mac is attached as "CrashReport.txt". I am attaching the .mscz file. Can someone tell me what might be causing the failure, and whether there is something that can be done to clean the .mscz file so that it will open? (The .mscz file is also attached.)

Attachment Size
Cherubim.mscz 11.66 KB
CrashReport.txt 74.81 KB

Comments

Bad luck. You've been warned to not rely on a file created with one nightly to open in another.
Get that older nightly, open the file there, export as xml and open that in a newer nightly.

If you close the navigator before loading the score, it should load also in recent Nightly builds.
Attached a version saved with 25f25dd
For these requests the forum is better than the issue report.
And as Jojo said, you were warned about the possibility of files saved in the Nightly builds not being able to be opened by recent Nightlies :-)

Attachment Size
Cherubim2.mscz 12.05 KB

Thank you, I tried closing the navigator and indeed I can now load the original file (and save). So was the problem then that the screen window within the navigator was being interpreted as out of bounds?

And yes I am now forewarned. I guess I should save both .mscz and .xml versions of everything I do with a nightly.

But it seems the problem is not isolated -- I have another file that with a similar problem. Is the .mscz file format in a state of active change?

The problem was in reading the staff ID for some slurs when drawing the score inside the navigator.
The slurs were partially reimplemented in recent commits.
> Is the .mscz file format in a state of active change?
Yes, and it could still change, at least until the release of a beta version of MuseScore 2.0 (sometime this year).

Thank you, very informative.

The other thing I've noticed is that I seem to need to redo placement of crescendos/decrescendos when opening scores with successively newer nightlies. This was not an issue earlier in the spring. Is that something that is a current focus of development?

More generally, is there a changelog some place where I can get a summary of what is new in the various nightlies? I was actually hoping to start making some contributions to development (particularly in the area of lyrics), so more generally I need to first learn my way around the documentation (as a prelude to exploring the code iteself), which for now I find bewildering. And -- at this point this discussion is off of the original topic, no longer remotely connected to bugs, and so should be moved -- where to?

> The other thing I've noticed is that I seem to need to redo placement of crescendos/decrescendos when opening scores with successively newer nightlies. This was not an issue earlier in the spring. Is that something that is a current focus of development?

There has been recent work on spanners which might have changed something about their placement. If you manage to find a case in which the position varies when opening a file saved with the most recent Nightly builds fell free to submit a bug report so it can be investigated.

> More generally, is there a changelog some place where I can get a summary of what is new in the various nightlies?

Not really, but you can track the various commits added to the code on github: https://github.com/musescore/MuseScore/commits/master
Usually, each commits contains a message explaining which bug has been addressed or which (general) changes are taking place.

> I was actually hoping to start making some contributions to development [ ... ] and so should be moved -- where to?

You can look at the technology Preview forum for questions regarding the behavior of Nightly builds (http://musescore.org/en/forum/687). For development, you can have a look here: http://musescore.org/en/development especially the "Get help from other developers" section with the link the developer mailing list and the IRC channel. I would suggest you also read the developers' handbook http://musescore.org/en/developers-handbook if you want to have some (little) help to navigate inside the code and to compile it by yourself (very useful if you want to contribute). And welcome aboard!

All changes are recoded on GitHub, but justly in code. For discussions I thin the technology preview forum would be the most appropriate place

OK. Before leaving this thread I have another example of a file created with one nightly that will not open in a more recent one. In this case the file was created with the July 1, 6c89edb version (actually created in an earlier version but modified with 6c89edb), but will not open (crashes) with a nightly from July 11, c15c73c. In this case closing the navigator does not help. File and crash log attached. Can someone tell me what the more recent MuseScore doesn't like? (Also -- migrating from the July 1 to July 11 version via MusicXML doesn't work -- the MusicXML file crashes the July 11 MuseScore as well. Even if did work, just re-opening the xml file in the July 1 version indicates some changed formatting, so not a great solution. So I am at a loss for how to migrate this file to a newer nightly.)

Bit of an update- there must be some bad code generated in producing measure 17 of the attached file. If I attempt to select the treble-clef notes in just the first beat of that measure, Musescore crashes.

Attachment Size
10 Voskr'esni_Bozhe_G_w_mrefr.mscz 9.98 KB
crashrept.txt 60.69 KB

If that score was created with an older nightly build, this might just be another example of that being not supported. if you can reproduce this from scratch in a score created with the current build, please open a new issue with specific steps to reproduce. But this current issue report has already been closed.

The problem with this score was in a customized slur (i.e. some grip points not in default positions) in the bass staff at measure 12, corssing the line break. Apparently, the track data was missing.
Attached a version saved with 3f5789d
If you manage to reproduce the problem from scratch in a new Nightly build, please open a new issue report.
Ciao,
ABL

Attachment Size
10 Voskr'esni_Bozhe_G_w_mrefr2.mscz 10.21 KB

Thank you. Following on your analysis I tried just deleting the slurs that cross from measure 12 to 13 in my original score; the result still crashes the July 11 build. I am wondering how you managed to create a version that works.

I also notice that if I open the version you sent me with the July 1 build, none of the slurs are visible. I have been able to reproduce this phenomenon with a freshly created score (attached). It was created with the July 11 build, and has several slurs; but if I open it with the July 1 build, no slurs appear. So apparently there was some quite significant difference in the way slurs are handled that was introduced between July 1 and July 11?

Attachment Size
testslurs2.mscz 2.36 KB

Indeed, the same problem was also present in a slur on the bass staff in measure 21 (going to the next system to measure 22), sorry if I forgot to say it: probably in the version I attached it goes to the bottom of the page due to the customized position.
The file you attached can be opened without problems and shows the slurs in recent Nightly builds. There was actually a re-implementation of slurs between the 1st and the 10th of July, so it is expected that scores with slurs saved with recent Nightly builds cannot be properly opened by older Nightly builds.
I also tried to reproduce some sort of corruption similar to the one of the files you posted starting from scratch, but I didn't manage, so I think we can let this thread rest :-)