Re: [Banshee-List] ipod doesn't show in banshee

[Aaron Bockover <abockover novell com>]

On Sun, 2006-11-19 at 21:04 -0500, Michel Salim wrote:

> Matthew Fata and myself also reported the same problem a few weeks
> ago, but that thread seems to have died down. He's on Gentoo and I'm
> on Fedora Core; in all cases ipod --list works.

There are a few other detection layers in Banshee above ipod --list. All
ipod --list tells you is that your iPod should be functional if in fact
it can be detected in Banshee. 

> Matthew's strace seems to suggest that Banshee was erroneously using
> the NJB library when it is supposed to load the iPod one instead.
> Could someone who speaks C# have a look?

No, it's not possible for NJB to load an iPod. Banshee works with more
than just iPods, so we have a fairly complicated detection layer that
has apparently been broken for some folks in the last release.

The process basically works like this:

1. Banshee loads DAP plugins and registers their types in a table at
startup. The DAP Core listens for HAL device events.

2. When a device is plugged in, a HAL device added event is raised, and
the DAP core reacts.

3. Some basic HAL properties are checked for performance reasons. Here
the hope is to eliminate a number of devices we probably won't care
about later in the process. Namely, we only go to step 4 if the
following is true:

(volume.policy.should_mount = true && volume.is_disc = false) ||
info.category = "portable_audio_player"

That effectively verifies that either the device should be mountable and
is not a disk (i.e. a CD), which later has the potential of at least
being a mass storage player or that the device is a known
portable_audio_player (such as an iPod or NJB deivce). The iPod happens
to satisfy both cases.

4. If the device needs mounting (volume.policy.should_mount), the DAP
core waits before going to step 5 until the device is actually mounted.
In 0.11.2, to get around some issues in the new managed DBus, I was
polling using a timeout and a wait table to check for the property
change (volume.is_mounted). In CVS today, I am now using the
device.PropertyModified event to kick off the volume.is_mounted check
and move to step 5. This change hopefully should fix the issues people
have been seeing.

5. Now the DAP core iterates over all registered DAP plugins in no
particular order (iPod, NJB, Mass Storage, MTP...). It instantiates the
plugin type's DapDevice object and tries to initialize it with the HAL
device from step 4. If the initialization succeeds, the DapDevice is
captured and registered and is effectively available for the user to
enjoy. If it fails, the next type is tried. The NJB in the strace was
just this process. The NJB plugin type was tested to see if the device
was suitable for NJB's use. That initialization would quickly fail and
the next type would be attempted.

In any regard, I've committed my fix noted in step 4 and could use some
testing. I have yet to reproduce the issue that people have been seeing
in 0.11.2, so it's a bit hard to say for sure that its fixed. I've tried
reproducing the problem on SLED 10, openSUSE 10.2, and Ubuntu Edgy with
various iPods to no avail.

--Aaron