GNOME Bugzilla – Bug 722991
Some Android 4.x (JellyBean) devices connect preferably or exclusively via MTP/PTP
Last modified: 2014-05-03 12:27:34 UTC
Created attachment 267204 [details] [review] Prototype patch in development Some Android devices e.g. Galaxy S2 i9100, running Android 4.1.2 (perhaps earlier?) prefer MTP connection mode over Mass Storage, in the best case, requiring the user to select mass storage mode on the device _before_ they connect the cable, in order for them to work as banshee expects. If we switch banshee to use Mtp support for these devices, we see: Not Working - Display tracks in browser (partial patch attached) Working - Transferring tracks - Deleting tracks - Display track information (partial) Untested - Edit track information (disabled for Mtp. This is TODO) Patch comment: The attached patch modifies the default MediaAttributes property for files found on the device. MtpTrackInfo had this as AudioStream which was then not modified, causing the files not to be displayed. I tried using a default of Music, but this did not cause the tracks to show-banshee behaved quite erratically in fact. Obviously, the patch is not ideal as Video clips show up in the Music source. But I think discussing how best to categorise the files is best since the current folder id mechanism doesn't appear to be working correctly, at least in my case.
Created attachment 267205 [details] Database excerpt Entries displayed in the Music source browser have an Attribute value of 5.
(In reply to comment #0) > Created an attachment (id=267204) [details] [review] > Prototype patch in development Sadly, with this patch, banshee still cannot see the tracks that Nexus4 has :( (In reply to comment #1) > Created an attachment (id=267205) [details] > Database excerpt > > Entries displayed in the Music source browser have an Attribute value of 5. Interesting! But I wonder why it doesn't fix it for me, how did you debug it? what traces to put in Mtp extension to show logs of each track?
(In reply to comment #2) > (In reply to comment #0) > > Created an attachment (id=267204) [details] [review] [details] [review] > > Prototype patch in development > > Sadly, with this patch, banshee still cannot see the tracks that Nexus4 has :( With the S2, I had to open the sqlite database and delete all the tracks from CoreTracks with the appropriate PrimarySourceID. Then after reconnecting, and with the patch applied, I allowed banshee a short period to re-populate the table and then tracks started showing up. However, as you've observed that's not the case with all devices, I have an S4 I can test with here too and that doesn't behave as I've described above. Also, the tracks for removable sources are supposed to be removed when banshee quits anyway, so the ones I removed on the command line probably shouldn't have been there. > (In reply to comment #1) > > Created an attachment (id=267205) [details] [details] > > Database excerpt > > > > Entries displayed in the Music source browser have an Attribute value of 5. > > Interesting! But I wonder why it doesn't fix it for me, how did you debug it? > what traces to put in Mtp extension to show logs of each track? It was actually just trial and error! In MtpTrackInfo's constructor I noticed the default Attribute value was AudioStream (1), which I thought I'd change to Music (4) and see if files started showing up in the browser. That however, didn't work at all. I was about to give up when I looked at the enum and spotted Default (5, or AudioStream | Music) so I had one last try with that value and found I could see all of the media files on my device. I just set a few break points in loadFilesFromDevice () and opened the database in a terminal window. The second attachment shows the same track reference in my main library, (PrimarySourceID = 1) the one for the Mtp device (PrimarySourceID = 8) and in mass storage mode (PrimarySourceID = 7), the key thing to notice is that in Mass Storage and the main library, the Attribute value is 5 aka Default, in the Mtp version it was 1 aka AudioStream.
*** This bug has been marked as a duplicate of bug 539804 ***
Created attachment 270589 [details] [review] Removes confusing hardware messages from GIO hardware manager Pardon the previous confusing edits... This patch is more appropriate here though the preceding commentary is a little misleading. As general support goes, fixing the two levels of messages for when a mount is removed and then when a volume is removed appears to be a much better approach to device handling. This slight change should provide excellent MTP support as the volume unmount that's needed in some cases won't cause DapService to attempt to remove the MTP source prematurely. In addition, on systems where automount is disabled we can still recognise both mtp and mass storage sources, perhaps asking the user if they want the latter mounted? In this patch I chose to simply mount the device which retains the same functionality we had before, i.e. when a mass storage device is recognised it is ready for banshee to initialise.
This looks very good, I'll review it after we release 2.9.1 (very soon now).
Nicholas, why is bug 539804 marked as a dependency of this one?
(In reply to comment #7) > Nicholas, why is bug 539804 marked as a dependency of this one? Just for resolution purposes. Since we don't support folder hierarchies on MTP devices at the moment, we'll overwrite files with the same track number and title. So full resolution of 539804 seemed like a good milestone for this one. I wasn't sure whether to actually close this one when you pointed me in the direction of 539804. Different devices, pretty much the same issue.
(In reply to comment #8) > (In reply to comment #7) > > Nicholas, why is bug 539804 marked as a dependency of this one? > > Just for resolution purposes. Since we don't support folder hierarchies on MTP > devices at the moment, we'll overwrite files with the same track number and > title. So full resolution of 539804 seemed like a good milestone for this one. > > I wasn't sure whether to actually close this one when you pointed me in the > direction of 539804. Different devices, pretty much the same issue. Well, I got confused because bug 539804 is about tracks in nested directories, and here we have a bug titled "Some android devices connect via MTP/PTP by default", and there is a patch that changes device-event-hooking. We should start being more specific when filing bugs ;) Anyway, I guess by mentioning bug 539804 you meant to make it related to the sub-item you listed in comment#0: "Not Working - Display tracks in browser (partial patch attached)". As we have committed already a patch for that for read-only support (and we have left bug 539804 for just the write-support), I'm changing the dependency then.
Closing, as too confused to the useful, and mostly superseded by 723695.