GNOME Bugzilla – Bug 542562
Cannot handle corrupt/incomplete files gracefully
Last modified: 2008-07-23 04:16:57 UTC
If banshee is asked to import a corrupt file, it will take a looooooong time (order of lots of minutes) and the import can't be cancelled. And in the mean time it keeps consuming 100% CPU. This specifically happens with partially downloaded media files using torrent (or any other p2p downloader). p2p downloaders create large sparse files filled mostly with zeroes. I suspect taglib-sharp or banshee itself is trying to scan the whole file in search of tags in the media file. The import should not try to scan the whole file (which can be of the order of gigabytes) but give up after reading a reasonable chunk of the file.
Created attachment 114406 [details] Example of such a partially downloaded media file Beware, the file is 300KB but expands to 220MB. Its a partially downloaded episode (mpg) of Futurama Season5 DVD RIP :-).
Reporter, could you please generate another media file that has the same effect with the file you already attach? That is, start downloading from http://www.bigbuckbunny.org/index.php/download/ and stop the download at the same level as before. This will help answer questions such as whether all sparse files mesh up Banshee, etc.
I can attach another avi file which also has the same problem. I actually didnt download the files myself; I got them from someone who told me later he had stopped downloading in the middle. (I couldnt find them on this computer so I will attach it within a day or two). If you are trying to reproduce by downloading yourself, then download some movie using torrent and stop soon after a chunk at the beginning is downloaded. I have read about this problem in several places so apparently you don't need a lot of luck to reproduce this. This is the same problem as http://bugzilla.gnome.org/show_bug.cgi?id=542562
http://cs-people/dbera/blogdata/bad.avi.bz2 Another corrupt file (avi). BTW, mplayer and midentify correctly deals with the file. E.g. mplayer is able to play the audio stream intermittently and more important, midentify quickly returns the duration, width, height, codec etc. information.
(In reply to comment #4) > http://cs-people/dbera/blogdata/bad.avi.bz2 Wrong link! http://cs-people.bu.edu/dbera/blogdata/bad.avi.bz2
Can Totem (with the GStreamer backend) play any of these corrupted files?
I have totem with gstreamer plugin and it can't play these files.
I think the general issue with these video files is that they are corrupted (missing lots of information to be played properly). Therefore, the goal is to get the player to deal with them gracefully. That is, either show whatever frames can be recovered, or display a message that the video file is corrupted. If the player crashes, this would be an indication of memory corruption, which makes it a serious bug. If the player takes long of time to figure out that the file is corrupted is also unacceptable behavior.
Ok, then this is a GStreamer bug. Moving products to reflect that and we'll see what the GStreamer folks can do with it.
Not sure what the problem here is. GStreamer handles the file "properly" for me: it tries to play the file, looks through it to see if it finds anything useful somewhere and then fails because it contains only garbage. And this happens in ~3 minutes here. Not sure what else should be done on such broken files. I'm closing this bug as such, if there's a crash with this file or gstreamer hanging forever please reopen with a backtrace :) (Also, doesn't banshee use taglib-sharp for reading the metadata when importing and only uses GStreamer for playback?) $ time gst-launch-0.10 -v playbin uri=file://`pwd`/bad.avi Setting pipeline to PAUSED ... /playbin0/decodebin0/typefind.src: caps = video/x-msvideo Pipeline is PREROLLING ... No accelerated IMDCT transform found ERROR: from element /playbin0/decodebin0/avidemux0: Could not demultiplex stream. Additional debug info: gstavidemux.c(3265): gst_avi_demux_stream_header_pull (): /playbin0/decodebin0/avidemux0: pull_range flow reading header: unexpected ERROR: pipeline doesn't want to preroll. Setting pipeline to NULL ... /playbin0/decodebin0/avidemux0.audio_00: caps = NULL /playbin0/decodebin0/avidemux0.video_00: caps = NULL /playbin0/decodebin0/typefind.src: caps = NULL FREEING pipeline ... real 3m1.109s user 1m49.551s sys 0m36.658s
(In reply to comment #10) > (Also, doesn't banshee use taglib-sharp for reading the metadata when importing > and only uses GStreamer for playback?) My original bug was directed against taglib-sharp in banshee. Since taglib-sharp is used for reading metadata, it hurts more if that takes several minutes to detect if a file is corrupt. BTW, mplayer immediately tells if the file is corrupt or is able to play whatever frames are available; it would be good is gstreamer can do that too.
I want to reopen this for banshee. Close this if any banshee developer feels this is how banshee should behave for corrupt files. The difference between banshee and gstreamer is banshee is a player/manager and the "apparent hang" happens while importing.
Can you run banshee-1 --debug from a terminal, get it to freeze, then run kill -s QUIT $(pidof banshee-1) from a different terminal? In the first terminal you should get a bunch of output (traces from every thread in Banshee). Please attach the result (or paste inline if it's not too long).
Created attachment 115019 [details] banshee thread stacktrace during importing banshee allows quitting during importing, so after I send SIGQUIT I quit banshee. The logfile contains the whole debug output and thread stacktrace.
Ok, if this is a taglib# bug (which it seem to be) you should file it here: http://forum.taglib-sharp.com/viewforum.php?f=5
(In reply to comment #15) > Ok, if this is a taglib# bug (which it seem to be) you should file it here: > http://forum.taglib-sharp.com/viewforum.php?f=5 > Done. FYI http://forum.taglib-sharp.com/viewtopic.php?f=5&t=251
OK, closing this based on previous comments. It's in Taglib-sharp's hands now.