I don't think it's good idea to automatically add a source for all usb mass storage devices.  This would mean we'd go searching on cameras and other devices for music files, wasting battery power (for some devices) and preventing the device from being unmounted.

The existing approach is for the user to add a '.is_audio_player' file to the root of the volume, but this isn't particularly discoverable.

Perhaps for devices that we don't identify as audio players, we can add a source to the source list, but not attempt to find music on it until the user selects the source and answers 'yes' to a 'treat this device as an audio player?' type question.  We could have 'yes - always' and 'yes - for this session only' responses, where 'yes - always' would write a .is_audio_player file to the device.

But why rhythmbox can't lookup usb metadata throught hald(storage.media_check_enabled)?

Rhythmbox does use hal device info to decide whether a device is an audio player.  What are you asking for here?

media_check_enabled flag usualy used by audio devices that uses mass storage profile.

It's also used by other things.  I don't think it's useful here.
We use the portable_audio_player.access_method property to detect audio players.

USB protocol specification is not so clear, many hw manufacturers uses non "standart" flags, or other combinations. It will be nice if we will have some workarounds. IMHO rhythmbox lack functionality with mediadevices other that ipod.

The portable_audio_player.x properties are not set by the device itself.  hal sets them based on device/manufacturer ID rules in .fdi files.

I really don't see how what you're proposing will help at all.  The workaround I proposed in comment 1 sounds much more useful to me.

I think we must add aditional functionality to '.is_audio_player' file(metadata, db algorhythms, suppoerted formats list...)

Now i' using alot of shell scripts to keep my devices synced with my music.

(In reply to comment #8)
> I think we must add aditional functionality to '.is_audio_player'
> file(metadata, db algorhythms, suppoerted formats list...)

.is_audio_player is designed as a temporary measure because HAL doesn't have correct information. I'm planning to add support for reading HAL-overrides out of it (like Banshee does as of a few days ago), but that is only to let RB know to use existing supported things (supported media types would probably be amongst them).

What exactly do you mean by "metadata" and "db algorithms"? The only media player db we currently support is the iPod's - but that is only no-one had worked on others. If we are to support other dbs, that will require either someone with such a device to do some development work, or one of the developers to get such a device.

>The only media player db we currently support is the iPod's

We can add backend for tools like easy pmp lib...

As far as I can tell, the only reasonable concrete idea that's come out of this is to expand our usage of the .is_audio_player file as banshee has done.

Created attachment 91799 [details] [review]
lightly tested patch

This also replaces our somewhat brain damaged attempt at filtering out playlists the device doesn't support by telling the playlist parser to ignore the mime types for unsupported formats.

Created attachment 91853 [details] [review]
use GKeyFile instead of parsing it manually

I really don't like writing string parsing code in c.

Committed (with some small fixes here and there) to svn.

I've also changed the interpretation of playlist_path to be closer to what I think the HAL spec means.

There's still some more we could do - offer to treat unknown devices as audio players, and provide a UI for entering the device information.

like you said, using .is_audio_player is a temporary measure and I assume it should fade out whenever rhythmbox will be able to get its data from an indexing engine that takes care of figuring out if there is music on the device or not.

No, .is_audio_player is a temporary measure used for an individual device until the device info is available from hal.  I don't see how indexing engines are involved here.