Any chance for someone looking into this bug?

No version of Banshee (1.4.x/1.5.x) running on Fedora 11 recognizes iPod players and as a result in a bad user experience for iPod owners that are trying to use Banshee as an iTunes replacement.

My guess is that on most distros, in this code:

            bool private_mount = !hal_device.GetPropertyBoolean("volume.is_mounted");

            if(private_mount) {
                mount_point = LowLevelMount.GenerateMountPoint();
                fs_type = hal_device["volume.fstype"];
                LowLevelMount.Mount(HalEnvironment.BlockDevice, mount_point, fs_type, true);
            } else {
                mount_point = hal_device["volume.mount_point"];
            }

private_mount is false; that is, the distro already mounted the drive, so the podsleuth mounting code path doesn't get run).  You can try modifying the LowLevelMount.Mount method to print out whether the mount point directory exists (according to System.IO) to corroborate the exception message.  It should have been created by the call to GenerateMountPoint - could also modify that method to make sure it's working.

I'm getting a similar error to the original reporter on my Ubuntu karmic install.

When I try to trace through podsleuth in the MonoDevelop debugger, it looks like the only device matched by this code:

            foreach(Hal.Device ipod in manager.FindDeviceByStringMatchAsDevice("info.product", "iPod")) {
                foreach(Hal.Device volume in ipod.GetChildrenAsDevice(manager)) {
                    if(!volume.IsVolume || 
                        !volume.PropertyExists("volume.is_mounted") ||
                        !volume.PropertyExists("volume.fsusage") ||
                        !volume.GetPropertyBoolean("volume.is_mounted") ||
                        volume.GetPropertyString("volume.fsusage") != "filesystem") {
                        continue;
                    }

... is skipped because volume.GetPropertyBoolean("volume.is_mounted") is false.

My knowledge of this code (and C#, Mono, HAL and iPods!) is pretty shallow. I'm happy to debug further, but I'll need some hints.

Hope this helps,
jml

This bug might be a duplicate of http://bugzilla.gnome.org/show_bug.cgi?id=553311

As per my previous comment, the iPod is not found because 'volume.is_mounted' is false. I tried removing this check from podsleuth to see what happened. If I do so, I get the following error:

$ ~/local/bin/podsleuth --debug
Found device
Found children
volume.IsVolume: True
volume.is_mounted: False
volume.fsusage: filesystem
Found an iPod device, but it is not known by PodSleuth:
   Error: org.podsleuth.* properties are missing
   UDI:          /org/freedesktop/Hal/devices/volume_uuid_3141_5926
   Block Device: /dev/sdb1
   Mount Point:  

   Cause: PodSleuth may not be installed properly, the HAL daemon may need
          to be restarted and/or the device needs to be refreshed.

   Note:  A PodSleuth debug log was found: /tmp/podsleuth-debug
          This file may provide more details or can be useful to
          developers. Please save it somewhere else and use it in
          a bug report. See http://banshee-project.org/PodSleuth


$ cat /tmp/podsleuth-debug 
Pre-Mount Settings:
  - UDI:                    /org/freedesktop/Hal/devices/volume_uuid_3141_5926
  - Block Device:           /dev/sdb1
  - Temporary Mount Point:  /tmp/podsleuth-mount-7
  - FS Type:                vfat

Exception:

Mono.Unix.UnixIOException: No such file or directory [ENOENT].
  at PodSleuth.LowLevelMount.Mount (System.String source, System.String target, System.String fstype, Boolean readOnly) [0x0002b] in /home/jml/src/podsleuth/src/PodSleuth/PodSleuth/LowLevelMount.cs:24 
  at PodSleuth.HalFrontend.HalPopulator.RunInternal (System.String[] args) [0x00065] in /home/jml/src/podsleuth/src/PodSleuth.Hal/PodSleuth.HalFrontend/HalPopulator.cs:61 
  at PodSleuth.HalFrontend.HalPopulator.Run (System.String[] args) [0x00000] in /home/jml/src/podsleuth/src/PodSleuth.Hal/PodSleuth.HalFrontend/HalPopulator.cs:24

As a reminder, the system podsleuth does:
$ podsleuth
No iPods were found in the HAL device tree


RAOF suggested that the problem might be due to some weird interaction between Gnome's udev-based automounting and podsleuth's HAL requirements. So I ejected my iPod, unplugged it, logged out of gnome, confirmed that the automounter wasn't running and then tried running podsleuth from a terminal. No joy.

However, when I ran my hacked copy of podsleuth:
Found device
Found children
volume.IsVolume: True
volume.is_mounted: False
volume.fsusage: filesystem
iPod Found [/org/freedesktop/Hal/devices/volume_uuid_3141_5926]
  * Generic Device Properties
    - Block Device:       /dev/sdb1
    - Mount Point:        
    - Read Only:          False
    - Volume Size:        120 GiB
  * General iPod Properties
    - Serial Number:      8K908S1E2C7
    - Firewire ID:        000A2700139D99D9
    - Firmware Version:   2.0.1
    - iPod_Control:       /iPod_Control
    - Extra Capabilities: podcast
    - Production Info:    36338 in February, 2009 from factory 8K
  * iPod Model Properties
    - Device Class:       classic
    - Generation:         7
  * Image Types Supported
    - Photos:             True
    - Album Art:          True
    - Chapter Images:     True


This smells a little like success.

I still get the same output after I launch Gnome (note: without unplugging or
ejecting my iPod).

If I run with --rescan though:

$ ~/local/bin/podsleuth --rescan --debug
Found device
Found children
volume.IsVolume: True
volume.is_mounted: False
volume.fsusage: filesystem
Rescanning device [/org/freedesktop/Hal/devices/volume_uuid_3141_5926]

Unhandled Exception: System.Exception: org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 1 matched rules; type="method_call", sender=":1.254" (uid=1000 pid=16222 comm="mono) interface="org.podsleuth" member="Scan" error name="(unset)" requested_reply=0 destination="org.freedesktop.Hal" (uid=0 pid=15894 comm="/usr/sbin/hald))
  at IPodSleuthProxy.Scan () [0x00000] 
  at PodSleuth.HalFrontend.HalClient.Run (System.String[] args) [0x00000] 
  at PodSleuth.HalFrontend.HalEntry.Main (System.String[] args) [0x00000] 


Once I unplug my iPod and plug it in again, behaviour returns to match the first examples.

This appears to be because of the use of Devicekit-disks on these distros. I've started work on  a devicekit-disks frontend to podsleuth that will fix much of this. I'll keep this bug report updated with my progress and push a branch to git when it's ready.

I'm not sure if this will help, but I actually starting chipping away at this earlier this summer. I didn't ever get to the point of working on actual iPod integration, but I did begin putting together a pure C# wrapper for the DeviceKit and DeviceKit-Disks DBus interfaces[1].

Unfortunately, I ended up dropping it after I found that NDesk-DBus doesn't conveniently support the native DBus Properties interface. I was hoping someone would pick it up as I no longer have time to advance it (especially if that means hacking NDisk-DBus), but no one has stepped up yet (although I know someone was trying to use the code at some point; I wrote them an email asking whether they made any progress on it; we'll see what comes back).

[1] http://www.mail-archive.com/mono-list@lists.ximian.com/msg29932.html

*** Bug 599820 has been marked as a duplicate of this bug. ***

Has there been much luck with this?  Ubuntu Karmic will be released in a couple days, which will probably bring a whole bunch of duplicates and unhappy iPod users.

I'm one of those unhappy iPod users. Is there an ETA as to when a fix for podsleuth might be available, or is there somewhere we can track the progress (other than here)?

*** Bug 601207 has been marked as a duplicate of this bug. ***

As far as I can tell, the problem is that whatever is mounting the iPod now (udev or devicekit-disks), the HAL volume.is_mounted and volume.mount_point properties aren't being set.

So, either we 1) fix that 2) workaround it by checking ourselves if a device is mounted (not sure how to do this; I think GIO can tell you what volume/device a path is on) or 3) transition entirely to DeviceKit, which also includes adding support for it in ipod-sharp and Banshee (that is, a lot more work)

