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

[Gary Ekker <gekker novell com>]

I could reproduce it reliably on SLED10 with banshee CVS. It is now
fixed for me with todays update, although BooBuddy failed to compile, I
just didn't build that subdir...

Thanks for the fix.

-Gary

On Tue, 2006-11-21 at 15:36 -0500, Aaron Bockover wrote:
> 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
> 
> 
> _______________________________________________
> Banshee-list mailing list
> Banshee-list gnome org
> http://mail.gnome.org/mailman/listinfo/banshee-list