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

[Gary Ekker <gekker novell com>]

On Wed, 2006-11-22 at 11:48 -0500, Aaron Bockover wrote:
> 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.
> 
I've been running the current SLED packages fine, it was just CVS that
was installed in a parallel prefix that didn't work for some time. I
haven't paid any attention to what the version changes are as i update
from CVS.

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

Making all in BooBuddy
make[3]: Entering directory `/home/gekker/src/banshee/src/BooBuddy'
/usr/bin/booc -t:library -o:BooMacros.dll -debug-
-nologo ./AliasMacro.boo
Invalid option: -nologo.
/AliasMacro.boo(20,45): BCE0044: 'expecting "INDENT", found 'return''.
/AliasMacro.boo(21,39): BCE0044: 'expecting "INDENT", found 'return''.
/AliasMacro.boo(23,32): BCE0044: 'expecting "INDENT", found 'return''.
3 error(s).

boo-0.7.0.1921-17.3
mono-core-1.1.13.8-2.11
dbus-1-mono-0.60-33.3
mono-data-sqlite-1.1.13.8-2.11
mono-data-1.1.13.8-2.11
monodoc-core-1.1.13-17.3
mono-tools-1.1.11-20.3
mono-devel-1.1.13.8-2.11
mono-basic-1.1.13.8-2.11
mono-web-1.1.13.8-2.11
mono-nunit-1.1.13.8-2.11
mono-winforms-1.1.13.8-2.11
monodevelop-0.9-33.3

Essentially the current packages from the SP1 branch of SLED10.

-Gary
> 
> 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
> 
> _______________________________________________
> Banshee-list mailing list
> Banshee-list gnome org
> http://mail.gnome.org/mailman/listinfo/banshee-list