I made an attempt to do that but the problem was that ndesk-dbus doesn't fully implement all dbus features and some of them are very complex to implement. (Like Properties).

Also, when asked on #banshee some people said it should move to udev, but other people were opposed to that and since it seemed nobody could agree on it I stopped.

I'm not sure how tools like gtkpod do it, but they all still work and as far as I can tell Banshee is the only application on my system currently unable to detect my iPod.

@Jensen: Songbird doesn't work either. (A workaround is to mount the ipod, then logout and back in again.) And I find that while Rhythmbox mounts my 1st gen ipod shuffle, it has problems uploading tracks to it. (At one point I had to log into Windows to restore my ipod in iTunes as the ipod wasn't detecting any tracks even though they showed up in Rhythmbox.)

It is a bit surprising that the standalone managers work fine.

I'm using openSUSE 11.2 and can confirm this bug with Banshee 1.6 Beta 2. Is there a chance to get this fixed in the next release?

GTKPod works (in Ubuntu) because it doesn't bother with udev, hal, OR devicekit-disks.  It asks one to specify the mount point (In my case, /media/IPOD), and it goes from there.  Devicekit generally always mounts the device in the same location, so it isn't a problem.

That's not necessarily a bad solution. Auto-detection is nice but in my opinion it's not a requirement.

