GNOME Bugzilla – Bug 733136
Some musics have 00:00 duration
Last modified: 2015-07-03 20:00:55 UTC
Created attachment 280607 [details] 00:00 length music Some of my musics have the unbelieveble duration of 00:00. See screenshot attached. Because of this, I cannot go forward or backward the music. It would be nice to know the music duration.
What's the output of 'tracker-info <path to this file> | grep duration'?
When I run this command, I have no output. In Rhythmbox, every track shows it's duration correctly.
Tracker extrator seems to be unable to fetch duration for this file, changing component to tracker
Hi there, Do you have a test file I can use to fix this? Thanks :)
I couldn't attach it to Bugzilla, so here it goes the dropbox link: https://db.tt/EL87CQkr
(In reply to Georges Basile Stavracas Neto from comment #5) > I couldn't attach it to Bugzilla, so here it goes the dropbox link: > https://db.tt/EL87CQkr Thanks for providing the file! As far as I've seen, this is a really odd file. It actually seems to be an .asf (application/vnd.ms-asf) file, with a full blown id3 header right at the beginning of the file. The header has seemingly related info, but completely displaces all asf data (including its 30 26 B2 75 8E... magic number, expected to be at offset=0). gvfs-info/xdgmime seem to be also confused by the file (or its extension, not sure), making tracker think it's an audio/mpeg, if I rename it to .asf, it's correctly reported as application/vnd.ms-asf. I'm pushing some Tracker patches to make the mp3 extract module bail out on non-mp3 data, that'll make tracker keep trying with other modules, and the gstreamer one will successfully figure it out. As for the mimetype not being correctly identified, I'm not sure whether suggesting filing a bug to fdo's xdgmime or not... this "id3 prepended to asf" thing sounds quite nonstandard to me.
The following fixes have been pushed: 0bde8cd extract-mp3: Return false if we find no frame headers 3691969 tracker-extract: Check the return value from TrackerExtractMetadataFunc
Created attachment 306768 [details] [review] extract-mp3: Return false if we find no frame headers This means we're probably not dealing with an mp3 file, even if we thought so. This makes it possible to bail out into more generic modules (eg. gstreamer) that might catch what the file is for real.
Created attachment 306769 [details] [review] tracker-extract: Check the return value from TrackerExtractMetadataFunc Extract modules might fail mid-processing, when the TrackerSparqlBuilder has been partially written, we should bail out and move on to the next extract module, as we can't guarantee its validity.