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

[Andrew Rodland]

On Wednesday 07 November 2007 07:37:23 am you wrote:
> > =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?
>
I misspoke, I meant that the album title on the device doesn't equal the _ 
album title_ in the collection (because we stuffed a disc number string into 
it). As such comparisons between the two of them will screw up unless we 
mangle the local album title for comparison in the same way that we mangled 
the title for sending to the device.

> > =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.
>

Well that's definitely not what I'm seeing here -- I didn't go deep into the 
MTP internals, but the player was definitely sending back some sort of 
an "already exists" error on LIBMTP_Send_Track_From_File if 
trackmeta->filename was set to the same value as a track that had been sent 
before, even if it was a completely different track in all other respects. 
Adding trackmeta->filename mangling made the problem entirely disappear. 
Still, I'll try to nail it down further.

Andrew