Reproduced with ab1ecd7 under Windows 8.1 and Linux Mint 17.
The log has changed since the report by chen lung.
The problem now seems to rise from the fact that the "current score" object is changed before the guiStop event is launched. A similar crash can be obtained by using "open file" instead of "open recent".
For the "open file" case the following lines: if (seq)
seq->guiStop();
can be added to the if (cmd == "file-open") case between lines 4045 and 4046 of mscore/musescore.cpp else if (cmd == "file-open")
loadFiles();
In the "open recent" case it is more tricky.
Adding the previous lines(if (seq) seq->guiStop();) to the MuseScore::selectScore function does not prevent the crash since, if I understood corrrectly, a guiStop event seems to be put in a delayed event queue, which is processed after the recent file is loaded (thus still crashing because the current score has changed in the meantime). If those lines are added to the MuseScore::openRecentMenu() function the crash is solved, but the playback is stopped when the mouse cursor runs over the "Open Recent" menu.
I tried with seq::stopWait, but the result is the same as before.
The problem is that guiStop tries to save the play position even if the score is not actually playing (as it happens for the newly loaded score) and it is in "normal" state.
The bug can probably be solved by adding a guiStop for cmd == "file-open" and in MuseScore::selectScore (before loading the new score), while at the same time modifying guiStop so that it acts only if in play (also play-entry?) state. (Comment to the line before: if we didn't add the guiStop for the "open file"/"open recent file" cases we risk of letting those scores remain in play state, while the current score, which is the one seen by the delayed guiStop, is in normal state).
Would this introduce collateral bugs? If I understood correctly, guiStop function is to stop playback, so in principle it should work only when a score is actually playing.
Comments
Reproduced with ab1ecd7 under Windows 8.1 and Linux Mint 17.
The log has changed since the report by chen lung.
The problem now seems to rise from the fact that the "current score" object is changed before the guiStop event is launched. A similar crash can be obtained by using "open file" instead of "open recent".
For the "open file" case the following lines:
if (seq)seq->guiStop();
can be added to the if (cmd == "file-open") case between lines 4045 and 4046 of mscore/musescore.cpp
else if (cmd == "file-open")loadFiles();
In the "open recent" case it is more tricky.
Adding the previous lines(
if (seq) seq->guiStop();) to the MuseScore::selectScore function does not prevent the crash since, if I understood corrrectly, a guiStop event seems to be put in a delayed event queue, which is processed after the recent file is loaded (thus still crashing because the current score has changed in the meantime). If those lines are added to the MuseScore::openRecentMenu() function the crash is solved, but the playback is stopped when the mouse cursor runs over the "Open Recent" menu.What about seq::stopWait ? We call it in seq::setScoreView() but if I read it well, it's too late?
I tried with seq::stopWait, but the result is the same as before.
The problem is that guiStop tries to save the play position even if the score is not actually playing (as it happens for the newly loaded score) and it is in "normal" state.
The bug can probably be solved by adding a guiStop for
cmd == "file-open"and inMuseScore::selectScore(before loading the new score), while at the same time modifying guiStop so that it acts only if in play (also play-entry?) state. (Comment to the line before: if we didn't add the guiStop for the "open file"/"open recent file" cases we risk of letting those scores remain in play state, while the current score, which is the one seen by the delayed guiStop, is in normal state).Would this introduce collateral bugs? If I understood correctly, guiStop function is to stop playback, so in principle it should work only when a score is actually playing.
I am unable to reproduce.
I am unable to reproduce too (Linux Mint 17). Playing actually stops when loading another score.
M.
Thanks guys.
I can't reproduce either, so I'll close.
Using MuseScore 2.0 Nightly Build (70e228a) - Mac 10.7.5.
Automatically closed -- issue fixed for 2 weeks with no activity.