https://bugs.kde.org/show_bug.cgi?id=524893
--- Comment #3 from [email protected] --- (In reply to xeirla from comment #1) > Thanks for the report! > > m3u/m3u8 Playlists are supported in Haruna, so this sounds like its > something else causing the error. I'm unable to reproduce the issue on my > system. > > Do you have `yt-dlp` installed as well? It is an optional dependency for > being able to parse Youtube links at least, which can be added to m3u > playlists. If so, and that is up to date, then it could be an issue in the > playlist parser or something else. > > Could you please give some additional info to help with triaging? > Specifically: > - The output of `yt-dlp --version` and `flatpak --version`, if they are > installed. > - Specify where Haruna was installed from (extra, cachyos-extra-v4, > flathub/flatpak, etc.) > - Attach a playlist file that's failing to load to the bug report > > > SOFTWARE/OS VERSIONS > Haruna Version: 1.8.1 > yt-dlp Version: 2026.08.19 > Operating System: Arch Linux > KDE Plasma Version: 6.7.4 > KDE Frameworks Version: 6.29.0 > Qt Version: 6.11.2 > Kernel Version: 7.1.8-zen1-3-zen (64-bit) > Graphics Platform: Wayland > Processors: 12 × AMD Ryzen 5 2600X Six-Core Processor > Memory: 32 GiB of RAM (31.2 GiB usable) > Graphics Processor: AMD Radeon RX Vega Thanks for following up. Sorry for the account mix-up, I no longer have access to the account I originally reported this with, but I am the same reporter (kydkunlf). I was able to narrow this down using a different M3U playlist as a test case, and it looks like the root cause is broader than just YouTube-link parsing: relative paths in M3U playlists appear to be resolved against the process's working directory instead of the playlist file's own directory. Requested info: yt-dlp version: 2026.08.19 I dont have flatpak nor flathub installed Haruna installed from: local/haruna Haruna version: 1.8.1-2.1 Reproduction matrix (all run from the directory containing the playlist and media files, via CLI, unless noted): Playlist with bare relative paths (Niketown.flac) -> Haruna does not play, and on exit throws: "QProcess: Destroyed while process ("/usr/bin/yt-dlp") is still running." This suggests at least one entry is being handed to the yt-dlp hook as if it were a remote URL rather than treated as a local file. Same playlist, relative paths prefixed with ./ (./Niketown.flac) -> Haruna opens with an empty player/playlist, no error message, nothing loads. Same playlist opened via file manager (Dolphin) double-click instead of terminal -> empty playlist, nothing loads, no error. Single media file (not a playlist), relative path, run from the file's own directory -> plays correctly. Playlist with all entries rewritten as absolute paths -> plays correctly every time, from terminal or file manager. So the failure only occurs with relative paths in an M3U and only when the process's current working directory doesn't happen to match the playlist's directory (which in normal usage — e.g. opening from a file manager — it never does). This matches the original report's behavior of a permanent loading screen / being handled like an HTTP request: it's consistent with a relative entry being misinterpreted as a remote reference when the local base path doesn't resolve. I'd guess the playlist parser needs to resolve relative entries against the M3U file's own path (QFileInfo(playlistPath).absolutePath() or similar) rather than the application's CWD. Attached: grünewürfelflow.m3u You will have to trust me on the FLAC files because I cant upload them but they are in the same directoy as the m3u Playlist and if I open them with any media player (even Haruna) they work as expected. -- You are receiving this mail because: You are watching all bug changes.
