Proposed as a Blocker for 37-final by Fedora user tdaede using the blocker tracking app because:

 > For all release-blocking desktop / arch combinations, the following applications must start successfully and withstand a basic functionality test: 
> file manager

Not having any thumbnails in the file manager is a very visible functionality loss (although technically files can still be managed).

Discussed during the 2022-09-26 blocker review meeting: [0]

The decision to delay the classification of this as a blocker bug and accept is as an "AcceptedFreezeException (Final)" was made in order to gather more info on how bad the CPU load issue is. We agree that the lack of thumbnails is an annoying cosmetic issue but not serious enough to block on. It's definitely serious enough (and in a component of the Workstation live, so not fully fixable with an update) to grant an FE.

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2022-09-26/f37-blocker-review.2022-09-26-16.01.txt

Yesterday, during Blocker review meeting, I promised I would test this with my setup, but I was not able to trigger this. Although, I have set scaling to 200%, I could always see the thumbnails in Nautilus. I did not see any bigger increases in CPU activity either. It seems my displays are not HI-DPI enough.

hum, it *ought* to happen with scaling set to 200%. I'll see if I can reproduce on my hidpi laptop, though.

So, I can reproduce this. But you need to hit a file that *doesn't already have a thumbnail*. Apparently this change doesn't make nautilus re-generate new hi-res thumbnails for files that already have them. So I had to create a new directory and download some random photos into it. Then when accessing that directory the bug occurred.

I put two fairly high-res JPEGs in the folder. On my other laptop - CPU is a dual-core i7-7500U - I see two processes using about 30-40% CPU time each, so I think together they're burning about 40% of the total CPU time across two cores. This persists as long as nautilus is showing the affected directory.

-6 blocker in https://pagure.io/fedora-qa/blocker-review/issue/918 , marking rejected blocker (it is still accepted FE).

I really think we could backport the simple workaround in nautilus here, it is safe and simple and restores previous behaviour. A slightly blurry thumbnail is much better than no thumbnail and a spinning CPU.

FEDORA-2022-2f7ae3de74 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-2f7ae3de74

FEDORA-2022-2f7ae3de74 has been pushed to the Fedora 37 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-2f7ae3de74`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-2f7ae3de74

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

FEDORA-2022-2f7ae3de74 has been pushed to the Fedora 37 stable repository.
If problem still persists, please make note of it in this bug report.

I can confirm that the nautilus update fixed this problem.

Note, the nautilus update more 'works around' than 'fixes' the problem, by just reverting the change to nautilus so we go back to always using lower-res thumbnails. But we can track the "true fix" (to get higher-res thumbnailing working when appropriate) upstream, I think.