Bug 489176 - libmtp doesn't see the ogg files
libmtp doesn't see the ogg files
Product: Fedora
Classification: Fedora
Component: libmtp (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Linus Walleij
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2009-03-08 09:29 EDT by nicofo
Modified: 2009-03-10 16:46 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-03-10 16:46:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
amarok log (19.44 KB, text/plain)
2009-03-09 19:10 EDT, nicofo
no flags Details

  None (edit)
Description nicofo 2009-03-08 09:29:41 EDT
Description of problem:

libmtp only lists the mp3 files, not the ogg !

I don't see the ogg files in my device (they aren't not listed using libmtp) though they are well present on the device :

=> I can transfer ogg files from my computer to my mp3-device without any
problem using for instance amarok or gnomad2 (the ogg are well transferred on
the device - I can listen to them: OK)

=> BUT amarok or gnomad2, ... don't show them: they only list the mp3 files
that are on the device, not the ogg.

Additional info:
- I have libmtp 3.6.1 version under Fedora 10, but this bug was already present with older versions of libmtp (at least the one of Fedora 9)
- I have a Samsung YP-T10
Comment 1 Linus Walleij 2009-03-08 19:02:39 EDT
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

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.)
Comment 2 nicofo 2009-03-09 19:10:07 EDT
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).


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.
Comment 3 Linus Walleij 2009-03-09 19:38:32 EDT
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! :-)
Comment 4 nicofo 2009-03-10 16:46:08 EDT
OK, I understand. Strange behavior from Samsung to consider the ogg as Unknown...

Anyway, thanks for your answer !

Note You need to log in before you can comment on or make changes to this bug.