'loading' window at startup does not close if using Qt library version == 5.5.0 (which current arch linux release uses)

Can you post a screen shot? I can't think of any such window in MuseScore, and wonder if or is something else. Also, how did you install MuseScore? Is there an official package for 2.0.2 yet for you distro?

Hmm, appears maybe that is for the Zerberus window. Somehow maybe it is failing to load. What happens if you go to View / Synthesizer then click Zerberus (warning: I'm guessing it might crash, or hang)? Might be a problem with a mismatch of Qt libraries or something, just guessing. Were you intentionally using this synthesizer?

If you have no Zerberus tab, in the View / Synthesizer window, then I think we've definitely found the culprit. If you start MuseScore from the command line ("mscore"), do you see any interesting console output? What if you run with the "-F" option to revert to factory settings?

Also curious if it ever ran successfully, or if you had ever previously successfully run 2.0 or 2.0.1 or any experimental prerelease build.

FYI, I have the exact same issue of a persistant "Loading..." popup on my arch linux machine on 2.0.2 that I've just been ignoring. When I go to view->synthesizer->zerobus, I don't see anything listed there.

My console output:

[e@localhost ~]$ mscore 
initScoreFonts 0x2ae1340
init Help from: 
cannot setup data for help engine: Cannot open collection file: /usr/share/mscore-2.0/manual/doc_C.qhc
AlsaDriver: recover: stat = 00, xrun of at least 1438041358425.227 ms

Reverting to factory settings:

[e@localhost ~]$ mscore -F
initScoreFonts 0x234e2a0
PulseAudio Context Connect Failed with Error: Connection refused
init PulseAudio failed
no audio driver found
init Help from: 
cannot setup data for help engine: Cannot open collection file: /usr/share/mscore-2.0/manual/doc_C.qhc
Cannot start I/O
sequencer init failed

that removed that loading, however I've also lost my sound output. Reverting settings back to ALSA, closing and restarting again, and now I'm back to seeing that "Loading..." popup. I can't remember when I first saw this issue, but I think it started in one of the nightlies within the past couple of months??? but I've never been bothered enough by it to post here.

Hmm, so you see this with your own self-builds, Eric? I'm looking at mscore/zerberusgui.cpp and seeing code involving _progressDialog and _progressTimer. The only place where the dialog is actually displayed seems to be line 182. If I set a breakpoint there, it is never hit during startup for me. Is it for you?

The dialog is created at line 99, and this *is* hit during startup, but that shouldn't actually display the dialog. There is code in line 192 that could conceivably be involved. This isn't hit for me either, but maybe it is for you? I kind of suspect maybe something about the timer that is set. You might read up on QTimer, look at the code, and experiment to see if you can figure out what is going on.

Oh, for anyone seeing this problem - what version Qt are you using?

I see this on my own self-builds.

If I put a breakpoint at 182 of zerebus/zerebus.cpp, I never hit that breakpoint.

If I put a breakpoint at line 156 (the start of the function), and go to Synthesizer->Zerebus, I hit that breakpoint immediately when I press the "add button". Stepping through that function, I notice there are no files in the "foreach (const QFileInfo& fi, l)" loop to iterate over, and then the if (!ld.exec()) is encountered and the return is taken. I resuming execution, and notice that there is a blank list in the popup of "SFZ files" as shown in this screenshot:

>> There is code in line 192 that could conceivably be involved. This isn't hit for me either, but maybe it is for you?

Breakpoint at 192 is never encountered, neither during startup nor when going to Synth->zerebus->add.

I put breakpoints at all the other lines that have "_progressDialog", and only the constructor (line 99) is hit.

I went ahead and downloaded the gigantic salamander sfz file, started up musescore 2.0.2. Loading bar pops up on boot and as usual and remains empty.

Then I've added the directory I extracted in the list of soundfont folders. Now when I go to Synth->zerebus and Click Add, I see the SFZ files...I added one, and the "Loading bar" is filled up after about 5 seconds. Loading bar completes and dissappears (finally!). I've set this SFZ as default.

I started up musescore 2.0.2 again, and the Loading bar is stiill present on boot and persists. I went ahead and added the other SFZ that I had in the downloaded folder. Loading bar fills up after 5 seconds and then dissapears. I set as default and rebooted musescore. But I still still see this loading bar present on boot and still persists.

I'm trying now to actually play using this zerebus synth...I've disabled the original fluidsyth, and set a zerebus file as default, but all that does is remove sound playback and send "FluidSynth error: event 0x90 channel 0: channel has no preset" messages to my console.

>> Oh, for anyone seeing this problem - what version Qt are you using?

The list of my installed pacman packages include:

qt4 4.8.7-2
qt5-base 5.5.0-1

I'm would think that this qt5-bases 5.5.0-1 is the one that is being invoked by musescore 2.0+

Hmmm, I wonder if that's the source of the problem. I think most of us are still using 5.4, either 5.4.1 or 5.4.2. I know a few people have experimented with builds against 5.5, but I don't know that we "support" it?

arch is always updates to the bleeding edge latest libraries...let me try downgrading to 5.4 and I'll report back.

Indeed, downgrading my qt5 from version 5.5.0-1 to version 5.4.2-1, and then performing make clean && make on the latest master git has removed this issue of a persistant "Loading ..." popup. Therefore we can conclude that the issue is due to arch linux using a newer version of qt libraries. I'm not particularly interested in investigating this futher, as marc said musescore does not support this latest qt library, unless someone can suggest a simple fix, so I've set to "minor" and "postponed" as this issue probably won't be addressed untill musescore decides to use the newer library. I'll upload my self-compiled arch binary statically linked with the 5.4.2-1 library in case other arch users are curious.

my static compiled build of current git master on my arch 64 machine where I downgraded qt to qt 5.4.2-1: //ericfontainejazz.com/mscore_20150728_gitmaster_build_statically_linked_qt-5-4-2-1.tar.bz2

When I run that or the nighlies on that machine with the downgraded qt, I don't see the persistant "Loading ..." popup. I cannot currenly run the offical arch build of musescore on that machine because computer obviously complains about missing qt5 symbols when try to execute, as the offical arch build was probably compiled against qt 5.5.0-1.

When I run that self compiled binary or the nightlies or the offical arch build of 2.0.2 on an arch 64 machine with the latest qt library, then I do see the persistant "Loading..." popup.

I do wonder if maybe the bug lies with the QT people.

Let's keep it open, so it doesn't vanish from the radar, even if we'd need a fix from the outside, here from the Qt folks.
It may need to get reported to them too ;-)

