Bug 489176

OK well Bug 485627 was perhaps masking the worse problem, that the
code that crashed libmtp wasn't doing what it should in the end
either.

I refactored the code again, if you still have a CVS compile up,
could you see if my latest fixes helps any?

Else I'll have to go and add a few tracepoints in the code to see
if there is something strange with the tracks. If you look at the
filedump using e.g. "mtp-files" does the OGG tracks end with a
proper ".ogg" extension? (This is what libmtp has to look at on
these devices, since they cannot tag it as OGG proper.)

Created attachment 334589 [details]
amarok log

I have just compiled your last version => that hasn't changed.
And yes, the files have the ".ogg" extension (I used the "files" command and I checked on the device as well).


BUT...

I have found something that can interest you: in fact, I have just seen that the ogg files are well listed by libmtp, BUT with only the tag "Title of the song" (that's why I didn't find them first: the ogg files are listed under "unknown artist/unknown album").

The odd thing is that, after I copy an ogg file from my amarok collection to my T10, the ogg file appears well on my T10 collection (with the correct tags) - BUT when I disconnect my mp3 and reconnect it, it's as though the tags have disappeared and the file in now under "unknown artist".
If I copy the ogg file from my mp3 to my PC ==> I see that the tags are still present.

==> To summarize, I think there is a problem in libmtp to read the tags of the ogg files ?



-----------------------------------------------------------------------

Rem: don't know if it is related: when I run gnomad2 for instance, I have this:
     $ gnomad2 
     Queried T10                  
     MTP extended association type 0x00000001 encountered
     MTP extended association type 0x00000001 encountered
(last line appears a lot!!)

When I run amarok, I have also these lines, plus a "LIBMTP PANIC: Unable to initialize device" (but it works): see log attached.

Aha yeah actually that's expected behaviour, not a bug but a feature.

The problem with the T10 and other Samsungs is that they do support
the OGG files, but they have to be marked as "unknown" files, the
device will only recognize them by the extension ".ogg" This means
that they only get the metadata applicable to such files. The set
of metadata available for a certain filetype is actually defined by
the device and for the T10 it looks like this (from the mtp-detect log):

   3000: Undefined Type
      dc44: Name STRING data type GET/SET
      dc01: StorageID UINT32 data type ANY 32BIT VALUE form READ ONLY
      dc04: ObjectSize UINT64 data type READ ONLY
      dc07: ObjectFileName STRING data type GET/SET
      dc09: DateModified STRING data type GET/SET
      dc4f: NonConsumable UINT8 data type enumeration: 0, 1,  GET/SET
      dc02: ObjectFormat UINT16 data type ANY 16BIT VALUE form READ ONLY
      dc0b: ParentObject UINT32 data type ANY 32BIT VALUE form READ ONLY
      dc41: PersistantUniqueObjectIdentifier UINT128 data type READ ONLY
      dc03: ProtectionStatus UINT16 data type enumeration: 0, 1,  READ ONLY
      dc97: EffectiveRating UINT16 data type range: MIN 0, MAX 100, STEP 1 GET/SET
      dc8a: Rating UINT16 data type range: MIN 0, MAX 100, STEP 1 GET/SET
      dc91: UseCount UINT32 data type ANY 32BIT VALUE form GET/SET
      d901: BuyFlag UINT8 data type ANY 8BIT VALUE form GET/SET
      dc0d: Hidden UINT16 data type enumeration: 0, 1,  GET/SET

Contrast this to the metadata tag set for MP3 for example.

The most critical missing key metadata entries are:

      dc8b: Track UINT16 data type ANY 16BIT VALUE form GET/SET
      dc99: OriginalReleaseDate STRING data type GET/SET
      dc46: Artist STRING data type GET/SET
      dc8c: Genre STRING data type GET/SET
      dc9a: AlbumName STRING data type GET/SET
      dc9b: AlbumArtist STRING data type GET/SET

This means it is practically impossible to store any metadata about Ogg
files in any standard way.

There are hacks you could think of of course. Like using the "Name"
field in some creative way with custom field separators, or
even creating some metadata holder file (that would need to be updated
every time a file was added/modified/deleted) for the devices wit this
problem. Quite a lot of implementation work but surely possible,
however to do it you really need a device.

Patches welcome! :-)

OK, I understand. Strange behavior from Samsung to consider the ogg as Unknown...

Anyway, thanks for your answer !