Single effect chains not visible after first start in effects_refactoring branch

[Daniel Schürmann]

Single effect chains are created during the first start of Mixxx.
However they are not shown in the Effect preferences.
A restart of Mixxx fixes the issue.

The single effect chains should be visible instantly after start.

[Be (be.ing)]

What do you mean? Where are they not shown? Please post a screenshot.

[Be (be.ing)]

I cannot reproduce this after `rm -rf ~/.mixxx/effects*`

[ronso0 (ronso0)]

I'm not sure if this is what @dascher refers to, but I don't see a simple filter in the Quick Effect selector. This is a basic effect that should easy to pick, like flanger etc.
Restarting doesn't change that.
What am I missing?

[ronso0 (ronso0)]

Oh, they do show up after pressing Reset To Defaults, both in the preferences and in the selector in the skin.

[Be (be.ing)]

It's possible you have some weird state in ~/.mixxx/effects or ~/.mixxx/effects.xml from testing an earlier development version. Mixxx must not override the user's modified state with default settings unless the user presses Reset To Defaults in the preferences.

Please test again after running `rm -r ~/.mixxx/effects*`. If you can reproduce it, there is a bug.

[ronso0 (ronso0)]

I removed the effects folder for a clean start. 100% reproducible.
No simple effects listed, no effect loaded to the Quick Effect slots.

[Be (be.ing)]

Did you remove effects.xml too or just the effects directory?

[ronso0 (ronso0)]

true, the effects.xml needs to be removed, too. Thought that was the one from main.
Now effects are displayed correctly.

[Daniel Schürmann (daschuer)]

I have started Mixxx with a completely fresh preferences folder and I cannot longer reproduce the issue. So I think the issue is the same ronso0 describes.

[Be (be.ing)]

If the issue can be reproduced by upgrading settings from Mixxx 2.3 then there is a bug. Otherwise there is no problem.

[Daniel Schürmann (daschuer)]

Did you change something lately, that make the preset incompatible?
I have used the effect_refactoring branch here the first time two or three week ago. So it is unlikely that I have used an old version that creates the issue.

However I have switched between 2.3 main and this branch many times.

This will be the common case for many contributors after merge like rons0 so I do not longer consider this bug as invalid.

[Be (be.ing)]

The XML format for the presets has not been changed recently, at least not intentionally.

[Be (be.ing)]

I tested creating new settings directories with 2.3 then using it with effects_refactoring and could not reproduce this. I also could not reproduce it with a fresh settings directory created by the main branch.

[Daniel Schürmann (daschuer)]

It is normal in such cases that the original author is not able to reproduce it.

Ronso0 and I experienced the issue and when have no explaination why.
We also have no evidence that this cannot happen for another user.

Please reconsider your latest status change.

[ronso0 (ronso0)]

For me, the issue vanished when I also deleted effects.xml which I have been using for testing 2.3.x, various PRs targeting main as well as the effects_refactoring branch.

If we approach the issue from the other side:
what would prevent loading the simple effects?

[Daniel Schürmann (daschuer)]

Could it be caused by a previous debug assert crash?

What is the rule that creates these chains?
Is there a way to trick that rule?

[Be (be.ing)]

> what would prevent loading the simple effects?

I presume you mean the autogenerated chain presets with a single effect. Those would not be added to the chain preset lists if effects.xml has a list that does not include them.

[Daniel Schürmann (daschuer)]

There is something fishy we need to investigate. I have set this to confirmed that it does not fall from the shelf.

[Be (be.ing)]

There is nothing to investigate if it cannot be reproduced.

[Daniel Schürmann (daschuer)]

We have two reports confirming the issue. This is sufficient to put a bug into a confirmed state.
It does not really sense to put a expiration timeout to the bug in this case.

> There is nothing to investigate if it cannot be reproduced.

For my understanding the opposite is true, to deliver a rock solid software.
I understand that this Bug is probably not the most pressing issue, especially because it cannot be reproduced, but understanding the issue would help.
The bug is a reminder for this.

[Launchpad Janitor (janitor)]

[Expired for Mixxx because there has been no activity for 60 days.]

[Swiftb0y (swiftb0y)]

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/10569