Confused about how metadata scanning works for local files

I really love Mopidy and I am hoping hoping that the community can assist with this problem I am experiencing. I’ve read the Mopidy documentation and searched this forum but I’ve been unable to find a solution to my problem. The relevant part of the Mopidy documentation can be found here.

The metadata attached to every file in my music collection is exactly how I like it, and this is the way I would like it displayed in Mopidy, however I am experiencing a problem where some of my metadata is being displayed differently. I have done some investigation into this issue and my findings are shown below:

The command avconv -i /mnt/sata/music/essential.mix/2013-05-25.essential.mix.armin.van.buuren.mp3 results in the following output:

Metadata: title : Essential Mix 2013-05-25 artist : Armin van Buuren album : Essential Mix track : 1 genre : Trance encoded_by : LAME 3.98.4 date : 2013

But the library scanner used by Mopidy results in a different set of metadata when the following command is run python /usr/lib/python2.7/dist-packages/mopidy/audio/ /mnt/sata/music/essential.mix/2013-05-25.essential.mix.armin.van.buuren.mp3

tags album [u'Essential Mix-SAT-05-25'] comment [u'TALiON'] track-number [1L] encoded-by [u'LAME 3.98.4'] artist [u'Armin Van Buuren'] audio-codec [u'MPEG-1 Layer 3 (MP3)'] title [u'Essential Mix-SAT-05-25-2013'] datetime [u'2013'] has-crc [False] genre [u'Trance'] channel-mode [u'joint-stereo'] bitrate [215000L] container-format [u'ID3 tag']

Why is there a difference in the metadata returned by the two different methods? I have two theories why this could be occurring:

  1. The two different techniques are accessing different metadata stored inside the same file. If so, how can I delete the metadata returned by the Mopidy media scanner so the correct metadata is used instead? I’ve tried countless ID3 editing tools and I can only see the same metadata as the avconv method which is the metadata I want.

  2. The Mopidy scanner creates a fingerprint of the file which is used to query an online database to obtain the metadata. If so, how can I override this behaviour so that Mopidy uses the local metadata instead?

I’m a bit confused, what exactly is your issue when using mopidy normally? The extra formatting characters are obviously not displayed in mopidy clients as I’m sure you’ve already seen. The only tag that seems to be missing is date. other than that, you’ve just got some extra tags there, which again, won’t be displayed by most clients.

Mopidy uses gstreamer to extract the tag data from the file, it does not use online metadata sources.


Thanks for the quick reply. Your response was exactly what I was looking for as it eliminated point 2 and enabled me to focus my efforts on point 1. The problem was data in the same tag between the different methods is completely different. For instance the title in the avconv method is “Essential Mix 2013-05-25”, but the method is “Essential Mix-SAT-05-25-2013”.

I installed eyeD3 and ran the command eyeD3 /mnt/sata/music/essential.mix/2013-05-25.essential.mix.armin.van.buuren.mp3 which showed the same tags as the avconv method.

Next, I removed all tags with the command eyeD3 --remove-all /mnt/sata/music/essential.mix/2013-05-25.essential.mix.armin.van.buuren.mp3. Running the command eyeD3 /mnt/sata/music/essential.mix/2013-05-25.essential.mix.armin.van.buuren.mp3 now shows the same tags as the method which is bizarre because the tags have been removed.

Running the command eyeD3 --remove-all /mnt/sata/music/essential.mix/2013-05-25.essential.mix.armin.van.buuren.mp3 for a second time removes a second set of tags from the file. Now, viewing the tags using avconv,, or eyeD3 shows that there are no tags on the file so I can add the tags I want and these will be used by Mopidy.

It seems there were two sets of tags on the file. Not ID3v1 and ID3v2 tags, but two sets of ID3v2 tags, an “outer” layer an an “inner” layer. I have never experienced this before. It seems that every program I had used to read the tags previously (iTunes etc) only read the “outer” tags, but gstreamer was reading the “inner” tags. Good to know! I hope others find this useful.