Embedded pictures when creating part cause crash
I'm using musescore 1.1 (stable) on win XP SP3.
When creating a single voice (Einzelstimme) from a score with an embedde picture the single voice contains the V-Box for the picture. But it shows empty.
When I immediatedly try to save this single voice I get
-an empty file
-an error message that the picture can not be found
- a crash of musescore 1.1 the next action
When I remove the empty V-Box a subsequent action in the single voice crashes Musescore.
When I remove the V-Box and the picture in the original score beforehand creating of the single voice is without problems.
| Attachment | Size |
|---|---|
| Concerto_Es_MWV641.mscz | 86.53 KB |
Comments
Do you know about the trunk?
No, I don't know. I use the official binary of MuseScore 1.1 for windows.
Until it's confirmed, I will mark this non-exclusive (make sure it's not closed when 1.2 is released) :).
Observations (I tried this with branch 1.2 and 1.1):
The enclosed score contains two VBoxes, the first one contains the title, composer, etc., and the image. The second VBox is empty.
I deleted the empty second VBox and deleted the picture from the first box.
I saved the score as MSCX, closed the document, opened the MSCX file.
Using Winzip I extracted the image from the original MSCZ file and inserted it again by dragging it onto the VBox.
I saved and closed the MSCX file. In "vi" I opened the MSCX file and saw that the image was recorded with its full path.
I opened the MSCX file again, picture showed up as expected.
I defined a part for Bb clarinet and harpsichord. I created the part.
The part created without problem and also showed the VBox and the picture.
I saved it as MSCZ. I opened the part, it opened OK and showed the picture.
I repeated creating the part, this time I saved as MSCX.
I opened the part, it opened OK and showed the picture.
Note:
1.1 creates the part without the "dirty" flag being set. So you can close it without saving. Saving it works just fine.
Conclusion:
When creating parts from a file that contains an embedded picture, it's best to start with an MSCX (uncompressed) format. The parts can then be saved as MSCX or MSCZ. I enclose the part I extracted.
===
The above is clearly a work around. When starting from the original MSCZ, I experienced all the problems mentioned in the original report, that is, the "file not found" message and later a spontaneous crash.
Here is a patch for the problem that in 1.2 when saving a part with "Save as", the dirty flag doesn't get cleared.
Forgot to change the status.
Because someone sat down and looked into the problem I'm going to add a hint:
The two file formats of musescore, mscx and mscz are incompatible. In both formats the reference to the picture is a full path. But whereas in mscx the path is on disk in mscz the path is within the gzipped container. I assume that part creation is not aware of this incompatibility and trys to use the reference into the container as a disk path. There, no such file exists.
I mostly agree with this "hint". Before the part is saved, it only resides in memory, so there is no "container" to reference.
Is there any problem in using an MSCX to start the part extraction?
If you use 7zip or a similar program to open the mscz file you can see what's contained:
- a directory META-INF containing the file container.xml
- a directory Pictures containing the embedded picture as pict1.jpg
- the mscx file containing the reference/link "Pictures/pict1.jpg" as an image
This is why I called the mscz file a container.
If the embedded picture is an external reference to a file on disk (like in mscx) you only need to copy the reference "full path" to the extracted part (in order to retain the picture). But with mscz you need to copy over the complete directory Pictures to the part's mscz (container- ) file if you want to achieve this behaviour.
To answer your question, I already have the parts I wanted. It worked fine if I temporarily removed the picture from the original score before starting part extraction.
The patch is commited.
MSCX is an intermediary format. It doesn't make sense to compare MSCX and MSCZ, or say they are incompatible. "Save as MSCX" is more a convenient way of debugging. See [File Format]
So let's focus on MSCZ. The problem is indeed deeper. When the parts are created the images are potentially no more on the file system. To solve the issue, the images are to be dump from memory to temporary "real" directory, and all the paths needs to be updated to local path. When the part will be saved, the images will be transfered from the local file system to the zip one.
I tried this approach, but unfortunatly, it does work well with the way parts are created currently. A part is created by making an XML (MSCX) "stream" of a score in memory and read into the score structure. When it's done, images are referenced in the Zip file system, and somehow already loaded. Copying the file after this step doesn't work...
I think we will live with this crash in 1.2...
Sorry, but I cannot agree. I first intended to ignore your bold statement. But then I decided to offer my humble opinion.
I think, the xml file format was the earlier one and invented to hold all information on a score. To name it now that somebody introduced a "compressed" file format as intermediary or debugging help is keen. My impression of the design of that "compressed" extension is of style "quick and dirty". This is only after having glimpsed the sources of mscore 1.1.
The cause of the crash is with autosave (autoSaveTimerTimeout). There, the routine to save compressed is called without exception handler: "// TODO: cannot catch exeption here:" But saveCompressedFile throws an exception if it cannot find the file "Pictures/pict1.jpg". This is honoured in the C++ runtime with calling terminate, bang.
The same effect you can trigger with saving a score (having a picture) that you opened from mcsz as mcsx. If you reload this score (mcsx) and do a change for autosave to do its work musescore abnormally terminates.
By the way, I missed some features, e.g. mixer, to be reflected in the file. This means, If you open the score after a while when you worked on other scores it will sound differently than the last time you played it. Please let Musescore not become a mockup rather than a product.
Thank you for the extended analysis.
We've already become aware that the issue can be triggered in ways other than part creation.
We're currently looking into a "quick fix" since the deadline for the release of 1.2 is nearing.
For missing features, please submit a feature request, otherwise it will get lost.
We always encourage people with the right skill-set to come an board and contribute. If you're interested, a good starting point is the developers handbook: //musescore.org/en/developers-handbook
In the trunk the score cannot be opened.
Issue #15263: [trunk] opening 1.1 score crashes
Here is my suggestion for a patch. You can call it a hack, a kludge, a workaround, or a mockup.
Fact is, this patch stops the crash and gives a semi-informative error message.
A very simple example to reproduce the problem if you don't want to go through the part creation:
1) Create a new score, embed an image. Save as MSCX.
2) Now rename the image in the file system.
3) Open the score, no image shows.
4) Save the score as MSCZ. You get a message, but the score saves and there is no crash.
We will need to reviews this bug for the trunk once we can actually open the score (see comment #14).
There is an issue in the system that calls for a removal of "throws":
issue #15264: [trunk] [branch 1.2] Need to clean up use of exeptions (throw)
Thanks for the patch. Commited in r5401.
Would this mean that a new string needs to get translated?
Yes, two new strings, the translation server will be updated soon. Of course, these strings appears only in case of an error, so it's not vital to have them translated.
German translation is done
(and just after you synced updated translations into the branch)
What should be done now?
There are two options:
1) patch the trunk like we did for the 1.2
2) fix the problem properly.
The first option is easy, it would take less than 10 minutes to do.
should be fixed since ages