GNOME Bugzilla – Bug 631207
[PATCH] Banshee uses 100% of CPU attempting to write metadata to files on DAP devices while loading
Last modified: 2011-02-23 14:56:46 UTC
I upgraded to version 1.8.0 a couple days ago, and it was working fine. Today I closed Banshee, and later started it again. Upon starting, Banshee is sucking up 100% of my CPU. It's the #1-listed process in both top and iotop. It has a little spinner spinning down in its lefthand-corner, but this is useless since it doesn't say what it's doing, doesn't respond to clicks, etc. Obviously Banshee is doing something but I have no way to know what. I thought it might be the "Library Watcher" extension, but I disabled that and it makes no difference.
If you mouseover the spinning thing in the corner, a tooltip should tell you what Banshee's up to. If you have the mirage or BPM extensions enabled, I believe that these both run a one-time, fairly CPU-intensive analysis of your music library, so that could be the cause of it.
Can you please attach a log from a debug run banshee-1 --debug --redirect-log will produce one which is located in ~/.config/banshee-1/log
No, there is no tooltip when I mouseover the spinner. It gives no indication whatsoever of what it is doing. I'm doing a debug run now. I'll attach the log when the spinner stops, which I think took about half an hour last time.
I don't understand from the description if Banshee recovers from this or it hangs. If it hangs please follow the instructions on www.banshee.fm/file-bugs
Created attachment 171863 [details] Banshee debug log, zipped because it was 5 MB as text I've attached the debug log. Banshee doesn't hang, it just bogs my system down for the ~11 minutes that it's using 100% of the CPU. It appears that Banshee is scanning my entire iPhone library, every single time I launch Banshee; it takes that same ~11 minutes every time.
That sounds like it might be an SQL query issue, can you also try to do a run with: banshee-1 --debug --debug-sql --redirect-log This will be very verbose and if bugzilla dislikes the size please upload to someplace like omploader.org
Created attachment 172060 [details] Banshee SQL debug log
Thank you for the logs. You get a gio-sharp error on what looks like every single track on the iṔhone. I don't know if that is the cause but cleaning this up would at least make the log readable. I skimmed the SQL log and I can't spot any long queries so that does not seem to be the cause either. [7 Debug 18:05:44.762] Saving metadata for Freelance Whales - The Great Estates (on Digitalis Vol 2) <00:04:02.9640000> [file:///home/myuser/.gvfs/My%20iPhone/iTunes_Control/Music/F35/CXLY.mp3] [7 Debug 18:05:44.780] Encountered a problem processing: file:///home/myuser/.gvfs/My%20iPhone/iTunes_Control/Music/F35/CXLY.mp3 [7 Warn 18:05:44.780] Caught an exception - GLib.GException: Operation not supported by backend (in `gio-sharp') at GLib.FileInputStream.QueryInfo (System.String attributes, GLib.Cancellable cancellable) [0x00000] at GLib.GioStream.get_Length () [0x00000] at TagLib.File.get_Length () [0x00000] at TagLib.Id3v2.Tag..ctor (TagLib.File file, Int64 position) [0x00000] at TagLib.NonContainer.StartTag.ReadTag (System.Int64& start) [0x00000] at TagLib.NonContainer.StartTag.Read () [0x00000] at TagLib.NonContainer.Tag.ReadStart () [0x00000] at TagLib.NonContainer.File.Read (ReadStyle propertiesStyle) [0x00000] at TagLib.NonContainer.File..ctor (IFileAbstraction abstraction, ReadStyle propertiesStyle) [0x00000] at TagLib.Mpeg.AudioFile..ctor (IFileAbstraction abstraction, ReadStyle propertiesStyle) [0x00000] at (wrapper managed-to-native) System.Reflection.MonoCMethod:InternalInvoke (object,object[],System.Exception&) at System.Reflection.MonoCMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] However I wonder if it is correct that Saving metadata to the files should apply to files on a DAP? Regardless, this doesn't have an obvious cause, further investigation seems to be required. Since this is Apple device related Alan wins first pick at sharing his thoughts.
Uh... are you saying that Banshee is trying to MODIFY the files on my iPhone -- every single one of them -- not only without my permission, but without so much as telling me about it? Why in the world would it do that?? If that's indeed what it's doing, I assume it's a bug? DAP or not, Banshee should not be trying to write metadata to one of my audio files unless I've used Banshee to right-click on that file and modify its metadata.
You clearly enabled Write metadata to files in the preferences. It is off by default and the log seems to indicate that it is on. Banshee is doing what you asked it to, however since you should already be writing said data to your files on disk, when we put them on the iPhone I wonder why it is then writing the same metadata to files on the iPhone is kinda strange. Should this data not already be in the files when we copied them there.. Regardless the issue needs more examination than I am capable of providing. My self assigned job is mainly to ensure that simple issues are identified, logs requested and such. All the usual candidates seem to have been ruled out. Time for consulting the more knowledgeable developers.
> You clearly enabled Write metadata to files in the > preferences. It is off by default and the log seems > to indicate that it is on. Banshee is doing what you > asked it to Wow, I seriously hope that is not the case. The obvious and logical reading of "Write metadata to files" is "when I use Banshee to change a song's metadata, write that metadata back into the song file, as opposed to just storing it in some kind of Banshee database." I can't imagine any reasonable person enabling a feature called "Write metadata to files" with the expectation that it would cause Banshee to automatically scan all newly-attached volumes and attempt to write metadata into every single media file on that device. What could it possibly be writing? Where is it getting the metadata? > Should this data not already be in the files when we > copied them there.. Banshee didn't copy them there. My iPhone is synced with a Mac mini; I only connect it to my Linux system for charging. I never asked Banshee to do anything at all to my iPhone, which is all the more reason it's appalling that Banshee is evidently trying to modify every single audio file on the iPhone.
Hey guys, I've also noticed the Metadata Writing operation for every file on the iPod when it's connected, and I think it's a bug introduced by the patches that were committed to implement the feature on bug 589196. I'm going to try to fix this bug in the following days but I cannot guarantee that the fix of this symptom will make the original issue go away. Thanks for reporting though.
I think I'll find time this weekend to fix what is mentioned in comment#12.
Any update on this?
So sorry about the delay but it turns out I got new hardware (a brand new netbook) and for it to work I had to install Ubuntu 10.10, which comes without hal, so I had to switch to use the AppleDevice extension instead of the iPodSharp one, and unfortunately it doesn't work for me because of bug 637202 and bug 634652. I hope I can debug or get help soon on them so I can resume work on this.
Created attachment 176634 [details] [review] Don't add a metadata sync job for removable sources.
Applies, survives a sync cycle and does not exhibit the metadata sync behavior.
Comment on attachment 176634 [details] [review] Don't add a metadata sync job for removable sources. Hey! I appreciate any help on this thanks! However: (In reply to comment #17) > ...and does not exhibit the metadata sync behavior. Exactly as David says, with this patch you break the metadata sync behaviour that I developed in bug 589196. Take in account the sync of metadata occurs in 2 ways: a) Sync the metadata to the device's DB. b) Sync the metadata to the file. And you broke (b) with this. (b) is useful, for example if you copy your files from your device to a computer again, and want to preserve the metadata changes you did. I have a patch done that has a different approach to fix this, but because of my recent problems when switching OSs I couldn't test it properly yet. I'll post it ASAP.
Created attachment 176679 [details] [review] Different approach, with explanation included Finally I could test this patch, and it works for me.
applies, compiles and I am not seeing Banshee write metadata to files on my Galaxy S when I insert it. Seems to work.
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.