seems our posts crossed...

FWIW, I wouldn't assuem we need a fix from Qt; could just be some behavior changed and we need to adapt.

I still a slight doubt as to whether this really is the Zerberus dialog. Would be worth trying to comment out that code entirely to be sure.

This IS the Zerebus dialog. I verified that by watching it from the start of boot until loading a SFZ, at which point its bar filled up and dissapeared when completed.

Is it better if you replace this line
https://github.com/musescore/MuseScore/blob/7f58e9fa2c9b125827505a468c9…
by
_progressDialog = new QProgressDialog("Loading...", "", 0, 100, this, Qt::FramelessWindowHint);

I'm going to look into this bug now. I guess to be precise I can't say this happens with ≥ 5.5 (as no future libraries have been released!), but only can say that it happens with 5.5.0-1 on arch linux x86-64 and i686 (just verified).

I'll start by commenting out the Zerberus code entirely. If anyone has ideas, please feel free to suggest.

Did you try lasconic's suggestion in response #23?

response #23 did not fix it.

>> I still a slight doubt as to whether this really is the Zerberus dialog. Would be worth trying to comment out that code entirely to be sure.

Commenting out all lines with _qprogressDialog in Zerberusgui.cpp & .h removes the "Loading..." bar. So yes, this really is the Zerebus dialog.

Update: I should clarify earlier I said qt library is statically linked, but now that I think about it, qt library isn't actually statically linked into the binary. I was only just compiling against an earlier version of the library when I downgraded my arch linux packages.

I'm going through //wiki.qt.io/New_Features_in_Qt_5.5 or //wiki.qt.io/Qt550-KnownIssues , but please feel free to throw me suggestions.

First thing I'm trying now is to grab and build with the latest dev version of qt 5.5 from https://github.com/qtproject

Something worth trying is to create a simple Qt app with a QProgressBar, without calling show() or exec(). If the QProgressBar is displayed, I believe it's a Qt bug and should be reported https://bugreports.qt.io and we can make a workaround. For example we could create the progressBar on demand instead of creating it in the constructor.

