[PATCH] [RFC] Gigabeat S support / mtpmediadevice tweaks

[Jeff Mitchell]

First, before I get to your issues, let me say this: a lot of MTP devices are 
broken.  The Toshiba Gigabeat S is *definitely* broken -- the libmtp device 
flags for it are DEVICE_FLAG_BROKEN_MTPGETOBJPROPLIST_ALL.  You should 
probably ask on the libmtp mailing list if they are aware of these issues, 
such as with folder creation and the like -- maybe by asking what 
DEVICE_FLAG_BROKEN_MTPGETOBJPROPLIST_ALL means and how it affects things.  
The README entry doesn't make it explicit that it's causing your issues, but 
I don't know when GetObjectPropList is being used in the code or in Amarok.  
But libmtp relies on user feedback to figure out what quirks devices have an 
assign appropriate flags, so it'd be a very good idea to report them.

> =1=
> Problem: The Gigabeat S considers every track to be Unknown Artist /
> Unknown Album unless it's associated with an MTP album object (i.e. it
> ignores tags in the file)
> Fix: Call getOrCreateAlbum regardless of whether there's album art
> available; have getOrCreateAlbum fill in the name and artist fields of the
> LIBMTP_album_t struct.

Sounds reasonable.

> Considerations: There's code yet in updateAlbumArt that maybe shouldn't be.

Meaning what?

> =2=
> Problem: The player doesn't recognize the disc-number tag and the MTP data
> structure has no way to represent it. I have lots of multi-disc albums in
> my collection.
> Fix: append "(Disc #)" to the album title sent to the device if there's a
> discNumber and make sure that we get separate MTP album objects as well.

It seems reasonable, but I don't know that I like this as a default.  I'm 
leaning towards you putting this as an option in the device's configuration 
dialog.  Anyone else have an opinion?

> Consideration: Now the album title on the device doesn't equal the local
> album number... so we need to replicate this transform anywhere we compare
> against the albums on the device (like checking whether a track is already
> sent). Not so cool.

I don't follow.  Of course the album title on the device doesn't equal the 
local album number...one is a string, and one is a number.  What do you mean 
by this?

> =3=
> Problem: The device doesn't support user-created folders. Folder creation
> returns success but if you try to find the returned folder ID, it doesn't
> exist. Disabling the use of folders works okay, however filename conflicts
> if two tracks have the same filename on disk can cause transfers to fail
> mysteriously.

How does this cause problems?  There is no filesystem on the device -- folders 
are only logical for users.  It is perfectly valid on a MTP device to have 
the exact same filename -- in fact, the exact same track -- multiple times, 
even if they are all contained under the same parent, because they all have 
different IDs.

> Solution: Create filenames when sending to the device, in a manner very
> similar to the "Organize Files' feature.

No, this is a bad idea.  If this isn't working for you, a better idea is to 
identify why something that is perfectly valid MTP-wise is causing issues for 
you.  Why does having the same filename on disk (which on disk I'm assuming 
is in different folders, otherwise you have bigger problems :-)  ) cause 
transfers to fail?  Certainly not for any MTP reason, so if the problem is in 
Amarok, see if you can track it down.

Thanks,
Jeff