https://bugs.kde.org/show_bug.cgi?id=520738
towe <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Playlist thumbnails |[REGRESSION] Playlist |generation uses frame 0 |thumbnails use frame 0 |instead of offset |instead of offset, and fail |(regression in 1.8.1) |to load completely during | |fast scrolling (1.8.1) --- Comment #1 from towe <[email protected]> --- Title: [REGRESSION] Playlist thumbnails use frame 0 instead of offset, and fail to load completely during fast scrolling (1.8.1) System: openSUSE Tumbleweed (KDE Plasma), Haruna 1.8.1 Description of the Issues: 1. Black Thumbnails: Since version 1.8.1, playlist thumbnails are generated from the very first frame (Frame 0, which is pitch black for most videos) instead of using a proper time offset. 2. Missing Thumbnails & Console Errors: When clearing the thumbnail cache and scrolling quickly through a large playlist, Haruna throws several "[swscaler] 1920x1080 -> 0x0 is invalid scaling dimension" errors. Consequently, many thumbnails fail to load and remain empty placeholders until the user manually scrolls back and forth or restarts the application. Root Cause Analysis: After digging into the code, I found that this is caused by two overlapping issues introduced in the 1.8.1 / Qt6 transition: 1. Frame 0 Regression: In `src/framedecoder/framedecoder.h`, the variable `m_AllowSeek` was changed/set to `false`. This breaks the frame offset logic and forces FFmpeg to extract frame 0. 2. QML Race Condition & Thread Starvation: In `src/playlist/PlaylistItemWithThumbnail.qml`, the `Image` component requests the thumbnail immediately. However, during the initial drawing phase of the QML delegate, the layout hasn't fully computed, resulting in a layout width/height of 0. This sends a `0x0` dimension request to the C++ FFmpeg worker, which crashes the `swscaler`. Furthermore, fast scrolling without proper `ListView.onPooled` cleanup overloads the worker with requests for out-of-view items, causing thread starvation (hence the empty placeholders). Proposed Fix (Patch Attached): I have attached a patch (`haruna_1.8.1_ThumbPlaylist_repair.patch`) that fixes both issues: - Reverts `m_AllowSeek` to `true` in `framedecoder.h`. - Refactors the QML `Image` loading in `PlaylistItemWithThumbnail.qml` to: - Use an `interval: 0` Timer to defer the image request to the next event loop frame, ensuring the layout is fully calculated (`width > 0`) before asking C++ for an image. - Properly clear the source and stop the timer in `ListView.onPooled` to prevent caching empty images and cancel requests for recycled elements. - Add a smooth opacity fade-in to prevent visual ghosting of old thumbnails. Steps to Reproduce (without patch): 1. Clear the Haruna thumbnail cache (`rm -rf ~/.cache/haruna/*`). 2. Open a directory containing many video files (e.g., 50+ videos) and open the playlist pane. 3. Scroll down quickly. 4. Observe the console output for `0x0 invalid scaling dimension` and notice the empty placeholders and black thumbnails in the UI. Version 1.7.1 generated correct thumbnails smoothly, so this represents a regression. The attached patch fully restores and improves the functionality. -- You are receiving this mail because: You are watching all bug changes.
