[karmic] FreezeException request for libmtp

please upgrade libmtp.
Thank you

That would be great. I've received many help request in ubuntu-it forum since I've posted a guide to update Jaunty libmtp from "PPA for next media". Thanks.

Upstream has already released 1.0.1, which adds even more devices and fixes some issues with performance and album artwork retrieval. C++ compatibility has also been improved.

I'm attaching the new ChangeLog diff.

Here the pbuilder log. It builds flawlessly.

The new release is source compatible with the current version, but applications will have to be recompiled. The path /usr/lib/libmtp.so.8.2.2 has been changes to /usr/lib/libmtp.so.8.3.1.

I've copied the build log from the terminal because either pbuilder hides it logfiles very well or its command line options don't all work.

Doing an installation test would be hard since all applications that use the library would have to be recompiled.

How many rdepends does the lib have? Do they all build with the new
version? What testing has been done that they work?

At this point integration with rdepends is the major consideration.

The command 'apt-cache rdepens libmtp8' returns the following list on Karmic:
  banshee
  python-pymtp
  mtpfs
  mtp-tools
  gnomad2
  banshee
  audacious-plugins-extra
  rhythmbox
  libmtp-dev
  amarok

Installing the new libmtp8 package doesn't give any problems.
Without rebuilding Banshee recognises the media player when it's connected and shows it, but the music list is empty; it places all data in the Other category and thinks it doesn't contain anything it can handle.

After installing the new library the device is mounted automatically when it's conected when there is no other application running that wants to use the device. Writing and reading to the device using the gphoto2:// protocol works, although copying a music file didn't add it to the music database on my player.

Building Rhythmbox and Banshee against the new library returns no errors.

Adding and removing songs in Rhythmbox works, but trying to play back directly from the device results in this error:
 (rhythmbox:22234): GStreamer-WARNING **:
 Trying to join task 0x2397290 from its thread would deadlock.
 You cannot change the state of an element from its streaming
 thread. Use g_idle_add() or post a GstMessage on the bus to
 schedule the state change from the main thread.

I'm not sure whether play back did work before I installed the newly compiled version of libmtp.

When loading the device in Banshee this exception is raised:
 MTP extended association type 0x00000001 encountered
 MTP extended association type 0x00000001 encountered
 MTP extended association type 0x00000001 encountered
 MTP extended association type 0x00000001 encountered
 MTP extended association type 0x00000001 encountered
 MTP extended association type 0x00000001 encountered
 MTP extended association type 0x00000001 encountered
 MTP extended association type 0x00000001 encountered
 MTP extended association type 0x00000001 encountered
 MTP extended association type 0x00000001 encountered
 MTP extended association type 0x00000001 encountered
 [Warn 15:19:39.338] 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]

The behaviour of all programs is the same as before I rebuilt them against libmtp8 1.0.1. Interesting is this bug report: http://bugs.gentoo.org/show_bug.cgi?id=280718
It says that libmtp 1.0.0 breaks MTP support in Banshee, which would plead against my case.

However, their does seem to be a lag when the program tries to detect the device, more retries are needed. This could use some further investigation.

This is my report for now, I'm still investigating on the matter, but I thought it would be good to already inform you of the current problems.

Just noticed (from the rdepends list) that this package is in Main. It's up to ubuntu-release, not motu-release.

OK, my bad. I probably read the FreezeException guidelines too quickly. Thanks for fixing it.

I've uploaded the latest version of the library to my PPA at <https://launchpad.net/~qense/+archive/ppa>.

I'm a bit concerned about having to rebuild packages against the new library, although it didn't bump SONAME. If it broke ABI in a backwards-incompatible way, it should get a soname bump to libmtp9, so that upgrades/backports/etc. won't break. OTOH, if it is backwards compatible, then we shouldn't need to have to rebuild apps.

This would only make sense if the new version has some new API which banshee & friends detect at build time, and based on this disable/enable some functionality.

But if the music list wasn't empty with the current karmic packages, but is empty with the new packages, then it rather sounds like a real ABI breakage?

I've been doing some extensive testing lately with this library and Banshee and the results weren't that good. I've traced it down to the problem in Banshee, but I haven't figured out yet what caused the problem inside libmtp.

It works like this: libmtp fetches a song from the player and puts it in a list -- if you call it that way in C(++), it uses a var->property syntax. The first song is saved in what is to become to return variable and the temporary variable is emptied and filled with the data of the new song. The pointer to this data is then saved in previous-song->next. This process continues until everything has been read.
It seems that in Banshee the pointer to the next song isn't a PtrInt, but rather an Int with the value 1. This breaks the whole thing.
Strangely the new library does seem to work reasonably well with Rhythmbox.

About the ABI/API changes: upstream specifically said that all applications that use the library should be rebuilt, but that the library was source compatible. The only changes to ABI were that some new functions and properties have been introduced in 1.0.0. I'm not sure if I got them added to the debian/libmtp8.symbols file correctly.
The 1.0.x versions also include a newly merged/fetched/rewritten PTP implementation.

However, rebuilding doesn't seem to be necessary at all (as far as I've tested) for most applications. Both Rhythmbox and Banshee apparantly use the symlink libmtp8.so.

When saying that 1.0.x does work with Rhythmbox without having to rebuild the media player I said reasonably because the library -- and its (mtp-)tools -- sometimes have problems with detecting devices and with properly 'mounting' it. It happens that you have to probe several times before your device is found and sometimes it says the device is busy, whereas it shouldn't. Mounting the device -- which allows you to access it via the gphoto:// protocol -- also seems to be a bit more aggressive, i.e. it mounts more often and sometimes even in spite of opened media players.

I also got a a few times a strange exception when using my player with Banshee telling me it couldn't detect the battery level. This was gone after a while, but I haven't found out what caused it.

After this testing I don't think it's still such a good idea to upload the new version of libmtp to Karmic. It feels to unstable to be given an exception so late in the development cycle. Instead lets make sure we get the latest version into the upcoming LTS in April 2010. We could backport some of the new devices, though.

Yes, I agree; this doesn't look like something we should make an exception for. Marking wontfix.