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

[Aaron Bockover <abockover novell com>]

Did you have the problem with the 0.11.2 release on SLED as well? For a
week or so in CVS, there was a typo in an assembly loading filter that
actually broke all DAP support, though that brokenness never made it in
a release.

Could you provide the BooBuddy failure as well? It's building fine here
for me on SLED, but I am using Mono 1.2.

--Aaron


On Tue, 2006-11-21 at 18:46 -0700, Gary Ekker wrote:
> 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
> 
> _______________________________________________
> Banshee-list mailing list
> Banshee-list gnome org
> http://mail.gnome.org/mailman/listinfo/banshee-list