[gpodder-devel] GnomeVFS volume detector
- From: thp at gpodder.org (Thomas Perl)
- Date: Sat, 31 Jan 2009 04:54:23 -0700
Hey there. Very interesting ideas, I'm happy to see developer interest
in this area :) There has been some code back in April 2006 that worked
with the then-new D-Bus and was able to detect iPods:
http://repo.or.cz/w/gpodder.git?a=commitdiff;h=7c66f8080eb542d8cfa530ab89ecc859cf104532
Look at the class "iPodManager", where we received the "DeviceAdded" and
"DeviceRemoved" signals. I don't know if this would still work with the
current versions of HAL/D-Bus (that was nearly 3 years ago ;).
Anyway, on to your mail...
You wrote:
> > All vfat devices?
>
> Yes, because I have two old fs based players which are detected as
> vfat volumes, not multimedia devices. I had to create some
> /media/xyz/.dotfile for Rhythmbox to recognize it. I don't want
> gpodder users to do this. Besides, if I want to plug in a MicroSD card
> then plug it back into my mobile phone, why not? Sometimes it's much
> faster than using the USB connection.
The dotfile is ".is_audio_player" and is used to override
(wrong/missing)
HAL device information. See here:
http://live.gnome.org/Rhythmbox/FAQ
This means that everyone that is using this dotfile should be reporting
a bug against HAL so that the device will be detected correctly in the
next release. I think things like that really belong into HAL, and we as
an application should be able to ask HAL "is this a audio player?" and
it
should take care of finding out if this is the case.
I also understand that there are use cases where your audio device
storage
is only accessed via a card reader (i.e. my mobile phone has a MicroSD
card
and i sometimes pop that out and use a card reader to work on the card).
Cases like this are easily fixed by creating the ".is_audio_player" file
on
such a card. Maybe a command that creates this file on a normal mass
storage
device can be added to gPodder, so we can "solve" the card reader cases.
> > Just vfat devices?
>
> Yes, because I have never seen a PMP which would not use vfat, except
> for old HFS iPods, which are detected specifically. If you know some,
> tell me.
>
> Also, gPodder currently only supports two types of devices with
> different syncing mechanisms: fs and iPods. I don't think we need to
> detect other devices specifically, if we can use them as regular fs
> based devices. MTP devices aren't mounted as volumes anyway, as far as
> I know.
I think the HAL-based method (DeviceAdded and DeviceRemoved or whatever
they are called nowadays) would also "see" MTP devices and I also think
that we could find out if a device is an MTP device. The only problem I
could think of is that MTP and PTP (the protocol that some digital
cameras use to transfer photos, think "gphoto2") are somehow related (I
think one is a superset of the other), so we might have false positives
there in the form of a digital camera being detected as an MTP device.
Still, I don't think these problems would be show-stoppers. Just some
unknown factors that we will learn to deal with in the course of
introducing and polishing this feature, so it works for (nearly)
everyone.
> The only reason to detect other devices using the information you
> provided would be to use supported output formats, but I've seen
> irrelevant values for some of my devices (e.g., audio/aac reported
> when the device didn't actually support it). Also, my .fdi file that
> you pointed me to says that iPods only support audio/aac, which is not
> true: they support MP3s and MP4 video, too. There's no information
> about video capabilities at all, so the information is both incomplete
> and not reliable.
>
> Also, even if there were ways to detect real device capabilities using
> DBus or HAL, we could use them to:
>
> - Convert audio while syncins,
> - Download video in a more appropriate format (YouTube offers: flv, mp4,
> 3gp).
As I said above, if HAL gives wrong information about a device, this is
a bug in the .fdi files, and you should report a bug there and get the
.fdi files fixed, so other users can profit from the corrected
information.
Also, the more accurate HAL is with describing a device's capability,
the
more applications will use that information and the less code will be
duplicated
in application-specific detection code and "capability databases".
> But gPodder can't do that currently. This has to be worked on, and can
> be worked on separately from the capability detection process. For
> example, we could use a gpodder.conf file in the root of the device to
> store capabilities which the user would be asked to describe using a
> dialog with check boxes, when she first plugs in the device. Actually,
> I think that all syncing options should be removed from the global
> gPodder config file and moved to that file stored on the device, if we
> chose to actually use HAL.
Yes, I think saving the sync-related options on the device instead of in
the local gPodder database would be a good idea and also magically fix
the "support multiple devices for sync" feature request, because that
would be possible by design.
As iPods are also just mass storage devices, we can store our config
file
on there, too (probably in the same folder as the iTunesDB, so users
won't
really notice it cluttering up the root directory of their iPod).
> > gthumb for example looks for a DCIM folder to indicate its a
> > filesystem from a digital camera.
>
> That's one specific type of devices that gthumb works with, with a
> standard fs layout. Which is not the case for gPodder.
If we decide against HAL (which I think is a bad idea, because we have
to do much work on our own, again), we could use simple things like
detecting the existence of the iTunesDB file on an iPod to "detect"
iPods. We would still need some hack-ish mechanism to be able to detect
normal devices.
An option we would have: Add a "setup new device" menu item that will
list all currently mounted removable storage devices and allow the user
to configure one of them, which will result in a gpodder.conf file being
written onto that storage device, which we can use to detect this device
in the future.
..but zero-configuration HAL integration would be even more "wow" ;)
> > I don't necessarily want my 2 gig sd card from my camera
> > popping up a gpodder sync request window as well as
> > a gthumb request.
>
> This is an interface problem. I added a popup dialog box because it
> was the easiest way for me. Ideally there would be an unobtrusive
> notification area inside gPodder, like the one you see in Firefox for
> blocked popups and new extensions. I couldn't implement this because
> I'm not friends with .glade guts and the current glade file is not
> editable with GUI tools.
The "yellow bars" are getting annoying, too, I think :) Maybe just
notify the user for the first time and then show a "Sync to <device>"
at the bottom of the main window that will disappear when the device
is disconnected.
I'd be happy to get together with you and work on this. We should
probably be using D-Bus and HAL integration to do it right. I guess
D-Bus is now more stable/mature than in 2006 when we did the first
experiments with device auto-detection, so that it will work on every
distro and "desktop system" available today :)
Thomas
Other related posts:
