Thanks a lot! :pray:

• cf6aef66 gstreamer_backend: Remove extra buffering probe […] by Philipp Bartsch
• c0a2d9f8 Make clippy happy! […] by Philipp Bartsch
• 052ae47c Merge branch 'main' into 'gstreamer-backend-buffering' […]
• 75d6596b Merge branch 'gstreamer-backend-buffering' into 'main' […]

This is potentially fixed by cf6aef6692cda251e6f91268be9b6d393c0ae070. Can you try if you're still able to reproduce the problem?

This is potentially fixed by cf6aef6692cda251e6f91268be9b6d393c0ae070. Can you try if you're still able to reproduce the problem?

This shouldn't be an issue with Shortwave, since we have a 1 second timeout on search logic side: https://gitlab.gnome.org/World/Shortwave/-/blob/75d6596bcc736e04ebcb6fa2c7437cbcf562e0d1/src/ui/pages/search_page.rs#L277

So I'm not sure if this problem applies to Shortwave?

I already removed all direct calls to gdk_pixbuf with https://gitlab.gnome.org/World/Shortwave/-/commit/0dee129d59beedda7ab1cc9b4e360c5a1c47000a, long term we should switch over go Glycin.

duplicate of https://gitlab.gnome.org/World/Shortwave/-/issues/721

Please reopen if this issue still persists.

I can touch the pause button in the middle. This stops the playing of the station. However, it also removes the controls from the lock screen, so I cannot start playing the station without unlocking the screen. This is inconvenient. Please do not remove the controls when stopping playing the station.

duplicate of https://gitlab.gnome.org/World/Shortwave/-/issues/683

• I think that the symbol for stopping the station should be a rectangle, and not the pause symbol, because you cannot really pause playing a station. You can stop and start again however.

• The other buttons (back to begin, 10 sec back, 30 sec forward, forward to next) do not work, obviously, because you cannot do this on a radio station. These buttons do not do anything, so the should all be displayed disabled (or maybe totally removed, if possible).

This is out of scope of Shortwave, we only use the regular MPRIS api here. The API doesn't allow us to hide buttons / set custom buttons.

Hmmm. I don't get any MPRIS controls at all with this MR :/

Oh! I wrongly assumed there was no safety mechanism in place, I did not expect there was something doing this in the backend already, particularly because I saw the spinner activating immediately when (and during) typing.

Arguably, if you were to do it at the SearchEntry widget level, you might be able to simplify your code a bit and dodge the "fake search" spinner thing; i.e. the spinner's apparition would presumably match more closely with "when the search is actually launched". Food for thought :)

In reply to @gitlab:t2bot.io
[World/Shortwave] haecker-felix commented on issue #730: Use a longer SearchEntry search-delay activation for better network efficiency

This shouldn't be an issue with Shortwave, since we have a 1 second timeout on search logic side: https://gitlab.gnome.org/World/Shortwave/-/blob/75d6596bcc736e04ebcb6fa2c7437cbcf562e0d1/src/ui/pages/search_page.rs#L277

So I'm not sure if this problem applies to Shortwave?

@haecker-felix Thanks to you and the contributor for your feeding. I'm failing to reproduce it currently even on 3.2.0. My usage profile of Shortwave has quite declined: So I'm not sure if this is due to the issue already being fixed. Observed it very rarely the past months.

Switching to Nightly release right now. Will report back in case I still observe this issue. If you receive no further feedback, I think you can safely assume it's addressed and fixed in the aforementioned commit.

Alright, thanks for the feedback either way. I'll close this, please feel free to reopen if necessary.

In reply to @felix:haecker.io
Yes, but IIRC the mechanism is a bit more than a simple delay, it also prevents that a new search query gets started when the previous isn't done yet.

• 73c214ef discover_page: Bump station count
• 34e00ab8 search_page: Refactor, get rid of custom timeout machinery. Closes #730

Yup, you were right. Thank you! :)