Re: [Rhythmbox-devel] xine metadata, and iPod HAL support

[Bastien Nocera <hadess hadess net>]

On Mon, 2004-06-21 at 08:20 +0200, David Zeuthen wrote:
> On Mon, 2004-06-21 at 02:30 +0100, Bastien Nocera wrote:
> > Heya,
> > 
> 
> Heya Bastien,
> 
> > Here's my free time's worth. First is a xine-lib metadata backend (which
> > I sent some time ago). It's not finished quite yet, but it's disabled by
> > default.
> > 
> > The rest is HAL support for the iPod source, with a bit of refactoring
> > for the existing code.
> > http://www.hadess.net/files/shots/21-06-2004.1.jpg
> > 
> > Enjoy.
> > 
> 
> Very nice, I've been thinking a long time about looking into portable
> player stuff for Rhythmbox using HAL. I don't have an iPod but I do
> happen to own one of these flash based USB drivers with mp3 support,
> namely this one
> 
>  http://www.jetflashusa.com/shop_detail.asp?product_id=16
> 
> According to specs this device happen to support output of MP3 and WMA
> and it has some voice recording function as well. I only tried the MP3
> stuff though.

The iPod is quite different from those players in that it requires a
database to be updated at the same time, and a particular hierarchy.

So, you will need special support for that device anyway.

> So, for a long term plan, which I'm proposing here :-), all I think is
> necessary is to create a capability and namespace in HAL called
> 'portable_audio_device' [1] and the device information file for *my*
> device could look like this (0x066f,0x8000 is the USB vendorId,
> productId pair)
> 
>  <?xml version="1.0" encoding="ISO-8859-1"?> <!-- -*- SGML -*- --> 
> 
>  <deviceinfo version="0.2">
>    <device>
>      <match key="info.bus" string="usb">
>        <match key="usb.vendor_id" int="0x066f">
>          <match key="usb.product_id" int="0x8000">
>            <merge key="info.category" type="string">portable_audio_player</merge>
>            <merge key="info.capabilities" type="string">portable_audio_player</merge>
> 
>            <!-- An abstract number telling how this device like the metadata to be updated  -->
>            <merge key="portable_audio_player.type" type="int">0</int>
> 
>            <!-- list of audio formats this device can play (should be MIME types) -->
>            <merge key="portable_audio_player.output.formats_accepted" type="string">mp3 wma</merge>
> 
>            <!-- list of audio formats this device can record (should be MIME types) -->
>            <merge key="portable_audio_player.input.formats_accepted" type="string">wav</merge>
> 
>          </match>
>        </match>
>      </match>
>    </device>
>  </deviceinfo>

What's "input.formats_accepted" for? In all that, you also need the
directory where the user would put the files, otherwise, you'll have to
write special code again.

> and you would have similar files for the iPod products, the Minidisc
> players (once someone fixes the ATTRAC stuff) and other existing
> products. For usb-storage and sbp2-based devices, e.g. storage devices,
> you would simply have the device tree
> 
>  - USB device        <--- tagged as portable_audio_player
>   - USB interface
>    - SCSI host
>     - SCSI device
>      - Block device
>       - Block device (partition)
>       - Block device (partition)
> 
> and search down the chain; I guess this is what you're doing today for
> your iPod? Btw, is it firewire? Can't get my firewire disk to work on
> Fedora. Oh well. 

Actually, I'm looking for the "Block Device" (the /udev/sda, parent of
the partitions). Then looking for the only mounted child.

> Continuing, for devices with a proprietary protocol (from top of my
> head, isn't the Rio500 this way?) it looks like this
> 
>  - USB device        <--- tagged as portable_audio_player
>   - USB interface
> 
> and you would use libusb or whatever is already implemented and get USB
> addressing details from the usb.* properties on the HAL device. You'd
> probably want a portable_music_player property telling how to access the
> device or something.

I don't think that there are anymore devices like the rio500 that
require a special protocol on the market, not in those kind of sizes
anyway (most of them just want a directory for you to dump the files
in).

(See http://www.ic.unicamp.br/~oliva/snapshots/FC2-firewire/ for
firewire on Fedora, basically, now, it works with 2.6.6)

> Now, with this approach we could do a lot of cool things, here's some
> 
>  1. change the hal gnome-vfs patch slightly such that Nautilus shows a
>     suitable cool icon for the device; yay, I guess we're all in for the
>     eye candy, right? :-)

All for that :)

>  2. get gnome-volume-manager to automatically launch Rhythmbox when
>     a 'portable_music_player' device is detected

Good idea.

>  3. share these details with KDE apps like JuK or amaroK since all the
>     HAL stuff happens on the system-level rather than the distro-level

Given.

>  4. automatically support newer players with weird formats without
>     recompiling Rhythmbox (only e.g. update gstreamer) since I guess the
>     re-encoding part can be automated (you want to reencode from .ogg
>     to export to your mp3/wma only player)

That sounds like a bad idea, IMO.

> The only work on the HAL details is basically the portable_audio_player
> capability and namespace that I need to put in the HAL spec and of
> course a bunch of .fdi files. The workload on the Rhythmbox side for
> this proposal sounds a bit higher though. 
> 
> How does this proposal sound?

I think that there are bits missing to support the "low-end" MP3 players
(the common flash based ones nowadays), but that there'll still be work
needed for the bigger ones that requires a database before they operate
properly. (BTW, you'll also want to detect those players that work on
top of Ethernet ;)

Cheers

> [1] : in search of a better and shorter name, but I want it to be
> descriptive as one day you might have 'portable_video_player' as well
> that another GNOME app might support, Totem maybe? And future devices
> with both video and audio would support both :-)

Hehe. I don't think Totem will have a "library" to speak of any time
soon. But just a simple "copy playlist files to portable video player"
would be easy enough :)

---
Bastien Nocera <hadess hadess net> 
It was a working class tradition, like fathers chasing kids around with
their power tools.