Search field: Keystrokes get mixed up

[Uwe Klotz]

Since building with Qt5 I noticed the following behavior: Keystrokes get mixed up when you continue typing in the search edit field while the UI is frozen during a database query that has been triggered by a typing timeout.

The typing timeout of 300 ms is too low for finishing typical search queries. The larger your library the more serious those intermediate and unwanted disruptions become and the more difficult it is to correct the wrong ordering of letters and to finish your query as intended. Totally annoying and hardly usable!

I propose to at least double the timeout to 600-800 ms. You can trigger a search manually at any time just by pressing Return, instead of stop typing and waiting for the timeout kicking in. The current timeout of only 300 ms combined with the keystroke issue is unacceptable.

I also noticed that the state management and signal handling in WSearchLineEdit is unnecessarily complex. I already fixed it, but unfortunately this did not fix the mixed up keystrokes.

[Uwe Klotz (uklotzde-deactivatedaccount)]

https://github.com/mixxxdj/mixxx/pull/1762

[Daniel Schürmann (daschuer)]

I cannot confirm the issue on Ubuntu Xenial with a library on a spinning HD and 17k titles.
Are you sure that this is a regression from the Qt5 change?

[Uwe Klotz (uklotzde-deactivatedaccount)]

Definitely a Qt5 issue. I switched a few times back and forth between Qt4 and Qt5 during development and this happens only on Qt5. There is even not a clear pattern when this happens exactly. The only common pattern is after continue typing while a search freezes the UI *sigh*. If it happens it feels like you are stuck in the mistyping mode, it's difficult to complete the search without subsequent errors.

Using Wayland/XWayland on Fedora, which might be another necessary precondition. I should try the X only fallback.

[RJ Skerry-Ryan (rryan)]

I think 300ms vs 600ms makes a meaningful difference in the "feel" of interactivity -- is increasing the timeout necessary to fix this bug?

[Uwe Klotz (uklotzde-deactivatedaccount)]

We can keep the 300 ms. I will simply disable in in my personal patched version. A search can be started reliably at any time just by pressing ENTER.

The search-as-you-type feature does not fit into the current architecture. In combination with this bug it gets you into trouble if each database query takes >2 sec and freezes the GUI. You need multiple tries with enforced waiting periods in between to correct and finish your intended search, which is unusable in live situations.

Optionally the timeout could be configurable by the user. At least until we have a solution that doesn't cause major usability issues depending on your personal typing speed and habits.

[Uwe Klotz (uklotzde-deactivatedaccount)]

Pushed back to the 2.3 release. We will see if this issue affects multiple users after releasing 2.2.

[geozubuntu (geozubuntu)]

Mixxx 2.3.0-alpha-pre (build master r6654)(I have set the nightly repos and update the windows as well) linux mint 19 tara x64 and Windows 7 ultimate x86.

Sometimes keystrokes are mixed sometimes characters are missing.
Having a database of eighty thousand (80000)Tracks it is very frustrating to search. Every 2 characters the UI freezes for 2-3 seconds (if it is not analyzing any tracks at the same time in the background) and after that when try to correct the string it freezes again. Very inconvenient in live situations and broadcasting.

A checkbox in preferences like "search as you type" to enable or disable the automatic search and a field for adjustable timeout would be a good, very convenient solution (and an easy one, I think). I would like to have the keywords typed and wait for me to load a deck or speak to the mic and then give focus to search field and hit the enter to start the search in a time I don't really care for the freezing of UI.

Unfortunately the way it works now is not helpful at all.

In any case many thanks for your efforts. :)

[Uwe Klotz (uklotzde-deactivatedaccount)]

Thanks for chiming in! Without evidence that other users are affected too prioritizing this bug was impossible.

A patch for mitigating the issues caused by UI lockups while searching is available: https://github.com/mixxxdj/mixxx/pull/1762

With this patch you are able to raise the debouncing timeout up to 10 sec which should be sufficient for most use cases. I'm currently using a timeout of 1 sec.

[Daniel Schürmann (daschuer)]

This means we should merge it, right?
To which branch?

[Uwe Klotz (uklotzde-deactivatedaccount)]

The fix introduces a new feature and ui element. According to our rules it's already too late for merging it into 2.2. But on the other hand risking to annoy and probably lose users with large libraries is a serious reason for requesting an exception.

I'm biased and won't make any decisions ;)

[Uwe Klotz (uklotzde-deactivatedaccount)]

The branch of the PR is still based on 2.2.

[Daniel Schürmann (daschuer)]

My vote is to merge it to 2.2.
I consider the change as a low risk and I can effort that it is not translated.
Any other opinion?

[Swiftb0y (swiftb0y)]

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