When I used Amarok I had the same problem: it wouldn't auto-detect my iPod but using the build-in device manager I was able to specify the mount point so when I plugged the device in it would detect the iPod device had been mounted on that location. I wouldn't even mind pressing the connect button every time I plug my iPod in.

Ok, I have committed fixes to podsleuth and Banshee for this: iPods and usb-drive-based DAPs should again work in Banshee (iPods only if you have the latest podsleuth).  Please test!

Hey Gabriel, thanks for working on this! I want to test it so I pulled the last git master, and the first thing I noticed is that the configure phase didn't warn me about needing to update podsleuth. Is this desirable for the configure script to detect if DK is running and whine if ipod support is not disabled?

I've tried to install the latest git-master podsleuth and I get this in the configure phase:

config.status: creating tests/Makefile
config.status: executing depfiles commands

PodSleuth 0.6.6

   Prefix:        /usr/local
   HAL Callouts:  /usr/local/lib/hal
   Updates Cache: /usr/local/var/cache/podsleuth
   libsgutils:    libsgutils2.so.2

   ******** WARNING ********

   Could not locate the standard HAL callout script,
   hal-storage-eject in /usr/local/lib/hal.

   You should re-run configure and set --with-hal-callouts-dir
   to the right location. In Gentoo for example, you 
   may need to run:

     ./configure --with-hal-callouts-dir=/usr/libexec


Is this a problem I can solve easily? Or is it just a non-important warning? Please let me know if you need more info so as I can test this successfully.

You definitely have to solve it. Have you tried running configure with the hal callouts option like it suggested?

./configure --with-hal-callouts-dir=/usr/libexec

The location of the hal stuff is different depending on what distro you're running and sometimes the configure script has trouble finding it on its own. I know I have to run configure as described on Fedora and I think you have to use it on Ubuntu as well (I'm not 100% sure about that though).

