[legacy] dconf 0.40 breaks preset autoload

[Digitalone1]

I noticed that PE lagacy was not autoloading the preset chosen for the device in use.

The spectrum is moving but levels of enabled plugins are all locked.

The only way to load the preset and apply the desired effects is to disable/enable a single preset. Then the level bars are unlocked and I notice the effects applied.

I tried everything to resolve this issue. Reset the settings, reset the dconf keys, delete the local pe config directory. Nothing works.

Then I gave a look at the last updates from pacman log. Downgraded dconf and everything is working as it should.

So, what could be done and is this happening also on the last release? Please, test.

[wwmm]

This is confusing. Does the autoload fails to load a preset or is the preset loaded but the settings have no effect? Is manual preset selection through the menu working?

[wwmm]

So far I did not notice any problems with dconf 0.40. And the presets manager is still the same in the PipeWire release.

[Digitalone1]

This is confusing. Does the autoload fails to load a preset or is the preset loaded but the settings have no effect? Is manual preset selection through the menu working?

The preset is loaded, but the effect is not applied.

The manual selection through the menu is not changing this behaviour. The only way is to disable and reenable a single plugin.

[Digitalone1]

Maybe I'll give pulseeffects 5.0 a try.

[wwmm]

Maybe I'll give pulseeffects 5.0 a try.

No problems in experimenting with that but I think something else is wrong. Are you sure nothing out of the ordinary is printed when running in debug mode? If even manually the setting is not changed something is broken in GSettings. And changing PE versions may not fix that.

[wwmm]

Are you sure nothing out of the ordinary is printed when running in debug mode?

I would take a look at journalctl output too.

[Digitalone1]

I'll make other tests, but as I remember I didn't notice any error or warning messages in debug mode.

[wwmm]

Ok. Try to load the presets manually while the dconf window is opened and showing our keys. Check if its window is updated while doing that.

[wwmm]

I did more tests and this is happening in the PipeWire release too. But not to all plugins. That is why I did not notice this before =/

[Digitalone1]

As far as I remember, it's happening in all plugins enabled in the screenshots, which are the ones I usually set up. But maybe it's happening also in others.

[wwmm]

And now it is happening to all of them. It seems to me that GSettings behavior was changed in this new release. I can see that the plugin is enabled in the dconf window. But in the initialization this setting is not being propagated to our plugins. And it takes a few attempts for the preset selection to actually activate the callbacks. It is almost like the signals are failing to be emitted...

[Digitalone1]

This needs a fix and a new release for both main and legacy branch. Unfortunately I can't test the code, but it's not and big issue to blocklist dconf in pacman for a while.

[wwmm]

I have found a fix. New releases available both for the master and the legacy branch. Let me know if something is still wrong. I did some tests with the Pulseaudio code in PipeWire's compatibility layer and it seems fine.

[Digitalone1]

Thanks. I'll test it.

[wwmm]

It was something I should have done a long time ago. Replace in each plugin the lines

// useless write just to force callback call

auto enable = g_settings_get_boolean(settings, "state");

g_settings_set_boolean(settings, "state", enable);

by

if (g_settings_get_boolean(settings, "state") != 0) {
      enable();
 }

[Digitalone1]

Fixed.