I had unmasked and installed libmtp-0.3.0 and upgraded to banshee-1.2.0. Trying to access my mtp device made banshee crash. downgrading _and_ recompiling banshee made it work correctly again. (I know I should provide a backtrace, but i'm leaving for holydays and have no time :) ) Reproducible: Always
Banshee is part of the sound herd. Please either select the correct herd if you've checked or just select "Ebuilds" if you're not sure. Thanks
Libmtp API has changed from 0.2.* (libmtp7) to 0.3.* (libmtp8). Can someone create a patch like someone did for rhythmbox and gnomad2? Aleady reported upstream(http://bugzilla.gnome.org/show_bug.cgi?id=542117), they seem to ignore it...
Created attachment 164316 [details, diff] Patch to fix compile against mtp-0.3 There was an ABI/API change, a couple of functions in libmtp had an extraneous argument (parentID) removed. So this patch removes the extraneous argument. It compiles and Banshee starts but I don't have an MTP device. Keep in mind this is just a glorified search-and-replace job. If it works, feel free to submit to the Banshee people. If it doesn't, you get to keep all the pieces your MTP device bursts into. Until upstream accepts its probably better just to make the MTP USE flag depend additionally on <media-libs/mtp-0.3 .
I tried it and it doesn't work. Unfortunately I couldn't create a meaningfull backtrace, but It seems the bug is not in mono. $ banshee-1 --debug ** Running Mono with --debug ** [Debug 12:03:58.801] NDesk.DBus.Bus.Session.RequestName ('org.bansheeproject.Banshee') => PrimaryOwner [Info 12:03:58.845] Running Banshee 1.2.1 Assembly not found: Banshee.Services, Version=1.2.1.33120, Culture=neutral WARNING: [Banshee.AlarmClock,0.4.1] Could not load some add-in assemblies: The classes in the module cannot be loaded. Assembly not found: Banshee.Services, Version=1.2.1.22833, Culture=neutral WARNING: [Banshee.AwnIcon,1.0] Could not load some add-in assemblies: Could not load file or assembly 'Banshee.Services, Version=1.2.1.22833, Culture=neutral' or one of its dependencies. WARNING: [Banshee.AlarmClock,0.4.1] Could not load some add-in assemblies: The classes in the module cannot be loaded. WARNING: [Banshee.AwnIcon,1.0] Could not load some add-in assemblies: The classes in the module cannot be loaded. WARNING: [Banshee.AwnIcon,1.0] Could not load some add-in assemblies: The classes in the module cannot be loaded. Required add-in not found [Debug 12:04:01.063] Core service started (DBusServiceManager, 0,002899s) [Debug 12:04:01.091] Core service started (DBusCommandService, 0,026848s) [Debug 12:04:01.362] Opened SQLite connection to /home/mieszko/.config/banshee-1/banshee.db [Debug 12:04:01.363] Core service started (DbConnection, 0,271623s) [Debug 12:04:01.383] Database version 20 is up to date [Debug 12:04:01.421] Core service started (PreferenceService, 0,035979s) [Debug 12:04:01.425] Core service started (SourceManager, 0,003721s) [Debug 12:04:01.858] Core service started (MediaProfileManager, 0,431677s) [Debug 12:04:01.900] Core service started (PlayerEngine, 0,041725s) [Debug 12:04:01.917] Configuration client extension loaded (Banshee.GnomeBackend.GConfConfigurationClient) [Debug 12:04:02.067] IO provider extension loaded (Banshee.IO.Unix.Provider) [Debug 12:04:02.084] Core service started (TranscoderService, 0,023202s) [Debug 12:04:02.090] Core service started (PlaybackController, 0,005304s) [Debug 12:04:02.091] Core service started (ImportSourceManager, 0,000958s) [Debug 12:04:02.104] Core service started (LibraryImportManager, 0,01262s) [Debug 12:04:02.105] Core service started (UserJobManager, 0,001142s) [Debug 12:04:02.132] Core service started (HardwareManager, 0,027349s) [Debug 12:04:02.244] Adding icon theme search path: /usr/share/banshee-1/icons [Debug 12:04:02.245] Core service started (GtkElementsService, 0,113136s) [Debug 12:04:02.412] Core service started (InterfaceActionService, 0,165874s) [Debug 12:04:02.413] Album artwork path set to /home/mieszko/.cache/album-art [Debug 12:04:02.413] Core service started (ArtworkManager, 0,001582s) [Debug 12:04:03.939] Core service started (NereidPlayerInterface, 1,525036s) [Debug 12:04:04.055] Extension service started (AudioCdService, 0,114581s) [Debug 12:04:04.059] Extension service started (DaapService, 0,002364s) [Debug 12:04:04.063] Extension service started (DapService, 0,003429s) [Debug 12:04:04.096] Extension service started (BookmarksService, 0,032904s) [Debug 12:04:05.138] Extension service started (NotificationAreaService, 1,041615s) [Debug 12:04:05.153] Extension service started (MiniModeService, 0,014854s) [Debug 12:04:05.193] Extension service started (LastfmRecommendationService, 0,038984s) [Debug 12:04:05.279] Audioscrobbler state: connected [Debug 12:04:05.283] Extension service started (AudioscrobblerService, 0,088808s) [Debug 12:04:05.290] Extension service started (GnomeService, 0,006277s) [Debug 12:04:05.298] Extension service started (BooScriptService, 0,008046s) [Debug 12:04:05.893] Extension service started (PodcastService, 0,595135s) [Debug 12:04:05.902] Using GNOME 2.22 API for Multimedia Keys [Debug 12:04:05.902] Extension service started (MultimediaKeysService, 0,008193s) [Debug 12:04:06.211] GStreamer pipeline does not run: audioconvert ! xingenc bitrate=128 ! id3v2mux [Debug 12:04:06.313] GStreamer pipeline does not run: audioconvert ! wavpackenc mode=2 md5=false extra-processing=0 ! apev2mux [Debug 12:04:06.315] GStreamer pipeline does not run: audioconvert ! fluwmaenc bitrate=64000 vbr=false ! fluasfmux [Debug 12:04:06.315] Extension service started (GStreamerCoreService, 0,410223s) [Debug 12:04:06.325] (libbanshee:player) Using built-in equalizer element [Debug 12:04:06.355] Player state change: NotReady -> Ready [Debug 12:04:06.385] Enabling equalizer preset: Rock [Debug 12:04:06.404] Player state change: Ready -> Idle [Debug 12:04:06.414] Extension service started (CoverArtService, 0,004619s) [Info 12:04:06.416] All services are started 5,362122s [Debug 12:04:08.743] Loaded IScreensaverManager: Banshee.GnomeBackend.GnomeScreensaverManager [Info 12:04:09.754] nereid Client Started [Debug 12:04:09.791] Dap support extension loaded: Banshee.Dap.MassStorage [Debug 12:04:10.180] Dap support extension loaded: Banshee.Dap.Mtp PTP: Opening session Stacktrace: Native stacktrace: Naruszenie ochrony pamięci
But it's not libmtp patch either. Rhythmbox with libmt patch works. Not only "parentID" changed they also say: "LIBMTP_Detect_Raw_Devices() and LIBMTP_Open_Raw_Device() are now available to open sessions to selected devices only." I own Creative ZEN Vision:M, maybe it was accessed using RAW mode? I'm no programmer so I can't check it.
Created attachment 164439 [details, diff] Patch to fix compile against mtp-0.3, attempt 2 My bad. I failed to realize not only did some of the functions change, but the structs did too. So here's an update version that fixes both.
(In reply to comment #6) > Created an attachment (id=164439) [edit] > Patch to fix compile against mtp-0.3, attempt 2 > > My bad. I failed to realize not only did some of the functions change, but the > structs did too. So here's an update version that fixes both. > It's working...for me;) Thank you very much. I have a Zen Vision:M. Please everybody test it. I'll send the patch upstream once more. Can someone make ebuild including patch?
+*banshee-1.2.1-r1 (03 Sep 2008) + + 03 Sep 2008; Peter Alfredsen <loki_val@gentoo.org> + +files/banshee-1.2.1-libmtp-0.3.0-API.patch, banshee-1.0.0-r1.ebuild, + banshee-1.2.1.ebuild, +banshee-1.2.1-r1.ebuild: + Add patch for bug 233869. Kudos to Salah Coronya <salahx@yahoo.com>, who + produced this. +
Created attachment 164579 [details] Debug log for transferring files to Zen Vision:M using libmtp 0.3.0 When i try to transfer files to device, it crashes at first transfer (using libmtp 0.3.0)
Can anybody tell if patch is really working for anybody? For me it prevents from crashing banshee, when I insert my player... ****************************From banshee-trunk changelog: "2008-09-05 Gabriel Burt <> * src/Extensions/Banshee.Podcasting/Banshee.Podcasting.Gui/DownloadManager/DownloadUserJob.cs: * src/Extensions/Banshee.Podcasting/Banshee.Podcasting.Gui/DownloadManager/DownloadManagerInterface.cs: Slightly more useful job status, shows how many total downloads in the job * src/Libraries/Mtp/Mtp/Track.cs: Hack around .m4v issue. * build/m4/banshee/dap-mtp.m4: * NEWS: Don't allow libmtp8 for now, and clarify how packages need to require libmtp (to ensure users have the same version the package was compiled against). **************************** So they don't plan to include libmtp too soon.... Maybe there could be a possibility, to install libmtp in different slot, or include it with banshee to comoile against it and use it until they make it compatible? Please, reopen bug, as no one reported banshee *really* working with libmtp8.
Reopening per above
Created attachment 164773 [details] Patch to fix compile against mtp-0.3, attempt 3 Third time is a charm. I got too zealous on the previous patch and chopped an argument off a function I shouldn't have. This fixes it.
This is making progress...;) Now it displays the occupation of disk space on my player. It's not able to show what tracks are on it. I'll try to reset my player. But trying to send track results in: PTP Layer error 02ff: get_first_storage_freespace(): could not get storage info. (in `') (Look this up in ptp.h for an explanation.) (in `') check_if_file_fits(): error checking free storage. (in `') LIBMTP_Send_File_From_File_Descriptor(): all device storage is full or corrupt. (in `') LIBMTP_Send_Track_From_File_Descriptor(): subcall to LIBMTP_Send_File_From_File_Descriptor failed. (in `Mtp') at Mtp.LibMtpException.CheckErrorStack (Mtp.MtpDeviceHandle handle) [0x00000] at Mtp.Track.SendTrack (Mtp.MtpDeviceHandle handle, System.String path, Mtp.TrackStruct& metadata, Mtp.ProgressFunction callback, IntPtr data, UInt32 parent) [0x00000] at Mtp.MtpDevice.UploadTrack (System.String path, Mtp.Track track, Mtp.Folder folder, Mtp.ProgressFunction callback) [0x00000] at Banshee.Dap.Mtp.MtpSource.AddTrackToDevice (Banshee.Collection.Database.DatabaseTrackInfo track, Banshee.Base.SafeUri fromUri) [0x00000] at Banshee.Dap.DapSource.AddTrackAndIncrementCount (Banshee.Collection.Database.DatabaseTrackInfo track) [0x00000] at Banshee.Sources.PrimarySource.AddTrackList (System.Object cached_list) [0x00000] I'll report after cleanup.
After cleanup banshee is also unable to get tracks, it only displays how much data is on player not saying how much of these are videos or music. In console it shows up something like: PTP: Sequence number mismatch 7001 vs expected 7003. PTP: Sequence number mismatch 7002 vs expected 7004. PTP: Sequence number mismatch 7003 vs expected 7005. PTP: Sequence number mismatch 7004 vs expected 7006. PTP: Sequence number mismatch 7005 vs expected 7007. etc. This is the ending of the log so I suppose it begins from ONE;D The ui hngs at "Loading My Zen 3486 from 4399 and proceeds 1 track per 10 seconds, but i think it used to happen with banshee 1.0 and libmtp 0.2.6 so I think It's not new libmtp's fault.
Recompiled with the new patch Plugged in my Zen Xtra, banshee recognizes it but is is unable to list songs, it just says how many are and how much disk space they take. from banshee --debug [Debug 11:00:28.356] Found DAP support (Banshee.Dap.Mtp.MtpSource) for device Onip [Warn 11:01:11.794] Caught an exception - Object reference not set to an instance of an object (in `Mtp') at (wrapper unknown) Mtp.TrackStruct:PtrToStructure (intptr,object) at (wrapper managed-to-native) System.Runtime.InteropServices.Marshal:PtrToStructure (intptr,System.Type) at Mtp.MtpDevice.GetAllTracks (Mtp.ProgressFunction callback) [0x0001d] in /var/tmp/portage/media-sound/banshee-1.2.1-r1/work/banshee-1-1.2.1/src/Libraries/Mtp/Mtp/MtpDevice.cs:180 at Banshee.Dap.Mtp.MtpSource.LoadFromDevice () [0x0001f] in /var/tmp/portage/media-sound/banshee-1.2.1-r1/work/banshee-1-1.2.1/src/Dap/Banshee.Dap.Mtp/Banshee.Dap.Mtp/MtpSource.cs:147 Hope this could help
Created attachment 164868 [details, diff] Patch to fix compile against mtp-0.3, attempt 4 Ok I had attached the wrong version of the patch on attempt 3. This is the correct one.
With this version of patch, after i plug device it shows up in banshee, but doesn't even try to refresh. Log: PTP: Opening session [Warn 10:57:02.702] Caught an exception - Object reference not set to an instance of an object (in `Mtp') at (wrapper unknown) Mtp.TrackStruct:PtrToStructure (intptr,object) at (wrapper managed-to-native) System.Runtime.InteropServices.Marshal:PtrToStructure (intptr,System.Type) at Mtp.MtpDevice.GetAllTracks (Mtp.ProgressFunction callback) [0x00000] at Banshee.Dap.Mtp.MtpSource.LoadFromDevice () [0x00000] And whe I try to transfer it just crashes.
The next version of banshee will specifically exclude libmtp >= 0.3, so I guess the ebuild should not contain this patch. See http://svn.gnome.org/viewvc/banshee?view=revision&revision=4475
(In reply to comment #18) > The next version of banshee will specifically exclude libmtp >= 0.3, so I guess > the ebuild should not contain this patch. > > See http://svn.gnome.org/viewvc/banshee?view=revision&revision=4475 > I already said that in comment #10.
It might not make a difference, but until I have time to take a better look at why it isn't working, note I'm using mono-1.2.6, I modified the mono-addins ebuild to not require mono-1.9, but only mono-1.2.6 (see bug 236169)
Created attachment 165069 [details, diff] Patch to fix compile against mtp-0.3, attempt 5 Ok, apparently LIBMTP_track_tract had a "composer" element added to it which I had missed previously, this added the missing element so that it marshals correctly.
Hell, it works!!! Thank you very much :)
(In reply to comment #18) > The next version of banshee will specifically exclude libmtp >= 0.3, so I guess > the ebuild should not contain this patch. > > See http://svn.gnome.org/viewvc/banshee?view=revision&revision=4475 They seem wrong there, they added that comment: * libmtp >= 0.2.0 and < 0.3.0 (0.2.6 recommended) * Note to packagers: since libmtp has different .so files for different versions, you need to require in your package the same version of libmtp you used to build Banshee. Since libmtp abi changes, it changes the soname, nothing wrong about it and it seems pretty obvious that binary packages need to require the same abi. Moreover if upstream doesn't plan to support >=libmtp-0.3 I'm afraid mtp support in banshee will have to be removed for our ebuilds, period. libmtp is not slotted and will probably never be, upstream seems to support only 0.3 now.
> They seem wrong there, they added that comment: > * libmtp >= 0.2.0 and < 0.3.0 (0.2.6 recommended) > * Note to packagers: since libmtp has different .so files for > different versions, you need to require in your package the same > version of libmtp you used to build Banshee. We' ve mentioned that already twice before in this thread.. So maybe we should file a bug, saying that libmtp should be slotted.
(In reply to comment #24) > So maybe we should file a bug, saying that libmtp should be slotted. why should it be slotted in the first place ? what should 'gcc foo.c -lmtp' link to ? mtp 0.2 or 0.3 ? what libmtp version should install /usr/bin/mtp-* programs ? My point was: libmtp upstream doesn't seem to have intended libmtp 0.2 and 0.3 to be installed in parallel. banshee upstream supports only libmtp 0.2, we ship libmtp 0.3. As breaking the deptree isn't an option, banshee will have to lose its mtp support until this is seriously sorted out.
Yeah, you're right. We could do some wrkaround to have both installed, and make banshee work with libmtp7, but upstream doesn't really support that, and it's really banshee's devs fault.
I don't have an mtp device, so I'm applying this with fingers crossed on your word, Mieszko. As Alexis pointed out, this isn't the choice between depending on libmtp <0.3.0 or >0.3.0. We need to maintain the integrity of the deptree, so it's either the mtp support provided by this patch or none at all. Slotting libmtp isn't going to happen. Thanks to Salah Colonya for taking the time to fix this problem, it's always a joy when our users know how to fix bugs themselves. Commit msg: +*banshee-1.2.1-r2 (10 Sep 2008) + + 10 Sep 2008; Peter Alfredsen <loki_val@gentoo.org> + files/banshee-1.2.1-libmtp-0.3.0-API.patch, + +files/banshee-1.2.1-notification-crash.patch, -banshee-1.2.1-r1.ebuild, + +banshee-1.2.1-r2.ebuild: + Probably definitely fix bug #233869, thanks again to Salah Colonya. Also + fix bug #236886 with fix from upstream. + If the patch still needs a bit of polishing, please ping this bug and I'll reopen.
(In reply to comment #27) > I don't have an mtp device, so I'm applying this with fingers crossed on your > word, Mieszko. > As Alexis pointed out, this isn't the choice between depending on libmtp <0.3.0 > or >0.3.0. We need to maintain the integrity of the deptree, so it's either the > mtp support provided by this patch or none at all. Slotting libmtp isn't going > to happen. Thanks to Salah Colonya for taking the time to fix this problem, > it's always a joy when our users know how to fix bugs themselves. > > Commit msg: > +*banshee-1.2.1-r2 (10 Sep 2008) > + > + 10 Sep 2008; Peter Alfredsen <loki_val@gentoo.org> > + files/banshee-1.2.1-libmtp-0.3.0-API.patch, > + +files/banshee-1.2.1-notification-crash.patch, -banshee-1.2.1-r1.ebuild, > + +banshee-1.2.1-r2.ebuild: > + Probably definitely fix bug #233869, thanks again to Salah Colonya. Also > + fix bug #236886 with fix from upstream. > + > > If the patch still needs a bit of polishing, please ping this bug and I'll > reopen. > Upstream also wants to keep compatibilityu with libmtp7, but...banshee's dev Gabriel Burt says: Salah, thanks a lot for the patches, it looks fine except we need to stay compatible with previous versions of libmtp. If you have time to add that run-time compatibility that would be wonderful, and would get committed quickly.
Created attachment 166239 [details, diff] Patch to fix compile against mtp-0.3, backported from Banshee svn A patch to support both both libmtp-0.2 and libmtp-0.3 (at least at compile time) has been merged upstream in the development version, I've backported it to banshee-1.2.1 . Compile tested against both libmtp-0.2 and libmtp-0.3, but since I don't have an MTP device so can't run test it. Note that if someone upgrades from mtp-0.2 to mtp-0.3 without explicitly rebuilding Banshee, it will malfunction with MTP devices. WARNING: revdep-revbuild DOES NOT detect this. Banshee must be explicitly re-emerged by the user.
