[Fwd: Re: [PATCH] [RFC] Gigabeat S support / mtpmediadevice tweaks]

[Jeff Mitchell]

Forgot to CC here.

-------- Original Message --------
Subject: 	Re: [PATCH] [RFC] Gigabeat S support / mtpmediadevice tweaks
Date: 	Wed, 07 Nov 2007 14:03:23 -0500
From: 	Jeff Mitchell <kde-dev at emailgoeshere.com>
To: 	Andrew Rodland <arodland at comcast.net>
References: 	<200711062116.59194.arodland at comcast.net>
<200711070837.23264.kde-dev at emailgoeshere.com>
<200711071254.56748.arodland at comcast.net>



Andrew Rodland wrote:
> 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.
>   
Do comparisons between the two ever happen?
>>> =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.
>   
You may want to talk to libmtp folks.  This smells like a problem with
your device.  Everything on a MTP device is an "object" identified by an
"object id" and is a certain type, such as folder or file.  And it's all
flat, it's just that some objects are assigned "parents".  I know you
can do this because I've run into issues before when I was trying to
make a filesystem display onto a MTP device  :-)

I wonder if your Gigabeat S is storing the tracks on a filesystem inside
the device, like FAT32, and keeping the MTP information in a database
somewhere.  That could certainly give it these kinds of problems.  But
again, AFAIK, this would mean a broken device on your part...

--Jeff