file corrupted in nightly build

• Apr 5, 2015 - 13:09
Type
Functional
Severity
S4 - Minor
Status
closed
Project
MuseScore

I saved the score and re-opened musescore.
When I tried to reopen the score I was working on I see that it is corrupted.

Measure 1 Staff 1 incomplete. Expected: 1/4; Found: 0/1
Measure 1 Staff 2 incomplete. Expected: 1/4; Found: 0/1
Measure 1 Staff 3 incomplete. Expected: 1/4; Found: 0/1

This could be a problem with the first measure. Indeed the time signature is 3/4 but the first measure just has 1 single count in it. The notes should be a dotted eight rest followed by a 16th note.

I'm using the following version.
4f94df8

Is there anything recoverable from this score? Or do I really need to start over from scratch?

Attachment Size
Sonate_No_6_allegro.mscz 31.88 KB

Comments

• Apr 5, 2015 - 13:37

I'm afraid that file is beyond repair, as soon as I open it and try to select the one and only and entirely empty measure, MuseScore crashes on me

How did you get into that situation?

Reply

• Apr 5, 2015 - 14:55
Status (old) needs info ⇒ active

I uncompressed the mscz, and opened the included mscx with a text editor (a linux one)

and saw that the datas are here. I saw 2 measures numbered 1. So I tried to suppress the first one (indeed an irregular measure) but this increased the number of errors). So the error in the text file presumably is not important, but finding it requires someone knowing better than me the codification used by mscore....

indeed I copied the first measure 1 of staff 2 in place of the first measure 1 of staff1 and obtained the attached mscx. Just repair the upbeat and save in mscz

but don't ask me to explain...

Attachment Size
Sonate_No_6_allegrorl.mscx 74.27 KB

Reply

• Apr 8, 2015 - 09:47

Can someone please help me figure something out.

I want to download a nightly build which contains this fix.
How can I figure out which one to use?
I have a cloned git repo, with two unmerged branches
remotes/upstream/master
and
remotes/upstream/2.0

For example, is there a way to know which commit fixes this bug?

I notice that the latest nightly is MuseScoreNightly-2015-04-08-0948-a628bf9.dmg
but "csh> git pull upstream a628bf9"
does not find such a remote ref.

Thanks.
Jim

Reply

• Apr 8, 2015 - 10:21

The issues are not fixed for now. See the two issues I linked to.

The issues are both regression from MuseScore 2.0 and you wouldn't have experimenting them if you didn't use an unstable nightly version in the first place. So it's better to stick with the stable version.

That being said, the fixes will happen in the master branch and not in the 2.0 branch since the bugs do not exist in the 2.0 branch. I'm not sure yet if the fixes will make it possible to open your corrupted files, it will depend on the way we fix the regression.

I explained the difference between the two branches here : http://dev-list.musescore.org/Preparing-MuseScore-2-0-1-bug-fix-release…

Reply

• Apr 8, 2015 - 11:38

OK, good information to have. So given a nightly build such as
MuseScoreNightly-2015-04-08-0948-a628bf9.dmg
how can I find the commit it is build from?
Is it possible?

Reply

• Apr 8, 2015 - 22:59

Yes a628bf9, but which git command should I use to pull that commit?
I tried the following but it didn't work.

csh> git pull upstream a628bf9
fatal: Couldn't find remote ref a628bf9

Reply

• Apr 9, 2015 - 08:14

Hi Jojo, thanks for the help.
That git command doesn't work for me unfortunately.
Here's what happens.

bash-3.2$ git pull upstream/2.0 a628bf9
fatal: 'upstream/2.0' does not appear to be a git repository
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
bash-3.2$ pwd
/Users/jimka/MuseScore
bash-3.2$ git remote
origin
upstream
bash-3.2$ git branch -r
origin/HEAD -> origin/master
origin/master
upstream/2.0
upstream/2.0beta1
upstream/mast

Reply

• Apr 9, 2015 - 09:15

I would go for

git fetch upstream
git checkout 2.0
git merge upstream/2.0

You will be at the last commit of the 2.0 branch that should contain the commit you want and that should be fine. You can later do the same again to make sure you have the last code of the 2.0 branch.

If you really really want to be on this commit in particular I would do

git checkout a628bf9

But then to go back to the branch git checkout 2.0.

Again don't do this if it's not for testing purpose... If you need more help, feel free to pop into our IRC channel #musescore on freenode.net

Reply