Almost all USB media players are missing "portable_audio_player" capability

Bug #215761 reported by Scott James Remnant (Canonical) on 2008-04-11
92
Affects Status Importance Assigned to Milestone
hal-info (Ubuntu)
Critical
Martin Pitt

Bug Description

Binary package hint: hal

This probably has a bunch of existing duplicates, but since we've already debugged this on IRC, I figured I'd just open a new bug with the pertinent information for you and weed the duplicates out in a little bit.

In order for Rhythmbox to use a portable audio player, it needs "portable_audio_player" in info.capabilities for the device, as well as various portable_audio_player.* properties.

information/10freedesktop/10-usb-music-players.fdi matches all of the various USB media players and adds the necessary portable_audio_player.* properties to them.

At the bottom, it attempts to match portable_audio_player.type being set, and if so, always adds the portable_audio_player capability.

HOWEVER as noted in a couple of places in that file, portable_audio_player.type is deprecated and many entries no longer set it.

This means that the only players which will work are iPod (sets type), Motorola phones (sets type), Archos GMini (sets type), iFP (sets type), LG Fusic Phone (explicitly adds capability) and PSP (explicitly adds capability).

The stuff at the bottom to add the capability looks logically wrong to me:

    <!-- Set common keys for detected audio player if you have special cases add
 the player below this match -->
    <match key="portable_audio_player.type" exists="true">
      <match key="portable_audio_player.access_method.protocols" contains="storage">
        <!-- NOTE: for backward compatibility until key get removed finally -->
        <merge key="portable_audio_player.access_method" type="string">storage</merge>
        <!-- NOTE: for backward compatibility until key get removed finally -->
        <merge key="portable_audio_player.type" type="string">generic</merge>
        <merge key="portable_audio_player.storage_device" type="copy_property">info.udi</merge>
      </match>
      <append key="info.capabilities" type="strlist">portable_audio_player</append>
      <merge key="info.category" type="string">portable_audio_player</merge>
      <!-- all player in the list above support this output format -->
      <append key="portable_audio_player.output_formats" type="strlist">audio/mpeg</append>
    </match>

It matches those with an existing type, then matches those with storage in their protocols list (which everything does have, I've checked) and then sets type to "generic"; which is somewhat strange since that means it overrides whatever was already set.

I think that inner match is supposed to be a previous match in the opposite direction.

    <match key="portable_audio_player.type" exists="false">
      <match key="portable_audio_player.access_method.protocols" contains="storage">
        <!-- NOTE: for backward compatibility until key get removed finally -->
        <merge key="portable_audio_player.access_method" type="string">storage</merge>
        <!-- NOTE: for backward compatibility until key get removed finally -->
        <merge key="portable_audio_player.type" type="string">generic</merge>
        <merge key="portable_audio_player.storage_device" type="copy_property">info.udi</merge>
      </match>
  </match>

So if we _DON'T_ have type set, but have set access_method.protocols, add the old compatibility keys.

THEN:

    <match key="portable_audio_player.type" exists="true">
      <append key="info.capabilities" type="strlist">portable_audio_player</append>
      <merge key="info.category" type="string">portable_audio_player</merge>
      <!-- all player in the list above support this output format -->
      <append key="portable_audio_player.output_formats" type="strlist">audio/mpeg</append>
    </match>

For everything (since type is now set) add the capability and category.

That fix works for me, does it look reasonable to you?

Related branches

(setting OMGRC because this is a rather big regression for a release we're claiming to have better media support for :p)

Changed in hal:
assignee: nobody → pitti
importance: Undecided → Critical
milestone: none → ubuntu-8.04
status: New → Triaged
description: updated
Jeremy Nickurak (nickurak) wrote :

My mp3 player (sansa e280) shows up in Rhythmbox when it's configured for MTP transfer mode, but not when it's configured for USB mass storage mode. That a symptom of this bug? (It did work in mass storage mode in Rhythmbox in gutsy)

Martin Pitt (pitti) wrote :
Changed in hal:
status: Triaged → In Progress
Martin Pitt (pitti) wrote :

Uploaded, subject to RM approval now.

Changed in hal-info:
status: In Progress → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package hal-info - 20080317+git20080318-1ubuntu4

---------------
hal-info (20080317+git20080318-1ubuntu4) hardy; urgency=low

  [ Niall Sheridan ]
  * 06_huawei_e220_ignore.patch: Some Huawei e220 devices don't work right
    if they're not ignored. (LP: #105545)

  [ Martin Pitt ]
  * Add 00upstream-update-music-players.patch: Update 10-usb-music-players.fdi
    to current upstream git head:
    - Incorporates 05_k320i.patch and fixes properties of it. Drop patch.
    - Fixes handling of portable_audio_player capability. (LP: #215761)

 -- Martin Pitt <email address hidden> Mon, 14 Apr 2008 09:44:53 +0200

Changed in hal-info:
status: Fix Committed → Fix Released
Jeremy Nickurak (nickurak) wrote :

Bug still present after upgrading to 20080317+git20080318-1ubuntu4 and restarting hal and rhythmbox.

On Mon, Apr 14, 2008 at 12:41 PM, Jeremy Nickurak <
<email address hidden>> wrote:

> Bug still present after upgrading to 20080317+git20080318-1ubuntu4 and
> restarting hal and rhythmbox.

Did you reboot to ensure that everything was properly reinitialized? I'd
think hal would be enough, but I'm not sure.

Matt LaPaglia (mlapaglia) wrote :

Is this update in the repo's yet? I just ran an update & upgrade, my sandisk media player still gives me the same errors:

[ 1054.308858] usb 5-5: new high speed USB device using ehci_hcd and address 6
[ 1054.614497] ehci_hcd 0000:00:1d.7: port 5 reset error -110
[ 1054.614503] hub 5-0:1.0: hub_port_status failed (err = -32)

Hi,

Matt LaPaglia [2008-04-14 17:07 -0000]:
> Is this update in the repo's yet? I just ran an update & upgrade, my
> sandisk media player still gives me the same errors:
>
> [ 1054.308858] usb 5-5: new high speed USB device using ehci_hcd and address 6
> [ 1054.614497] ehci_hcd 0000:00:1d.7: port 5 reset error -110
> [ 1054.614503] hub 5-0:1.0: hub_port_status failed (err = -32)

That is an entirely different bug. Your kernel does not recognize the
hardware properly. It might be a hardware or wiring problem, or a
genuine kernel bug. Please open a new report about this one against
'linux'.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments