GNOME Bugzilla – Bug 542582
beagle-helper hangs with 100% cpu on incomplete mpeg files
Last modified: 2018-07-03 09:51:38 UTC
Please describe the problem: When beagled is using its internal "FilterVideo" filter, it frequently gets stuck in an infinite loop when processing mpeg video files. Normally you don't run into this problem because the "FilterMPlayerVideo" is usually used, but if mplayer is not installed on the system, then it falls back to "FilterVideo", and hangs. Steps to reproduce: 1. Remove mplayer from your system (or temporarily disable it) 2. Put a corrupt .mpeg video file in the directory beagle is indexing 3. Let beagled start indexing You can also reproduce this running beagle-extract-content on the corrupt file Actual results: beagled-helper hangs trying to filter the corrupt mpeg file, using 100% cpu indefinitely. This prevents beagle from indexing any further, because it is stuck on this file. If I remove the corrupt file, shutdown, and restart beagled, then it will proceed until it runs into the next corrupt file. Expected results: beagled-helper should give up processing the file once it can't find the information it is looking for (width and height I assume) Does this happen every time? This happens every time for corrupt or incomplete mpeg files Other information: The problem is an infinite loop in Filters/TagLib/Mpeg/File.cs ReadVideoPacket function Here is a version of that function which prevents the infinite loop: void ReadVideoPacket (ref long position) { Seek (position + 4); int length = ReadBlock (2).ToUShort (); long offset = position + 6; // Put a sanity limit on how long we search int sanity_limit = 1000; int i=0; while (!video_found && (i < sanity_limit) && offset < position + length) { if (FindMarker (ref offset) == Marker.VideoSyncPacket) { video_header = new VideoHeader (this, offset + 4); video_found = true; } else { // Make sure we keep moving forward, because this one didn't match offset += 4; } i++; } position += length; }
Yes. Thanks for reporting this. I came to know this problem recently. I was not able to reach TagLib# author. Yesterday I also filed a bug with banshee because they too have the same problem. BTW, I dont think there is any "infinite loop". Its just that the whole file is read byte-by-byte. We have dropped our copy of taglib-sharp and instead depend on an external taglib-sharp.dll packaged library. So we cannot fix this in beagle the way you describe above. Moreover this problem exists in (almost) all their file readers - they keep reading till the marker is found. Taglib-sharp almost certainly needs to handle corrupt files better. If you can hunt down taglib-sharp bugzilla and file a bug there, that will be extremely useful. I couldn't find any active taglib-sharp bugzilla. I will keep this open till the taglib-sharp problem is solved or we find a correct workaround in beagle.
Beagle is not under active development anymore and had its last code changes in early 2011. Its codebase has been archived (see bug 796735): https://gitlab.gnome.org/Archive/beagle/commits/master "tracker" is an available alternative. Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is deprecated) if anyone takes the responsibility for active development again.