GNOME Bugzilla – Bug 731195
video: handle images that have bytes size above 2^31
Last modified: 2014-06-20 01:50:58 UTC
Either gnome-music in fedora 20 + gnome 3.12 copr or gnome-music master show emty views for albums and artists. The songs view is filled, but with unknown album/unknown artist. tracker-1.0.1-1.fc20.x86_64 grilo-plugins-0.2.12-3.fc20.x86_64 grilo-0.2.10-1.fc20.x86_64 gnome-music-3.12.2.1-1.fc20.x86_64 LANG="fr_FR.utf8" Console warnings running gnome-music master: ./gnome-music Running from source tree, using local files (gnome-music:9244): GLib-GIO-CRITICAL **: g_file_get_parent: assertion 'G_IS_FILE (file)' failed (gnome-music:9244): GLib-GIO-CRITICAL **: g_file_get_parent: assertion 'G_IS_FILE (file)' failed (gnome-music:9244): GLib-GIO-CRITICAL **: g_file_get_parent: assertion 'G_IS_FILE (file)' failed (gnome-music:9244): Grilo-WARNING **: [upnp] grl-upnp.c:359: Failed to execute GetSearchCaps operation (gnome-music:9244): Grilo-WARNING **: [upnp] grl-upnp.c:361: Reason: Access denied (gnome-music:9244): Grilo-WARNING **: [upnp] grl-upnp.c:359: Failed to execute GetSearchCaps operation (gnome-music:9244): Grilo-WARNING **: [upnp] grl-upnp.c:361: Reason: Access denied (gnome-music:9244): GLib-GIO-CRITICAL **: g_file_get_parent: assertion 'G_IS_FILE (file)' failed (gnome-music:9244): Grilo-WARNING **: [upnp] grl-upnp.c:359: Failed to execute GetSearchCaps operation (gnome-music:9244): Grilo-WARNING **: [upnp] grl-upnp.c:361: Reason: Access denied (gnome-music:9244): GLib-GIO-CRITICAL **: g_file_get_parent: assertion 'G_IS_FILE (file)' failed (gnome-music:9244): GLib-GIO-CRITICAL **: g_file_get_parent: assertion 'G_IS_FILE (file)' failed (gnome-music:9244): GLib-GIO-CRITICAL **: g_file_get_parent: assertion 'G_IS_FILE (file)' failed (gnome-music:9244): GLib-GIO-CRITICAL **: g_file_get_parent: assertion 'G_IS_FILE (file)' failed (gnome-music:9244): GLib-GIO-CRITICAL **: g_file_get_parent: assertion 'G_IS_FILE (file)' failed (gnome-music:9244): GLib-GIO-CRITICAL **: g_file_get_parent: assertion 'G_IS_FILE (file)' failed (gnome-music:9244): GLib-GIO-CRITICAL **: g_file_get_parent: assertion 'G_IS_FILE (file)' failed (gnome-music:9244): GLib-GIO-CRITICAL **: g_file_get_parent: assertion 'G_IS_FILE (file)' failed
Please attach the output of 'gnome-music -d' to get more details
Created attachment 277870 [details] Debug output
Which libmediaart version do you have? It seems to throw odd errors when we're trying to add 'Unknown Artist' Tracker also read all your mp3 as 'Unknown Artist', could you try rescanning your collection?
(In reply to comment #3) > Which libmediaart version do you have? It seems to throw odd errors when we're > trying to add 'Unknown Artist' libmediaart-0.4.0-1.fc20.x86_64 > Tracker also read all your mp3 as 'Unknown Artist', could you try rescanning > your collection? How ?
(In reply to comment #4) > > Tracker also read all your mp3 as 'Unknown Artist', could you try rescanning > > your collection? > > How ? tracker-control --backup FILENAME tracker-control --hard-reset tracker-control --start tracker-control --restore FILENAME
Here is the new debug output after a rescan. Bug is still there.
Created attachment 277997 [details] Debug output
I'm not sure it will help, but here's a part of the output of tracker-control -F: LANG=C tracker-control -F Store: 06 juin 2014, 09:39:18: ? Store - Idle Miners: 06 juin 2014, 09:39:18: ? File System - Idle 06 juin 2014, 09:39:18: ? Extractor - Not running or is a disabled plugin 06 juin 2014, 09:39:18: ? Applications - Idle Press Ctrl+C to end follow of Tracker state 06 juin 2014, 09:44:33: ? File System - Processing? 06 juin 2014, 09:44:33: ? File System - Idle 06 juin 2014, 09:44:33: 0% Extractor - Extracting metadata 06 juin 2014, 09:44:35: 1% Extractor - Extracting metadata 06 juin 2014, 09:44:35: 2% Extractor - Extracting metadata 08m 45s remaining 06 juin 2014, 09:44:35: 3% Extractor - Extracting metadata 05m 08s remaining 06 juin 2014, 09:45:01: 0% Extractor - Extracting metadata 06 juin 2014, 09:46:50: 0% Extractor - Extracting metadata 06 juin 2014, 09:46:50: ? File System - Processing? 06 juin 2014, 09:46:50: ? File System - Idle 06 juin 2014, 09:47:07: 0% Extractor - Extracting metadata 06 juin 2014, 09:48:10: 0% Extractor - Extracting metadata 06 juin 2014, 09:48:10: ? File System - Processing? 06 juin 2014, 09:48:10: ? File System - Idle 06 juin 2014, 09:48:27: 0% Extractor - Extracting metadata 06 juin 2014, 09:57:26: 0% Extractor - Extracting metadata 06 juin 2014, 09:57:26: ? File System - Processing? 06 juin 2014, 09:57:26: ? File System - Idle 06 juin 2014, 09:57:43: 0% Extractor - Extracting metadata 06 juin 2014, 10:00:27: 0% Extractor - Extracting metadata 06 juin 2014, 10:00:27: ? File System - Processing? 06 juin 2014, 10:00:27: ? File System - Idle 06 juin 2014, 10:00:44: 0% Extractor - Extracting metadata 06 juin 2014, 10:04:27: 0% Extractor - Extracting metadata 06 juin 2014, 10:04:27: ? File System - Processing? 06 juin 2014, 10:04:27: ? File System - Idle 06 juin 2014, 10:04:44: 0% Extractor - Extracting metadata
What's the output of "tracker-info <any file>" e.g. "tracker file:///home/pacaud/Musique/La%20Rue%20K%C3%A9tanou%20-%20Ouvert%20a%20Double%20Tour/La%20Rue%20Ketanou%20-%20Ouvert%20a%20Double%20Tour%20-%2013%20-%20Ma%20Faute%20A%20Toi.mp3"?
$ tracker-info file:///home/pacaud/Musique/La%20Rue%20K%C3%A9tanou%20-%20Ouvert%20a%20Double%20Tour/La%20Rue%20Ketanou%20-%20Ouvert%20a%20Double%20Tour%20-%2013%20-%20Ma%20Faute%20A%20Toi.mp3 Demande d'information sur l'entité:'file:///home/pacaud/Musique/La%20Rue%20K%C3%A9tanou%20-%20Ouvert%20a%20Double%20Tour/La%20Rue%20Ketanou%20-%20Ouvert%20a%20Double%20Tour%20-%2013%20-%20Ma%20Faute%20A%20Toi.mp3' 'urn:uuid:1fc8f793-084e-33c1-fa9d-5b0004bf24ef' Résultats: 'http://purl.org/dc/elements/1.1/date' = '2010-08-19T13:35:53Z' 'http://purl.org/dc/elements/1.1/date' = '2014-06-04T08:20:24Z' 'http://purl.org/dc/elements/1.1/source' = 'urn:nepomuk:datasource:9291a450-1d49-11de-8c30-0800200c9a66' 'tracker:added' = '2014-06-04T14:15:34Z' 'tracker:modified' = '1015' 'rdf:type' = 'http://www.w3.org/2000/01/rdf-schema#Resource' 'rdf:type' = 'http://www.semanticdesktop.org/ontologies/2007/01/19/nie#DataObject' 'rdf:type' = 'http://www.semanticdesktop.org/ontologies/2007/01/19/nie#InformationElement' 'rdf:type' = 'http://www.semanticdesktop.org/ontologies/2007/03/22/nfo#FileDataObject' 'rdf:type' = 'http://www.semanticdesktop.org/ontologies/2007/03/22/nfo#Media' 'rdf:type' = 'http://www.semanticdesktop.org/ontologies/2007/03/22/nfo#Audio' 'rdf:type' = 'http://www.tracker-project.org/temp/nmm#MusicPiece' 'nie:byteSize' = '10442817' 'nie:dataSource' = 'urn:nepomuk:datasource:9291a450-1d49-11de-8c30-0800200c9a66' 'nie:isPartOf' = 'urn:uuid:e31e0ba9-9f95-2d96-53a9-c3f58b520089' 'nie:url' = 'file:///home/pacaud/Musique/La%20Rue%20K%C3%A9tanou%20-%20Ouvert%20a%20Double%20Tour/La%20Rue%20Ketanou%20-%20Ouvert%20a%20Double%20Tour%20-%2013%20-%20Ma%20Faute%20A%20Toi.mp3' 'nfo:belongsToContainer' = 'urn:uuid:e31e0ba9-9f95-2d96-53a9-c3f58b520089' 'tracker:available' = 'true' 'nie:isStoredAs' = 'urn:uuid:1fc8f793-084e-33c1-fa9d-5b0004bf24ef' 'nie:mimeType' = 'audio/mpeg' 'nfo:fileLastAccessed' = '2014-06-04T08:20:24Z' 'nfo:fileLastModified' = '2010-08-19T13:35:53Z' 'nfo:fileName' = 'La Rue Ketanou - Ouvert a Double Tour - 13 - Ma Faute A Toi.mp3' 'nfo:fileSize' = '10442817'
As tracker doesn't detect 'artist' and 'album' for this file, there's nothing gnome-music can do, reassigning
Indeed. It looks like tracker-extract was crashing on a file in my documents: (gdb) run Starting program: /usr/libexec/tracker-extract gobject.pyc: gdb was not built with custom backtrace support, disabling. [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". [New Thread 0x7ffff1800700 (LWP 23706)] [New Thread 0x7ffff0b64700 (LWP 23707)] [New Thread 0x7fffebfff700 (LWP 23708)] [New Thread 0x7fffeb7fe700 (LWP 23709)] [New Thread 0x7fffeaffd700 (LWP 23710)] [New Thread 0x7fffea7fc700 (LWP 23711)] [New Thread 0x7fffe9ffb700 (LWP 23712)] [New Thread 0x7fffe97fa700 (LWP 23713)] [New Thread 0x7fffe8ff9700 (LWP 23714)] [New Thread 0x7fffdffff700 (LWP 23715)] [New Thread 0x7fffdf7fe700 (LWP 23716)] [New Thread 0x7fffdeffd700 (LWP 23717)] [New Thread 0x7fffde7fc700 (LWP 23718)] [New Thread 0x7fffddffb700 (LWP 23719)] libmediaart-Message: Initializing Storage... libmediaart-Message: Mount monitors set up for to watch for added, removed and pre-unmounts... libmediaart-Message: No mounts found to iterate Syntax Warning: May not be a PDF file (continuing anyway) Syntax Error: Couldn't find trailer dictionary Syntax Error: Couldn't read xref table (tracker-extract:23702): Tracker-WARNING **: Couldn't create PopplerDocument from uri:'file:///home/pacaud/Documents/Perso/V%C3%A9lo/Rose-VPC%20-%202012%2006%2005%20-%20Explication%20retour%20poign%C3%A9es.pdf', PDF document is damaged (tracker-extract:23702): Tracker-WARNING **: Task for 'file:///home/pacaud/Documents/Perso/V%C3%A9lo/Rose-VPC%20-%202012%2006%2005%20-%20Explication%20retour%20poign%C3%A9es.pdf' finished with error: Could not get any metadata for uri:'file:///home/pacaud/Documents/Perso/V%C3%A9lo/Rose-VPC%20-%202012%2006%2005%20-%20Explication%20retour%20poign%C3%A9es.pdf' and mime:'application/pdf' [New Thread 0x7fffd7fff700 (LWP 23720)] (tracker-extract:23702): Tracker-WARNING **: Call to gst_discoverer_discover_uri() failed: Il manque un greffon dans votre installation de GStreamer. (tracker-extract:23702): Tracker-WARNING **: Task for 'file:///home/pacaud/Documents/Perso/Musique/Ukul%C3%A9l%C3%A9%20-%20Brassons%20-%20Les%20copains%20d'abord.mid' finished with error: Could not get any metadata for uri:'file:///home/pacaud/Documents/Perso/Musique/Ukul%C3%A9l%C3%A9%20-%20Brassons%20-%20Les%20copains%20d'abord.mid' and mime:'audio/midi' (tracker-extract:23702): GLib-ERROR **: gmem.c:103: failed to allocate 18446744071909384471 bytes Program received signal SIGTRAP, Trace/breakpoint trap.
+ Trace 233674
Thread 140736817264384 (LWP 23720)
Created attachment 278058 [details] The suspected file
Reassigning to GStreamer, it's clearly an SVG extraction issue in there. The size being attempted is massive: ...
+ Trace 233680
...
While I agree gstreamer should be fixed to not crash on this file, I think tracker-extract should be made more robust in order to still properly work even when the library used for data extraction crashes. In a user data collection, there will always be bugs or malformed files that will make those libraries crash.
(In reply to comment #15) > While I agree gstreamer should be fixed to not crash on this file, I think > tracker-extract should be made more robust in order to still properly work even > when the library used for data extraction crashes. I don't see how? > In a user data collection, there will always be bugs or malformed files that > will make those libraries crash. I am happy to take suggestions here. The tracker-extract process is separate because there is no real way to do what you suggest AFAICS. We always expect crashes/issues with tracker-extract because we can't know how 3rd party libraries will react to content. We have memory barriers in place right now and other measures too. Did you have something specific in mind?
One possibility would be to use a blacklist mechanism. If a crash happen in tracker-extract, on the following start, it would detect the last file was not properly processed, and store it in a blacklist. Each blacklist entry could be timestamped, in order to retry the indexation later.
(In reply to comment #17) > One possibility would be to use a blacklist mechanism. If a crash happen in > tracker-extract, on the following start, it would detect the last file was not > properly processed, and store it in a blacklist. Each blacklist entry could be > timestamped, in order to retry the indexation later. We're in the process of working on that actually. I thought you meant specifically in tracker-extract itself for first case situations :)
The svg seems to be rather large and is pushing some limits inside gstreamer. Will look into this.
commit 320293836958af73cbfae53741b428930c2fe31d Author: Thiago Santos <ts.santos@sisa.samsung.com> Date: Mon Jun 9 21:05:00 2014 -0300 videoscale: vs_image: strides are a gsize The strides that are set from the GstVideoInfo structs are a gsize. Using an int can cause overflows when dealing with large enough images https://bugzilla.gnome.org/show_bug.cgi?id=731195 commit fb3a9d1bc5f4f40957a58d7cad7ca77242e2a73f Author: Thiago Santos <ts.santos@sisa.samsung.com> Date: Mon Jun 9 19:44:56 2014 -0300 video: avoid overflows when doing int operations for size size is a gsize, so cast the operands to it to avoid overflows and setting wrong value to the video size. Includes tests. https://bugzilla.gnome.org/show_bug.cgi?id=731195
Also available in the 1.2 stable branch, will be released in stable 1.2.5 and the unstable 1.3.3 releases. Thanks for reporting. commit 4c31880bf0a4b720ab90fc8753fbbcc72275d6f8 Author: Thiago Santos <ts.santos@sisa.samsung.com> Date: Mon Jun 9 21:05:00 2014 -0300 videoscale: vs_image: strides are a gsize The strides that are set from the GstVideoInfo structs are a gsize. Using an int can cause overflows when dealing with large enough images https://bugzilla.gnome.org/show_bug.cgi?id=731195 commit b29adbaeaa78f642a1ade2ed83c38b8e8008d10d Author: Thiago Santos <ts.santos@sisa.samsung.com> Date: Mon Jun 9 19:44:56 2014 -0300 video: avoid overflows when doing int operations for size size is a gsize, so cast the operands to it to avoid overflows and setting wrong value to the video size. Includes tests. https://bugzilla.gnome.org/show_bug.cgi?id=731195
*** Bug 690679 has been marked as a duplicate of this bug. ***