Bug 1798987

After downgrading to audacity 2.3.2 using dnf --releasever 30 distro-sync, I can confirm that the bug doesn’t happen. (Seems to have been introduced recently.)

I was able to inadvertently reproduce the bug on another machine running f32 and audacity 2.3.3, both with GNOME X/Wayland and Sway/Wayland.  Audacity was behaving normally then at some point it stopped displaying the cursor (unless I use a way to redraw the whole window constantly, e.g. by toggling "Pin play head").

Deleting .audacity-data doesn’t resolve anything, nor does reinstalling the package or starting a graphical session as another user.  Feel free to let me know if additional info is needed.

Actually it’s even worse; after a few hours of work on a moderately large file, the Audacity window is no longer updated *at all*.
- Obviously, no cursor at all.  No selections either.
- Waveform stays static, even though the sound’s playback is moving on largely beyond what’s displayed.
- Likewise, timecodes above the waveform remain frozen.
- Enabling "Pin play head" stops helping after a while.
- By going in blind and selecting some fragments willy-nilly, I can confirm that the program is actually still responding; apparently only the display part of the GUI’s affected.

All in all, this renders Audacity more or less unusable.  Not sure if it’s a toolkit problem with wxGTK3 or what (hard to tell since there are very few other programs using that).

Perhaps more interestingly, even the status bar is frozen as well.  When saving the file with Ctrl-S, the "saved" message isn’t displayed although the file _is_ indeed saved in its current state.

This tends to happen when there’s a lot of disk activity involved (caching audio chunks etc.).  I was able to reproduce that behavior on three different machines with various amounts of RAM, with or without disk swap, so that doesn’t seem to be relevant here.

I’m gonna try and submit a report upstream as well.  (Instead of adding to the noise on this tracker :-)

Audacity has some UI issues when running under Wayland (https://github.com/audacity/audacity/issues/471). Please try launching with "GDK_BACKEND=x11 audacity" to see if that fixes the issues.

Oh, indeed, it appears to be yet another instance of their bug #471. Setting backend to x11 fixes the problem. (What’s weird is that even selecting gnome-x11-session in gdm doesn’t fix the issue.)

I’ll let them know. Thanks!

Thanks for testing. I will see about making that the default invocation for launching Audacity.

That might be worth exploring.  One of their folks just told me: “We do not yet "officially" support Wayland as we don't have the resources to  do so, though we will as it becomes more mainstream.”

It does appear that Fedora’s wayland/GNOME is particularly prone to this bug, though, much more than Ubuntu’s for example.

See also https://github.com/audacity/audacity/issues/459

I have hit this same problem (in its "play cursor not moving" form) on RHEL 8.2 beta, Audacity from EPEL. Worked around it by adding GDK_BACKEND=x11 to the Exec line in the audacity.desktop file (after "env").

So EPEL is also hit.

FEDORA-2020-b3bcb3f08b has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-b3bcb3f08b

FEDORA-2020-18014ddf17 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-18014ddf17

FEDORA-EPEL-2020-5b4b41394d has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-5b4b41394d

FEDORA-EPEL-2020-75532e052f has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-75532e052f

FEDORA-EPEL-2020-75532e052f has been pushed to the Fedora EPEL 8 testing repository.

You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-75532e052f

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2020-b3bcb3f08b has been pushed to the Fedora 31 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-b3bcb3f08b`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-b3bcb3f08b

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2020-18014ddf17 has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-18014ddf17`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-18014ddf17

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-EPEL-2020-5b4b41394d has been pushed to the Fedora EPEL 7 testing repository.

You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-5b4b41394d

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2020-b3bcb3f08b has been pushed to the Fedora 31 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2020-18014ddf17 has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-EPEL-2020-75532e052f has been pushed to the Fedora EPEL 8 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-EPEL-2020-5b4b41394d has been pushed to the Fedora EPEL 7 stable repository.
If problem still persists, please make note of it in this bug report.