Image tags in mp3 files

[Steve Hawtin]

I just started using the LMS. In my music collection I have more than 25,000 mp3 files every one of which has an embedded image. These images have been working for years on the Apple products, Android, Firefly and Windows media servers. Imagine my surprise then at finding that not a single one of them was readable by the Logitec Media Server.

However I have some experience using Perl to handle music data. So I set debug on and delved.

It seems to me that there is a bug in Slim/Utils/GDResizer.pm, in the subroutine _read_tag(). The check:

if ( $pic->[4] ) { # offset is available

fails for some validly ID3v2 tagged mp3 files. This then returns an invalid offset to the mp3 file the scanner then checks if the magic numbers look good and gives a message like:

Slim::Utils::ImageResizer::sync_resize (130) Error resizing /data/music/data/...yway.mp3: Can't resize unknown type, magic: "\0C\1\5\5\5\a\6"

Now the way this should be fixed (IMHO) is that the magic test should be applied *before* the return:

if ( $pic->[4] )
{ # offset seems to be available
if(_content_type_file($file, $pic->[4],1))
{
# This looks like a good offset into the file
return ( $pic->[4], $pic->[3] );
}
}

NB: This code has NOT been tested

This test would then let the code fall through to the second scan, which works (at least for my files).

I realise that this change might have some other implications, so I would like to suggest that one of the developers could check that it is reasonable and add it.

I also wanted to post a message so that anyone else who has the above "Magic" message can fix it without having to spend a few hours trawling the code.

[JJZolx]

Why not test it?

You can report LMS bugs and post patches at http://bugs.slimdevices.com. Just sign up for an account.

[garym]

Hmmmm, I have thousands of mp3 files with embedded art and all work fine with LMS (and on apple stuff) without doing anything special. What format are your art files. Mine are all jpg.

[Steve Hawtin]

I have thousands of mp3 files with embedded art and all work fine with LMS...

So clearly your files don't hit this bug. What does that have to do with anything?

Are you saying that since this works for you everyone else should just live with it? Are you claiming that this is NOT a bug, because personally when I write software my aim is not to cope with a single person's setup, but rather to handle everyone's issues.

The issue here obviously has nothing to do with the fact that the images are Jpeg (which mine all are as well), it has to do with whether the selected APIC tag from the ID3v2 requires "unsynchronization" (as the documentation for Audio::Scan calls it). When the embedded image has been aligned the way that Slim::Utils::GDResizer::_read_tag() uses the result from Audio::Scan->scan_tags() fails.

The fact that it fails on one user's valid file means that this is a bug, this post could help other such cases in the future. The fact that many other users don't hit this bug really doesn't help anyone. Your post was a waste of time.

[garym]

So clearly your files don't hit this bug. What does that have to do with anything?

Are you saying that since this works for you everyone else should just live with it? Are you claiming that this is NOT a bug, because personally when I write software my aim is not to cope with a single person's setup, but rather to handle everyone's issues.

The issue here obviously has nothing to do with the fact that the images are Jpeg (which mine all are as well), it has to do with whether the selected APIC tag from the ID3v2 requires "unsynchronization" (as the documentation for Audio::Scan calls it). When the embedded image has been aligned the way that Slim::Utils::GDResizer::_read_tag() uses the result from Audio::Scan->scan_tags() fails.

The fact that it fails on one user's valid file means that this is a bug, this post could help other such cases in the future. The fact that many other users don't hit this bug really doesn't help anyone.

Uhhh, calm down. I wasnt suggesting that your post was not relevant. I was simply pointing out that I dont see this issue (as a data point from another user for helping to debug) and also pointing out a known problem with some non jpg artwork, thus my question. A bug needs to be reproducible of course by more than a single user (to account for any idyosyncratic issues related to only your setup). The suggestion to file a bug report via the official means was a good one. Then post a link to that bug here so others can vote on the bug to get the developers' attention.

[Mnyb]

...And provide you patch to the bug report it will increase the possibilty of fix by several 1000% . Patches are typically very welcome to few people with coding skills makes bug reports these days .
I do my best providing info even if don't have coding skills , but a clear cut analysis and pionters to exactly where in the code things goes wrong is worth so much more.

Bug fixes have been very very slow recently and bugzilla is a mess , but a very specific bug with a sugested fix (or idea on what to fix ) migth do it .