GNOME Bugzilla – Bug 651965
Rygel Uses 100% CPU while working on an incomplete MKV file
Last modified: 2012-02-18 20:10:33 UTC
Created attachment 189288 [details] gdb info While downloading an mkv file into a directory watched by Rygel, Rygel will get into a state of using 100% of a CPU. This seems to occur while the file being downloaded is incomplete and small. It may have to do with metadata extraction. Rygel needs to be force quit to stop it from using all of one CPU. This occurs every time while downloading an mkv. But it may go away after I've killed and restarted Rygel. (Also, while using GDB, I earlier tried and failed to stop rygel with ctrl-c. But the second time I tried, ctrl-c worked, and rygel quit and I was able to get debugging traces.) I am using Ubuntu 11.04 Natty, and Rygel 0.10.1.54-ca2ac
Should be fixed once https://gitorious.org/~phako/rygel/rygel-sandbox-phako/commit/cd320089bc324500da901c2c17c8fd04bb023979 is merged.
Which it is now.
Hi, I just ran rygel with this newly merged patch and unfortunately the 100% cpu issue occurred again. BitTorrent program (transmission) was also not running at the time. However, I believe Rygel was hung up on an incomplete mkv file. So I wonder whether the metadata extractor, whilst reading in an incomplete area of the mkv, encountered some unexpected bytes, which made it error, and when propagated back up to Rygel, made it use 100% CPU? I'll try to get a debug log. The last messages from Rygel on the command line, before I killed it, were MediaExport-Message: 'file:///home/chris/Photos' harvested (rygel:25491): MediaExport-DEBUG: rygel-media-export-harvesting-task.vala:264: Scheduling file file:///home/chris/Documents/torrents/xyz.mkv for meta-data extraction… MediaExport-Message: 'file:///home/chris/Music' harvested (rygel:25491): Rygel-DEBUG: rygel-main.vala:124: New network dlink (wlan0) context available. IP: 192.168.0.101 (rygel:25491): Rygel-DEBUG: rygel-root-device-factory.vala:235: No icon provided by plugin 'MediaExport'. Using Rygel logo. (rygel:25491): Rygel-DEBUG: rygel-root-device-factory.vala:235: No icon provided by plugin 'Test'. Using Rygel logo. (rygel:25491): Rygel-DEBUG: rygel-root-device-factory.vala:235: No icon provided by plugin 'Playbin'. Using Rygel logo. MediaExport-Message: 'file:///home/chris/Videos' harvested (rygel:25491): MediaExport-DEBUG: rygel-media-export-metadata-extractor.vala:110: Extraction timed out on file:///home/chris/Documents/torrents/xyz.mkv [1]+ Killed rygel
Created attachment 189749 [details] second gdb session with 100 percent cpu A Second GDB session, when Rygel was using 100% cpu.
(In reply to comment #3) > Hi, I just ran rygel with this newly merged patch and unfortunately the 100% > cpu issue occurred again. > > BitTorrent program (transmission) was also not running at the time. However, I > believe Rygel was hung up on an incomplete mkv file. So I wonder whether the > metadata extractor, whilst reading in an incomplete area of the mkv, > encountered some unexpected bytes, which made it error, and when propagated > back up to Rygel, made it use 100% CPU? Try this: gst-launch-0.10 playbin2 uri='URI_TO_YOUR_MKV_FILE' . If this also go to 100% cpu usage and doesn't error out, this is a gstreamer bug.
Thanks Khattak, 100% cpu usage did occur with that command. I'll look into whether this issue with gstreamer has been reported before. Hopefully they will not be offput with a request to better deal with what are (temporarily) broken files. (This bug's title is already mentioned in the Rygel git log, unfortunately it could be a bit misleading.)
(In reply to comment #6) > Thanks Khattak, 100% cpu usage did occur with that command. Good. That narrows down the issue. > I'll look into whether this issue with gstreamer has been reported before. > Hopefully they will not be offput with a request to better deal with what are > (temporarily) broken files. > > (This bug's title is already mentioned in the Rygel git log, unfortunately it > could be a bit misleading.) Not really a problem. GStreamer is on the same bugzilla so I'll just change the component..
I can reproduce it. A few threads are waiting, sending EOS to a pad, which blocks.
Created attachment 193448 [details] [review] matroskademux: ensure no-more-pads is always emitted In particular, do so even if failing to read while prerolling, such as when reading from a partial file (eg, while it is being downloaded). This fixes a wedge in playbin2.
This fixes the wedge I saw in gst-launch playbin2, where playbin2 would not realize it would not see more pads.
Note that the stack trace for this is different from the one posted by the reported, so there may be two bugs. I've not seen the reporter's stack trace here using gst-launch.
Comment on attachment 193448 [details] [review] matroskademux: ensure no-more-pads is always emitted Looks good but additionally you should post an error message if no pads were added yet and a warning message otherwise (if EOS happens before the "header" state was left)
Created attachment 193518 [details] [review] matroskademux: ensure no-more-pads is always emitted In particular, do so even if failing to read while prerolling, such as when reading from a partial file (eg, while it is being downloaded). This fixes a wedge in playbin2.
Messages added.
Comment on attachment 193518 [details] [review] matroskademux: ensure no-more-pads is always emitted Is there something else to do for this bug? commit e032d2667496f6be815d5c8ac0af08510829f947 Author: Vincent Penquerc'h <vincent.penquerch@collabora.co.uk> Date: Mon Aug 8 22:14:28 2011 +0100 matroskademux: ensure no-more-pads is always emitted In particular, do so even if failing to read while prerolling, such as when reading from a partial file (eg, while it is being downloaded). This fixes a wedge in playbin2. https://bugzilla.gnome.org/show_bug.cgi?id=651965
Please feel free to reopen the bug if the problem still occurs with a newer version of GStreamer