https://bugs.kde.org/show_bug.cgi?id=523043
Pablo <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pablosantangelo2001@hotmail | |.com --- Comment #17 from Pablo <[email protected]> --- Same symptom here, and I think I can supply the root cause: this is not a Haruna bug in the resume logic itself, it is bug 522678 (frameworks-kfilemetadata) surfacing through Haruna. System: Arch Linux, Haruna 1.8.1, KDE Frameworks 6.27.0, shared-mime-info 2.5.1. The chain: 1. MpvItem::loadTimePosition() (src/mpv/mpvitem.cpp:779) needs the file duration before it will look up the saved position. When the playlist item has no duration yet, it falls back to KFileMetaData, using MiscUtils::mimeType(m_currentUrl), which is KFileItem::mimetype(). 2. On shared-mime-info 2.5.1, that returns the canonical name "video/matroska" for .mkv files. "video/x-matroska" is now only an alias of it (/usr/share/mime/aliases: "video/x-matroska video/matroska"). 3. FFmpegExtractor still declares only "video/x-matroska" (src/extractors/ffmpegextractor.cpp), and ExtractorCollection::fetchExtractors() (src/extractorcollection.cpp:161) does not resolve aliases: it does a literal string lookup in the mimetype -> extractor hash, and its only fallback walks QMimeType::allAncestors(). For "video/matroska" those ancestors are "application/x-matroska" (and application/octet-stream, which is skipped), neither of which any extractor declares. So no extractor is returned. 4. With no extractor, duration stays 0, and the guard at src/mpv/mpvitem.cpp:800 hits: if (m_currentUrl.isLocalFile() && duration < PlaybackSettings::minDurationToSavePosition() * 60) { return 0; } 0 < 60 is true, so it returns 0 without ever querying the database. The position is never restored. Saving is unaffected because saveTimePosition() (src/mpv/mpvitem.cpp:769) uses mpv's own duration() property, which is always correct. That is exactly why the position is present in the database but never used. Direct evidence with kfilemetadata_dump6, the same tool used in bug 522678. For the .mkv, no extractor matches at all and no duration is produced: $ kfilemetadata_dump6 -f some-episode.mkv some-episode.mkv video/matroska That is the entire output. No FFMpegExtractor, no properties. The same command on an .mp4 in the same directory does match, and does produce a duration: $ kfilemetadata_dump6 -f some-movie.mp4 some-movie.mp4 video/mp4 FFMpegExtractor For video/mp2t [...] video/x-matroska [...] Types: Video Duration: 6874 (int) [...] Note that the extractor's own advertised list, printed there, contains "video/x-matroska" while the file it just refused to handle was reported as "video/matroska". The end-to-end effect in Haruna, reading org.mpris.MediaPlayer2.Player.Position a few seconds after opening: .mp4 -> saved position 6108.375 s, playback started at 6118 s. Restores. .mkv -> saved position 612.612 s, playback started at 0 s. Does not restore. In both cases the position was present and correct in Haruna's database (~/.local/share/haruna/haruna.db, table playback_position) before opening. This also explains the reported workaround of setting the minimum duration to 0: it makes the comparison "duration < 0" false, so the guard stops discarding the lookup and Haruna queries the database directly. It does not fix the duration detection, it just stops the broken duration from mattering. Cross-references: - Bug 522678 "KFileMetadata MIME type issue for *.mkv files" is the same root cause, reported against Dolphin not showing video metadata for mkv. - kfilemetadata MR 227 adds "video/matroska" to FFmpegExtractor's list, which would fix this specific case. As of today it is still open and not merged, and neither master's ffmpegextractor.cpp nor master's fetchExtractors() has changed. Two things worth considering on the Haruna side regardless of what happens in kfilemetadata: - The narrow fix in MR 227 only covers matroska. Any other mimetype that shared-mime-info renames, with the old name left as an alias, will silently reintroduce this. Alias resolution in fetchExtractors() would be the general fix. - Haruna could avoid depending on the outcome entirely: when the duration lookup fails and returns 0, treating that as "unknown" rather than as "shorter than the threshold" would let the database lookup proceed. As written, a failed duration detection is indistinguishable from a genuinely short file, and the failure is silent. Disclosure: I used Claude Code to help investigate this and draft this comment. Everything above was reproduced and verified on my own machine - the kfilemetadata_dump6 output, the MPRIS position readings, and the source line references against the v1.8.1 and v6.27.0 tags. -- You are receiving this mail because: You are watching all bug changes.