Same behavior with Qt5.5.0 under Mac OS X 10.8.5, commit 7f58e9fa2c9

I also had same behavior in Trisquel 7 Linux after self-compiling the qt 5.5.1 git version, so whatever behavior has not changed since qt 5.5.0.

Hmm, there is no Qt-5.5.1 yet, just the latest dev version, that eventually may become 5.5.1, right?

yes. all the .so files are called 5.5.1

Qt-5.5.1 is targeted for September, see http://lists.qt-project.org/pipermail/releasing/2015-August/001983.html

The relevant Qt bug is here https://bugreports.qt.io/browse/QTBUG-47042
I will add the reset workaround

I guess it'd be needed in 3 places, zerberus/zerberusgui.cpp after line 99, mscore/exportaudio.cpp after line 82 and mscore/exportmp3.cpp after line 694
I wonder whether it should get restricted to Qt-5.5.0 only?

I'm changing to == 5.5.0 and will let lasconic add a work around, since he obviously has better knowledge about this.

Let's treat the first bug first. It's currently a problem for zerberus only and not for the others. If it ends up being a problem for the other ones, let's fix them.
Btw, if you have a Qt account, feel free to vote for this bug.

I don't have an account there.

Maybe @ericfontainejazz (or someone using Qt-5.5.0) could test those other 2 potential candidates, by trying to export .wav, .ogg, or .flac and .mp3

Fixed in branch master, commit ae7495b763

fix #71001: 'loading' window at startup does not close if using Qt library version == 5.5

Shouldn't that "Loading..." get translated (or rather be made translatable)?
Edit: see https://github.com/musescore/MuseScore/pull/2156

I tested the latest git 3f94d87 that includes lasconic's workaround, at it works correctly, in that I don't see a zerebus loading bar on boot, when running on my arch linux x86-64 machine with qt 5.5.0 libraries, so it appears fixed.

I've also tried export .wav, .ogg, or .flac and .mp3, and I don't observe anything unusual. A progress bar appears when I start export, and then disappears when export finishes. I don't see any stray progress bars on boot.

Good, so there's nothing to fix for those. Thanks for checking

while we are talking about "Shouldn't that", I want to say shouldn't the .flac .mp3 .wav .ogg progress bars have some title, like "Exporting..." (and with translations). Currently I see a nameless progress bar.

Also regarding a related feature request that I created last week in response to someone's computer crashing when trying to loading a Zerberus sound font (#71441: Add a "Cancel" button for Zerebus soundfont loading & audio export) I would like to add a cancel button to these .flac .mp3 .wav .ogg export progress bars, because when I try out on a very large score, I have to wait a minute+ and have no way of canceling except killing mscore.

EDIT: also export .png takes a long time on a huge score...and there is no progress bar at all or any way to cancel...

indeed only exporting audio (including mp3) do have that progress bar
Adding an "Exporting..." should be pretty easy, just add
progress.setLabelText(tr("Exporting..."));
in exportaudio.cpp and exportmp3.cpp
Actually it seems adding a Cancel button is almost as easy, just to a
progress.setCancelButtonText(tr("Cancel"));
and comment out the
progress.setCancelButton(0);

Edit: maybe not that easy, the Cancel button seems to work, that progress dialog vanishes, but it seems the export continues and finishes in the background, so there's some more magic involved to stop it.

Fixed in branch 2.0.3, commit 8974c1a223

fix #71001: 'loading' window at startup does not close if using Qt library version == 5.5

Automatically closed -- issue fixed for 2 weeks with no activity.

Today I see the "Loading" window the first time - like described in the other comments.
Some days before I had realised an upgrade to UBUNTU 16.04 LTS 64 bit, Qt 5.5.1.
Musescore version is 2.0.2, revision 3543170. The Ubuntu version management for Musescore seems not to be up to date.

It had been fixed with MuseScore 2.0.3

You can get 2.0.3 for Ubuntu here: https://musescore.org/en/download

Automatically closed -- issue fixed for 2 weeks with no activity.

Posted in mageia : https://bugs.mageia.org/show_bug.cgi?id=19918

That mageia bug report says for "Source RPM: mscore-2.0.2-6.mga6.src.rpm", which is the previous release. The bug shouldn't be present in current release 2.0.3, so maybe (if you posted that report) you could tell them that this is fixed in 2.0.3 release.

I have do it.