After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 733136 - Some musics have 00:00 duration
Some musics have 00:00 duration
Status: RESOLVED FIXED
Product: tracker
Classification: Core
Component: Extractor
unspecified
Other Linux
: Normal major
: ---
Assigned To: tracker-extractor
tracker-extractor
Depends on:
Blocks:
 
 
Reported: 2014-07-13 23:09 UTC by Georges Basile Stavracas Neto
Modified: 2015-07-03 20:00 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
00:00 length music (173.24 KB, image/png)
2014-07-13 23:09 UTC, Georges Basile Stavracas Neto
  Details
extract-mp3: Return false if we find no frame headers (2.51 KB, patch)
2015-07-03 20:00 UTC, Carlos Garnacho
none Details | Review
tracker-extract: Check the return value from TrackerExtractMetadataFunc (1.76 KB, patch)
2015-07-03 20:00 UTC, Carlos Garnacho
none Details | Review

Description Georges Basile Stavracas Neto 2014-07-13 23:09:18 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.
Comment 1 Vadim Rutkovsky 2014-07-13 23:27:07 UTC
What's the output of 'tracker-info <path to this file> | grep duration'?
Comment 2 Georges Basile Stavracas Neto 2014-07-13 23:30:05 UTC
When I run this command, I have no output. In Rhythmbox, every track shows it's duration correctly.
Comment 3 Vadim Rutkovsky 2014-07-13 23:31:43 UTC
Tracker extrator seems to be unable to fetch duration for this file, changing component to tracker
Comment 4 Martyn Russell 2014-07-22 11:01:51 UTC
Hi there,

Do you have a test file I can use to fix this?
Thanks :)
Comment 5 Georges Basile Stavracas Neto 2014-07-24 16:42:59 UTC
I couldn't attach it to Bugzilla, so here it goes the dropbox link:
https://db.tt/EL87CQkr
Comment 6 Carlos Garnacho 2015-07-03 19:59:41 UTC
(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.
Comment 7 Carlos Garnacho 2015-07-03 20:00:46 UTC
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
Comment 8 Carlos Garnacho 2015-07-03 20:00:51 UTC
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.
Comment 9 Carlos Garnacho 2015-07-03 20:00:55 UTC
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.