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 703747 - GStreamer extractor doesn't properly extract media art
GStreamer extractor doesn't properly extract media art
Status: RESOLVED FIXED
Product: tracker
Classification: Core
Component: Extractor
unspecified
Other All
: Normal normal
: ---
Assigned To: tracker-extractor
Depends on:
Blocks:
 
 
Reported: 2013-07-07 16:35 UTC by Arnel Borja
Modified: 2013-07-11 18:06 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
tracker-extract-gstreamer: Get media art image type from sample info (2.75 KB, patch)
2013-07-07 16:35 UTC, Arnel Borja
committed Details | Review

Description Arnel Borja 2013-07-07 16:35:01 UTC
The media art image type is taken from the caps of the sample, which is
incorrect according to GStreamer's documentation. We are supposed to get the
media type from the extra information of the sample and not from the caps.

Because of this, getting the "image-type" field from the caps fails, and the
code doesn't check if this fails, leaving the variable "type" uninitialized.
So, if you're lucky enough, type will have the value "0", and the if block next
to it will work.

To fix this, we should get the "image-type" field from the extra information
for the sample, then ensure if this succeeds.

I attached a patch that do this. I also moved the caps inside the if block so
that it won't be unnecessarily retrieved if the image-type fails.

The patch was tested in Fedora 19 and openSUSE 12.3.
Comment 1 Arnel Borja 2013-07-07 16:35:05 UTC
Created attachment 248552 [details] [review]
tracker-extract-gstreamer: Get media art image type from sample info

Instead of getting the "image-type" field from the caps of the sample, get
it from the structure for extra information of the sample. Check also that
the field does exists, skipping the sample if it doesn't.
Comment 2 Martyn Russell 2013-07-11 18:06:18 UTC
Great patch, seems to work when I tested it thanks! :)

This problem has been fixed in the development version.
The fix will be available in the next major software release 0.17.0 
The fix will go into the next software release 0.16.2.
Thank you for your bug report.