[BUG] Remote Icon fetching can take an inordinate amount of time

[tdewey-rpi]

Describe the bug
Without a clear pattern, occasionally remote icon fetching from known-up servers can take an inordinately long time. I've observed this both on Raspberry Pi owned servers and on third party servers.

To Reproduce

1. Install Raspberry Pi Imager v1.8.5
2. Load the Model Selector or OS List
3. Observe the row item icons

Expected behaviour
Icons to be loaded and displayed

Screenshots or video

Desktop (please complete the following information):

• OS: macOS Sonoma, Windows 11

Additional context
There's no obvious pattern or log messages corresponding with this behaviour - sometimes it completes as expected - others it never renders. It's also not obviously tied to any one server, nor to an OS-level connectivity discontinuity (at least as shown to the User).

[maxnet]

There's no obvious pattern or log messages corresponding with this behaviour

Recall you need to set environment variables ( QML_XHR_DUMP=1 ?) if you want to see network request logging.

[jedahan]

I wonder if bundling cached versions at build time could mitigate the perceived performance.

[tdewey-rpi]

I wonder if bundling cached versions at build time could mitigate the perceived performance.

Unfortunately that would set us up for a game of cat-and-mouse with new distros, and open us up to claims of unfair treatment against distros that didn't get their requests to have an icon packaged with the binary.

Recall you need to set environment variables ( QML_XHR_DUMP=1 ?) if you want to see network request logging.

Right you are - but part of the problem with this issue is that we're not able to reproduce it deterministically. I've only seen it after 1.8.5, and only then very rarely. I might consider looking at what we could do around response time logging.

Realistically, these assets are very small by modern standards (the Raspberry Pi Zero 2 W icon is ~27k, 405x405 PNG), and as such I'd expect them to take no more than a few seconds each on even an intermittent connection. That we're seeing this behaviour on UK Commercial connections too suggests we're not actually seeing an artefact of the request - but maybe one of an errant server or an exotic QNetworkAccessManager case.

--

I don't strictly have the time to follow up on this one for now - but I did want to capture it to offer a place for the community to upvote if they've seen it too. If anyone is feeling particularly enthusiastic about this issue, I'd suggest they first try to eliminate some of the variables:

1. Can it be reproduced when the icons are on a local drive? (Use a custom JSON file, store the assets locally)
2. Can it be reproduced on an artificially slowed network?

[jedahan]

to backseat a bit more - maybe tagging issues like this with 'ready for community contribution' or something like that would help redirect/lighten the load.

[tdewey-rpi]

@jedahan A fair comment. I'll look at that as part of some other process changes (most notably, we're going to move to using GitHub forms for issue reporting)

[lurch]

I've seen other repos use a 'help needed' tag, which I guess is a bit more concise than 'ready for community contribution' 😉