Lmms: "Loading project" percentage incorrect

[musikBear]

lmms 1.1.90
win32 xp3

Is there a std sequence in project loading.
More specific, does loading always follow the same sequence,
First loading is instruments, then automation then.....
OR
is it different from project to project, depending on the actual structure of the projectfile. Eg loading as a kind of 'what is to come first on screen, will be loaded first'.
I am trying to figure out what the last 2% that loads during a specific project loading, is.
I would like to know, because I experience load freezing.
After 98% loading, lmms 'jump back' to 82% loaded, and there lmms freeze. Have others seen behaviour that 'revert-jump' after 98% loading?

[tresf]

Have others seen behaviour that 'revert-jump' after 98% loading?

Yes.

[musikBear]

@tresf That is not enough information
One word is not.
So in what situation, and did you manage to find a reason for a revert from 98% to 82%
If the loading sequence is sequential, then a revert would mean some kind problem in that sequence.
If you have information about the loading sequence it would be valuable.

[tresf]

@tresf That is not enough information

We are all seeing the 68%, 36%, 99% problem and the intent of my Yes answer was to answer the portion that was known, without speculating.

Perhaps you can learn C++ and help yourself out. That would be valuable and would avoid unnecessary ad hominem (which I'm now equally guilty of) ;)

[PhysSong]

The "Loading project" percentage is calculated in TrackContainer::loadSettings(). It counts objects per track, not total objects of whole song.
When every track starts loading, pd->setMaximum( pd->maximum() + _this.childNodes().count() ) is called. It causes the "revert-jump" because the progress displayed in the dialog is value/maximum*100%.
There's an solution, counting total object first and setting maximum value of progressive dialog to it. However, it can slower the loading of projects slightly.
@tresf How do you think about it?

[musikBear]

However, it can slower the loading of projects slightly.

Imo not a good idea. Project loading in rc3 is already significantly slower than previously. A different thought could be not to show percentage at all, but show the actual number of objects, like
Total to Load : xxxxxx Loaded : ...xxx
Then it would be of no importance in witch order the objects was loaded, but the real issue was: what object-load made the loading halt after a revert, and often at 68 or 82 %, and then freeze lmms.

[tresf]

Imo not a good idea.

Please stop. This isn't a peanut gallery. The performance implications of his proposal are in milliseconds and he's proposing a fix for YOUR bug. Don't back people into corners with rhetoric please.

@tresf How do you think about it?

👍

[PhysSong]

The performance implications of his proposal are in milliseconds

I've tested by counting object number 1000 times, @tresf is right.
I'll do more tests and make a PR if I works properly.

[softrabbit]

How about being more informative, like displaying the track names as they're being loaded? That would be helpful in reporting any loading troubles. Something like _"Loading track 7/11 (Big Chords)"_

[musikBear]

@softrabbit that would be a extension of the 'count of objects', so good imo.

[PhysSong]

@softrabbit Good idea. I'll try to implement it.

[PhysSong]

Now I'm preparing for the PR, but there's a problem: Fixing incorrect loading percentage is a bug fix. Is showing track name on loading a bug fix?
If it is, only one PR is needed. If it isn't, I should make two separate PRs(One for bug fix, the other for this new feature).

[zonkmachine]

I think one PR in two separate commits against stable-1.2 will be fine.

[tresf]

If this is a regression in 1.2, ok. If this is not a regression, we should aim these at master.

[PhysSong]

Then @tresf do you think showing track name on loading is a regression on 1.2? Or not, why?
For more details, see my project-load branch.

[tresf]

I'm talking about #3611 (bug) in general, not the enhancement mentioned. It would certainly be silly to decouple the enhancement if it's a quick fix, so @zonkmachine's advice would be favored.

[PhysSong]

Okay. I'll do some more tests and make a PR soon.

[PhysSong]

Please test my PR and give feedback to me.