https://bugs.kde.org/show_bug.cgi?id=522678
Pablo <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pablosantangelo2001@hotmail | |.com --- Comment #4 from Pablo <[email protected]> --- Another consumer affected by this, in case it helps justify a broader fix: Haruna does not restore the playback position of .mkv files, tracked as bug 523043. The cause is the same one described here. Haruna's MpvItem::loadTimePosition() asks KFileMetaData for the file duration before it will look up the saved position. fetchExtractors() is called with "video/matroska", finds nothing because FFmpegExtractor declares only "video/x-matroska", the duration stays 0, and Haruna concludes the file is shorter than its minimum-duration threshold and skips the lookup. The position is in its database the whole time, it is just never read. .mp4 files, whose canonical mimetype is declared verbatim, restore correctly on the same machine. System: Arch Linux, KDE Frameworks 6.27.0, shared-mime-info 2.5.1, Haruna 1.8.1. Confirming your kfilemetadata_dump6 finding on an independent system: for a .mkv the tool prints the path and "video/matroska" and nothing else, with no extractor matched and no properties at all, while an .mp4 in the same directory matches FFMpegExtractor and yields a duration. The extractor list printed for the .mp4 contains "video/x-matroska", which is precisely the name the .mkv is no longer reported as. On MR 227: adding "video/matroska" to FFmpegExtractor's list fixes matroska, but the underlying behaviour is more general. ExtractorCollection::fetchExtractors() (src/extractorcollection.cpp:161) does a literal string lookup and then falls back only to QMimeType::allAncestors(). Aliases are never consulted, and an alias is not an ancestor: for "video/matroska", allAncestors() gives "application/x-matroska" and "application/octet-stream", so the fallback cannot find the plugin either. That means every future shared-mime-info rename that leaves the old name as an alias will silently break the corresponding extractor, one mimetype at a time, with no error, just missing metadata. Resolving the alias in fetchExtractors() (for example, mapping the query through QMimeDatabase::mimeTypeForName() and also probing the resolved name and its aliases) would close the whole class instead of this one instance. Disclosure: I used Claude Code to help investigate this and draft this comment. The observations above were reproduced and verified on my own machine - the kfilemetadata_dump6 output for both file types, Haruna's behaviour, and the source references against the v6.27.0 and Haruna v1.8.1 tags. The suggestion about resolving aliases in fetchExtractors() is just that, a suggestion; I have not implemented or tested it, and you are far better placed than I am to judge whether it is the right shape for a fix. -- You are receiving this mail because: You are watching all bug changes.
