GNOME Bugzilla – Bug 670915
Banshee gets stuck reading Galaxy Nexus because of missing battery status
Last modified: 2014-02-05 19:11:51 UTC
Originally reported at: https://bugs.launchpad.net/bugs/942132 When I plug in my Galaxy Nexus phone, Banshee starts reading the files on it (this takes a while, banshee turns grey a few times). While reading, it tries to get the battery status (which is not available), and stops processing (no files are marked as being "music" either, all files are "Other"). [26 Warn 19:09:25.685] Unable to get battery level from MTP device - Mtp.LibMtpException: Could not retrieve battery stats (in `Mtp') at Mtp.MtpDevice.GetBatteryLevel (Mtp.MtpDeviceHandle handle, System.UInt16& maxLevel, System.UInt16& currentLevel) [0x0001b] in /build/buildd/banshee-2.3.5/src/Libraries/Mtp/Mtp/MtpDevice.cs:312 at Mtp.MtpDevice.get_BatteryLevel () [0x00000] in /build/buildd/banshee-2.3.5/src/Libraries/Mtp/Mtp/MtpDevice.cs:68 at Banshee.Dap.Mtp.MtpSource.DeviceInitialize (IDevice device) [0x00259] in /build/buildd/banshee-2.3.5/src/Dap/Banshee.Dap.Mtp/Banshee.Dap.Mtp/MtpSource.cs:144 ProblemType: Bug DistroRelease: Ubuntu 12.04 Package: banshee 2.3.5-1ubuntu1 ProcVersionSignature: Ubuntu 3.2.0-17.27-generic 3.2.6 Uname: Linux 3.2.0-17-generic x86_64 ApportVersion: 1.93-0ubuntu2 Architecture: amd64 Date: Mon Feb 27 19:04:58 2012 InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Alpha amd64 (20110803) ProcEnviron: TERM=xterm PATH=(custom, user) LANG=nl_NL.UTF-8 SHELL=/bin/bash SourcePackage: banshee UpgradeStatus: Upgraded to precise on 2011-12-03 (86 days ago)
This seems related to bug #664855, but this one is getting further, maybe thanks to a more recent libmtp version. I don't think the "Unable to get battery level" error is really relevant: the exception is caught and logged. Could you please try to get the full log output, as described in http://banshee.fm/contribute/file-bugs/
I get a lot of these in my kernel log: [657700.117680] usb 2-1.3.4.1: usbfs: process 15293 (banshee) did not claim interface 0 before use
Created attachment 212251 [details] The log of what happens when banshee tries to sync podcasts to my Galaxy Nexus
Created attachment 212252 [details] Log of "hanging" banshee I've made a log (banshee --debug --redirect-log) of what happens when I plug in my phone and the banshee UI freezes for a minute. I've given Banshee a SIGQUIT (to do stack dumps) several times during this process. Banshee acts the same as without the SIGQUIT.
Created attachment 268180 [details] [review] Reduces Locking granularity in LoadFromDevice Hi, are you still experiencing this issue? If it's possible for you to apply patches to banshee could you try the attached one. The last stack trace you posted seems to be caused by a failed lock on the mtp_device member, which must have been successful previously in the function. The patch just stops banshee from releasing the lock until the function completes. Thanks!
(In reply to comment #5) > The last stack trace you posted seems to be caused by a failed lock on the > mtp_device member, which must have been successful previously in the function. > The patch just stops banshee from releasing the lock until the function > completes. Nicholas, I think you misinterpreted what happened here. Look at this part of his log: "Main Thread" tid=0x0x7f5d08bba740 this=0x0x7f5d08b84ea0 thread handle 0x403 state : waiting on 0x8e3 : Sem owns () at (wrapper managed-to-native) System.Threading.Monitor.try_enter_with_atomic_var (object,int,bool&) <IL 0x0000f, 0xffffffff> at System.Threading.Monitor.TryEnter (object,int,bool&) <IL 0x00044, 0x0004f> at System.Threading.Monitor.Enter (object,bool&) <IL 0x00003, 0x00023> at Banshee.Dap.DapService.UnmapDevice (string) [0x0000d] in /build/buildd/banshee-2.4.0/src/Dap/Banshee.Dap/Banshee.Dap/DapService.cs:258 This is exactly the same we had in bug 723040, so I don't think it's related to holding the lock once/twice! Nonetheless, good find! We can mark this as duplicate then. Thanks for taking the time to report this bug. This particular bug has already been reported into our bug tracking system, but we are happy to tell you that the problem has already been fixed. It should be solved in the next software version (2.6.2). You may want to check for a software upgrade. *** This bug has been marked as a duplicate of bug 723040 ***
(In reply to comment #6) > (In reply to comment #5) > > The last stack trace you posted seems to be caused by a failed lock on the > > mtp_device member, which must have been successful previously in the function. > > The patch just stops banshee from releasing the lock until the function > > completes. > > Nicholas, I think you misinterpreted what happened here. Look at this part of > his log: > "Main Thread" tid=0x0x7f5d08bba740 this=0x0x7f5d08b84ea0 thread handle 0x403 > state : waiting on 0x8e3 : Sem owns () > at (wrapper managed-to-native) > System.Threading.Monitor.try_enter_with_atomic_var (object,int,bool&) <IL > 0x0000f, 0xffffffff> > at System.Threading.Monitor.TryEnter (object,int,bool&) <IL 0x00044, 0x0004f> > at System.Threading.Monitor.Enter (object,bool&) <IL 0x00003, 0x00023> > at Banshee.Dap.DapService.UnmapDevice (string) [0x0000d] in > /build/buildd/banshee-2.4.0/src/Dap/Banshee.Dap/Banshee.Dap/DapService.cs:258 > > This is exactly the same we had in bug 723040, so I don't think it's related to > holding the lock once/twice! > > Nonetheless, good find! We can mark this as duplicate then. > Indeed, you're right. However, in the thread running LoadFromDevice, we were using the mtp_device but then it was disposed by Unmap between lock statements. It would be really nice if we could stop any running tasks for a given device before attempting the Unmap.
(In reply to comment #7) > ... > However, in the thread running LoadFromDevice, we were using the mtp_device but > then it was disposed by Unmap between lock statements. It would be really nice > if we could stop any running tasks for a given device before attempting the > Unmap. Indeed, and I already fixed that here :) : https://git.gnome.org/browse/banshee/commit/?id=37cb8a36f0a5884936fde0c84e7a9da87d19794a