"Save online" fails
There have been several reports lately (basically since 2.2 went live) where "Save online" failed, MuseScore itself reported success, but musescore.com reports that score as "Upload failed".
Some of these forum posts:
https://musescore.org/en/node/271697
https://musescore.org/en/node/271638
https://musescore.org/en/node/271169
https://musescore.org/en/node/271068
https://musescore.org/en/node/270790
https://musescore.org/en/node/270436
But also the score in #271664: 2.2.1 (51b8386) Crashes On All My Computers
Comments
On French forum, another one: https://musescore.org/fr/node/271003
With error message: https://musescore.org/fr/node/271003#comment-828121
See also https://musescore.com/groups/improving-musescore-com/discuss/5017191
Thank you for making this issue Jojo. We are trying to identify the root cause of the issue. As soon as we found something, we'll let you all know.
Several potential causes had been found in some of those cases, a bad font, bad instrumentation plus system breaks, a glissando and some bogus hairpins. No real smoking gun nor any common denominator though.
-Opening this score in MS 2.0.3 and then exporting to a MusicXML file: works okay. No crash.
-Then, importing the .mxl (not compressed) into MS 2.2.1: works ok.
-Then, saving Online the score: works ok. Score link (marked as private , I'll delete it later): https://musescore.com/user/259496/scores/5068401/s/c8c763
-And, lastly, after following the above intermediate steps: an export to MusicXML from 2.2.1: works ok.
(also commented in the musescore.com thread https://musescore.com/groups/improving-musescore-com/discuss/5017191
The score from https://musescore.org/en/node/271697, right? I've now entered the MusicXML crash part of that problem in #271707: MusicXML export: crash when exporting hairpins. Exporting in 2.1 doesn't crash either.
In reply to The score from https:/… by Jojo-Schmitz
Oh, you're right Jojo. It's only from 2.2.1 the crash . Yes, it's the same score. I've temporarily uploaded online using the workaround , for Mark, but the root cause seems, effectively, a regression or bug between 2.1 and 2.2.1.
Just a heads up that lasconic has been able to reproduce the problem with three of the reported score files. Fix coming up.
@Thomas, what lies inside the musescore.com parsing engine that is so nitty-picky or fussy? these scores opens perfectly well inside the application. Can't it simply ingest internally the uploaded score exactly the same as the app does?? do the web engine first export to MusicXML the score before ingesting it?
https://musescore.org/en/node/271697
https://musescore.org/en/node/271638
https://musescore.org/en/node/271169
https://musescore.org/en/node/271068
https://musescore.org/en/node/271068
Crash when exporting to MusicXML in MS::addPositioningAttributes. See #271707: MusicXML export: crash when exporting hairpins
We should fix it, apply a patch on 2.2.1 in a branch and deploy a new MuseScore.com backend.
@mdi1972 there is nothing different in the musescore.com engine, it is not more nitty-picky or fussy than Musescore. It opens the mscz file and export it to midi, musicxml, svg, png etc... If MuseScore itself fails to do so, then MuseScore.com will fail as well.
Btw https://musescore.org/en/node/270436 is different. I don't have the cause yet.
That is the one with the strange font:
The issue was in the incorrect font family of the name "Ранди" in the measure 182. The score seems working correctly after changing its font family to common "Free Serif".
See also #270920: Incorrect font property of one text block
Seems we have known issues for all these now, so can close this issue here as a duplicate of those
In reply to @mdi1972 there is nothing… by [DELETED] 5
@lasconic (or @Thomas), so, by inference, what it does the musescore.com, "at the end of the day" is doing an intermediate export to MusicXML, before treating the upload as successful? before generating the audio?
Can you comment about this?
Erm... @Jojo, please, would you be mind to leave this open, temporarily?
I asked a question, unrelated to the newly created issue, and related to the workings of musescore.com. I would like to know about this, and , being another issue , I honestly think it would be more appropiate to get a concrete response to the question - then close this issue here.
@mdi1972 When a user uploads a mscz file to MuseScore.com, the MuseScore software is started from the command line with the task to open the mscz file and export it to various amount of files: pdf, png, svg, musicxml, midi, mp3, mpos. Also some metadata is extracted from the mscz file such as the work title, subtitle, poet, composer, key/time signature, part names, part programs, musicXML instrument id's, etc. Once done, these files are stored on the MuseScore.com static file servers. In this particular issue, this process fails entirely as it fails to export the MusicXML file. Hope this answers your question.
Answers can still be given here.
I guess musescore.com reporting success only after all the exports have been done might take too long?
Edit: why then does MuseSscore gets returned "Success"?
In reply to @mdi1972 When a user uploads… by Thomas
@Thomas, many thanks for the info, now I do understand.
In reply to Answers can still be given… by Jojo-Schmitz
@Jojo MuseScore gets success if the mscz is transferred onto the server. Only afterwards does the serverprocessing start.
@jeetee correct!
OK, than the error message on MuseScore.com need to get improved, it clearly states "Upload failure", which contradicts the "Upload success "in MuseScore
I'm afraid you would reply with a big "no" but....would be some wiser, given the current (frequent) situation of upload problems, to just catch the failed parser/exporter pass, not bang out the whole thing at the backend? - and then, retrying without running the failed pass (in this case, that would be the majority, the MusicXML export)
You would give musescore.com users a good option. I understand it's crucial to the developer teams to be aware of bugs in the code and trying the whole code path in exporting is good to catch them, but there is a growing downside about these problems in musescore.com.
And you surely already trap these errors internally in the web application, so no lost info (about the error) would happen, no?
Automatically closed -- issue fixed for 2 weeks with no activity.
Automatically closed -- issue fixed for 2 weeks with no activity.
Automatically closed -- issue fixed for 2 weeks with no activity.
Automatically closed -- issue fixed for 2 weeks with no activity.
Automatically closed -- issue fixed for 2 weeks with no activity.
Automatically closed -- issue fixed for 2 weeks with no activity.
Automatically closed -- issue fixed for 2 weeks with no activity.