(In reply to comment #20)
> You definitely have to solve it. Have you tried running configure with the hal
> callouts option like it suggested?
> 
> ./configure --with-hal-callouts-dir=/usr/libexec
> 
> The location of the hal stuff is different depending on what distro you're
> running and sometimes the configure script has trouble finding it on its own. I
> know I have to run configure as described on Fedora and I think you have to use
> it on Ubuntu as well (I'm not 100% sure about that though).

You're right thanks. Sorry, stupid me, I was just simply installing in a different prefix than where libhal-devel is. As soon as I chose --prefix=/usr , the warning went away. So I uninstalled the previous podsleuth, reinstalled with the new prefix, re-configured and re-built and re-run banshee, but no luck, it doesn't bring the iPod source when I connect it. (FWIW I'm using openSuse 11.2.)

So Gabriel, tell me if you need info about this, I would like to help. I'll lurk on IRC from time to time.

(In reply to comment #21)
> ... and re-run banshee, but no
> luck, it doesn't bring the iPod source when I connect it.

Ok, when I finished writing that comment, I went to look at my banshee and the iPod source was there! So I guess what happens is that there's a bit more delay for detecting the source inside banshee than just when the system detects it and it opens it up in nautilus.

However, I'm testing now with auto-sync and I'm getting this exception:

[Warn  17:16:48.963] Caught an exception - The given key was not present in the dictionary. (in `mscorlib')
  at System.Collections.Generic.Dictionary`2[System.Int32,Banshee.Dap.Ipod.IpodTrackInfo].get_Item (Int32 key) [0x000a8] in /usr/src/packages/BUILD/mono-2.4.2.3/mcs/class/corlib/System.Collections.Generic/Dictionary.cs:143 
  at Banshee.Dap.Ipod.IpodSource.PerformSyncThreadCycle () [0x00221] in /home/knocte/Documentos/banshee/src/Dap/Banshee.Dap.Ipod/Banshee.Dap.Ipod/IpodSource.cs:613 
  at Banshee.Dap.Ipod.IpodSource.PerformSyncThread () [0x0001c] in /home/knocte/Documentos/banshee/src/Dap/Banshee.Dap.Ipod/Banshee.Dap.Ipod/IpodSource.cs:543 

Which makes the sync unusable because when I eject the iPod, I can see there were no real changes made to it (if all worked properly, it should have removed 2 songs from it and added 1). I'll test with manual-sync now and report here. And I'll try to squash the bug about auto-sync later.

(In reply to comment #22)
> ... I'll test with manual-sync now and report here.

It works with manual sync so I'm marking this bug as VERIFIED. I guess I'll open another bug for the auto-sync issue.

Thanks for the great work!

Thanks, Andrés.

On openSUSE/SLE I build podsleuth with:

$ ./autogen.sh --prefix=/usr --libdir=/usr/lib64 --sysconfdir=/etc

of course the libdir is only b/c I'm on a 64 bit install.

(In reply to comment #24)
> On openSUSE/SLE I build podsleuth with:
> 
> $ ./autogen.sh --prefix=/usr --libdir=/usr/lib64 --sysconfdir=/etc
> 
> of course the libdir is only b/c I'm on a 64 bit install.

Thanks for the info.

BTW, while trying to reproduce again the auto-sync problem, I got an exception when ejecting the iPod which seems related to the changes made for this bug:

[Warn  21:43:23.858] Caught an exception - org.freedesktop.DBus.Error.UnknownMethod: Method "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist
 (in `NDesk.DBus.Proxies')
  at PropertiesProxy.Get (System.String propname, System.String ) [0x00000] 
  at Banshee.HalBackend.DkDisk.get_IsReadOnly () [0x00000] in /home/knocte/Documentos/banshee/src/Backends/Banshee.Hal/Banshee.HalBackend/DkDisk.cs:81 
  at Banshee.HalBackend.Volume.get_IsReadOnly () [0x00000] in /home/knocte/Documentos/banshee/src/Backends/Banshee.Hal/Banshee.HalBackend/Volume.cs:118 
  at Banshee.Dap.Ipod.PodSleuthDevice.get_IsReadOnly () [0x00000] in /home/knocte/Documentos/banshee/src/Dap/Banshee.Dap.Ipod/Banshee.Dap.Ipod/PodSleuthDevice.cs:294 
  at Banshee.Dap.Ipod.IpodSource.get_IsReadOnly () [0x00000] in /home/knocte/Documentos/banshee/src/Dap/Banshee.Dap.Ipod/Banshee.Dap.Ipod/IpodSource.cs:428 
  at Banshee.Dap.Ipod.IpodSource.get_CanRename () [0x00000] in /home/knocte/Documentos/banshee/src/Dap/Banshee.Dap.Ipod/Banshee.Dap.Ipod/IpodSource.cs:386 
  at Banshee.Gui.SourceActions.UpdateActions (Boolean force) [0x00070] in /home/knocte/Documentos/banshee/src/Core/Banshee.ThickClient/Banshee.Gui/SourceActions.cs:369 
  at Banshee.Gui.SourceActions.<HandleActiveSourceUpdated>m__87 () [0x00000] in /home/knocte/Documentos/banshee/src/Core/Banshee.ThickClient/Banshee.Gui/SourceActions.cs:159 
  at Banshee.Base.ThreadAssist.ProxyToMain (Banshee.Base.InvokeHandler handler) [0x00015] in /home/knocte/Documentos/banshee/src/Core/Banshee.Services/Banshee.Base/ThreadAssist.cs:96 
  at Banshee.Gui.SourceActions.HandleActiveSourceUpdated (System.Object o, System.EventArgs args) [0x00000] in /home/knocte/Documentos/banshee/src/Core/Banshee.ThickClient/Banshee.Gui/SourceActions.cs:158 
  at (wrapper delegate-invoke) System.EventHandler:invoke_void__this___object_EventArgs (object,System.EventArgs)
  at Banshee.Sources.Source.OnUpdated () [0x0000d] in /home/knocte/Documentos/banshee/src/Core/Banshee.Services/Banshee.Sources/Source.cs:496 
  at Banshee.Sources.Source.OnPropertyChanged (System.Object o, Hyena.Data.PropertyChangeEventArgs args) [0x00000] in /home/knocte/Documentos/banshee/src/Core/Banshee.Services/Banshee.Sources/Source.cs:526 
  at (wrapper delegate-invoke) Hyena.Data.PropertyChangeEventHandler:invoke_void__this___object_PropertyChangeEventArgs (object,Hyena.Data.PropertyChangeEventArgs)
  at (wrapper delegate-invoke) Hyena.Data.PropertyChangeEventHandler:invoke_void__this___object_PropertyChangeEventArgs (object,Hyena.Data.PropertyChangeEventArgs)
  at Hyena.Data.PropertyStore.OnPropertyChanged (System.String propertyName, Boolean added, Boolean removed, System.Object oldValue, System.Object newValue) [0x0001a] in /home/knocte/Documentos/banshee/src/Libraries/Hyena/Hyena.Data/PropertyStore.cs:91 
  at Hyena.Data.PropertyStore.Remove (System.String name) [0x0004b] in /home/knocte/Documentos/banshee/src/Libraries/Hyena/Hyena.Data/PropertyStore.cs:108 
  at Banshee.Dap.DapSource.Dispose () [0x00029] in /home/knocte/Documentos/banshee/src/Dap/Banshee.Dap/Banshee.Dap/DapSource.cs:106 
  at Banshee.Dap.Ipod.IpodSource.Dispose () [0x00017] in /home/knocte/Documentos/banshee/src/Dap/Banshee.Dap.Ipod/Banshee.Dap.Ipod/IpodSource.cs:117 
  at Banshee.Dap.DapService.UnmapDevice (System.String uuid) [0x00075] in /home/knocte/Documentos/banshee/src/Dap/Banshee.Dap/Banshee.Dap/DapService.cs:247 
Exception in Gtk# callback delegate
  Note: Applications can use GLib.ExceptionManager.UnhandledException to handle the exception.
System.Exception: org.freedesktop.DBus.Error.UnknownMethod: Method "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist

  at PropertiesProxy.Get (System.String propname, System.String ) [0x00000] 
  at Banshee.HalBackend.DkDisk.get_IsReadOnly () [0x00000] in /home/knocte/Documentos/banshee/src/Backends/Banshee.Hal/Banshee.HalBackend/DkDisk.cs:81 
  at Banshee.HalBackend.Volume.get_IsReadOnly () [0x00000] in /home/knocte/Documentos/banshee/src/Backends/Banshee.Hal/Banshee.HalBackend/Volume.cs:118 
  at Banshee.Dap.Ipod.PodSleuthDevice.get_IsReadOnly () [0x00000] in /home/knocte/Documentos/banshee/src/Dap/Banshee.Dap.Ipod/Banshee.Dap.Ipod/PodSleuthDevice.cs:294 
  at Banshee.Dap.Ipod.IpodSource.get_IsReadOnly () [0x00000] in /home/knocte/Documentos/banshee/src/Dap/Banshee.Dap.Ipod/Banshee.Dap.Ipod/IpodSource.cs:428 
  at Banshee.Dap.RemovableSource.get_CanDeleteTracks () [0x00000] in /home/knocte/Documentos/banshee/src/Dap/Banshee.Dap/Banshee.Dap/RemovableSource.cs:80 
  at Banshee.Dap.DapSource.get_CanDeleteTracks () [0x00000] in /home/knocte/Documentos/banshee/src/Dap/Banshee.Dap/Banshee.Dap.Gui/DapActions.cs:1 
  at Banshee.Playlist.AbstractPlaylistSource.get_CanDeleteTracks () [0x0000c] in /home/knocte/Documentos/banshee/src/Core/Banshee.Services/Banshee.Playlist/AbstractPlaylistSource.cs:185 
  at Banshee.Gui.TrackActions.UpdateActions () [0x0013b] in /home/knocte/Documentos/banshee/src/Core/Banshee.ThickClient/Banshee.Gui/TrackActions.cs:229 
  at Banshee.Base.ThreadAssist.ProxyToMain (Banshee.Base.InvokeHandler handler) [0x00015] in /home/knocte/Documentos/banshee/src/Core/Banshee.Services/Banshee.Base/ThreadAssist.cs:96 
  at Banshee.Gui.TrackActions.HandleActiveSourceChanged (Banshee.Sources.SourceEventArgs args) [0x00078] in /home/knocte/Documentos/banshee/src/Core/Banshee.ThickClient/Banshee.Gui/TrackActions.cs:144 
  at (wrapper delegate-invoke) Banshee.Sources.SourceEventHandler:invoke_void__this___SourceEventArgs (Banshee.Sources.SourceEventArgs)
  at (wrapper delegate-invoke) Banshee.Sources.SourceEventHandler:invoke_void__this___SourceEventArgs (Banshee.Sources.SourceEventArgs)
  at (wrapper delegate-invoke) Banshee.Sources.SourceEventHandler:invoke_void__this___SourceEventArgs (Banshee.Sources.SourceEventArgs)
  at (wrapper delegate-invoke) Banshee.Sources.SourceEventHandler:invoke_void__this___SourceEventArgs (Banshee.Sources.SourceEventArgs)
  at (wrapper delegate-invoke) Banshee.Sources.SourceEventHandler:invoke_void__this___SourceEventArgs (Banshee.Sources.SourceEventArgs)
  at (wrapper delegate-invoke) Banshee.Sources.SourceEventHandler:invoke_void__this___SourceEventArgs (Banshee.Sources.SourceEventArgs)
  at (wrapper delegate-invoke) Banshee.Sources.SourceEventHandler:invoke_void__this___SourceEventArgs (Banshee.Sources.SourceEventArgs)
  at (wrapper delegate-invoke) Banshee.Sources.SourceEventHandler:invoke_void__this___SourceEventArgs (Banshee.Sources.SourceEventArgs)
  at (wrapper delegate-invoke) Banshee.Sources.SourceEventHandler:invoke_void__this___SourceEventArgs (Banshee.Sources.SourceEventArgs)
  at (wrapper delegate-invoke) Banshee.Sources.SourceEventHandler:invoke_void__this___SourceEventArgs (Banshee.Sources.SourceEventArgs)
  at (wrapper delegate-invoke) Banshee.Sources.SourceEventHandler:invoke_void__this___SourceEventArgs (Banshee.Sources.SourceEventArgs)
  at Banshee.Sources.SourceManager.SetActiveSource (Banshee.Sources.Source source, Boolean notify) [0x0006c] in /home/knocte/Documentos/banshee/src/Core/Banshee.Services/Banshee.Sources/SourceManager.cs:347 
  at Banshee.Sources.SourceManager.SetActiveSource (Banshee.Sources.Source source) [0x00000] in /home/knocte/Documentos/banshee/src/Core/Banshee.Services/Banshee.Sources/SourceManager.cs:322 
  at Banshee.Sources.Gui.SourceView.OnButtonPressEvent (Gdk.EventButton press) [0x00142] in /home/knocte/Documentos/banshee/src/Core/Banshee.ThickClient/Banshee.Sources.Gui/SourceView.cs:206 
  at Gtk.Widget.buttonpressevent_cb (IntPtr widget, IntPtr evnt) [0x0000d] in /usr/src/packages/BUILD/gtk-sharp-2.12.9/gtk/generated/Widget.cs:2938 
   at GLib.ExceptionManager.RaiseUnhandledException(System.Exception e, Boolean is_terminal) in /usr/src/packages/BUILD/gtk-sharp-2.12.9/glib/ExceptionManager.cs:line 58
   at Gtk.Widget.buttonpressevent_cb(IntPtr widget, IntPtr evnt) in /usr/src/packages/BUILD/gtk-sharp-2.12.9/gtk/generated/Widget.cs:line 2940
   at Gtk.Application.gtk_main()
   at Gtk.Application.Run() in /usr/src/packages/BUILD/gtk-sharp-2.12.9/gtk/generated/AboutDialog.cs:line 1
   at Banshee.Gui.GtkBaseClient.Run() in /home/knocte/Documentos/banshee/src/Core/Banshee.ThickClient/Banshee.Gui/GtkBaseClient.cs:line 160
   at Banshee.Gui.GtkBaseClient.Startup() in /home/knocte/Documentos/banshee/src/Core/Banshee.ThickClient/Banshee.Gui/GtkBaseClient.cs:line 76
   at Hyena.Gui.CleanRoomStartup.Startup(Hyena.Gui.StartupInvocationHandler startup) in /home/knocte/Documentos/banshee/src/Libraries/Hyena.Gui/Hyena.Gui/CleanRoomStartup.cs:line 54
   at Banshee.Gui.GtkBaseClient.Startup() in /home/knocte/Documentos/banshee/src/Core/Banshee.ThickClient/Banshee.Gui/GtkBaseClient.cs:line 71
   at Banshee.Gui.GtkBaseClient.Startup(System.String[] args) in /home/knocte/Documentos/banshee/src/Core/Banshee.ThickClient/Banshee.Gui/GtkBaseClient.cs:line 61
   at Nereid.Client.Main(System.String[] args) in /home/knocte/Documentos/banshee/src/Clients/Nereid/Nereid/Client.cs:line 54
make: *** [run] Error 1

Should I open a new bug for this? I am not sure yet if I can reproduce it reliably.

Yes, please do.

Hello guys,

Sorry I'm not as tech savvy as you guys and break down code to find things out, but there was a solution that I found and it's probably helped 8/10 people I recommend it to.  You guys are right that they problem occurs when distros switched from HAL to device kits, as in Ubuntu Karmic 9.10.

I found out that in gnome, all I would have to do is disconnect the ipod and make sure that banshee is closed.  Then open up terminal and run 'killall -9 nautilus'.  Then plug in the iPod and wait about 30 seconds, then run nautilus again by hitting Alt+F2.  After I ran this and opened up banshee my iPod worked like a charm.

Like I said I'm not as tech savvy as you guys but this is a work around for now, and if it can help you guys in anyway I would have done my deed.  So please don't bash me if you find this post irrelevant, I'm just trying to help.  Thanks to the developers for working on this.

Sorry I'm a complete linux newb, but if this bug is marked as "fixed", does that mean I should not still be experiencing it under Gnome 2.30.0 and Banshee 1.6.0.
Even the fix suggested by the last commenter won't help me :( Is the problem only fixed in a pending beta version?

Brian Z: see bug #615010