Rockbox database with MP3s with large ID3 tags

[rhinobanga]

Hi Folks,

I asked RB to build it's DB cache on my 80GB iPod and noticed a few of my MP3 tracks were missing or "unassigned".

So I downloaded the source code, built the simulator and managed to reproduce the problem on one of my tracks.   Media players on my PC handled the track in question just fine so I hex edited the file to look at the tags.

I noticed that this track had a very large COMM tag right at the beginning, 1200 bytes.

Running the sim under gdb I noticed that the mp3.c:setid3v2title function used the entry->id3v2buf area for a buffer, which under the sim was 900 bytes.

However the code handled large frames by skipping (lseek) to the next one.

Then I noticed this code:

Code: [Select]

                /* Seek to the next frame */
                if(framelen < totframelen)
                    lseek(fd, totframelen - framelen, SEEK_CUR);

Which got me thinking, if the code seeks to a new position then the internal buffer and buffer position must be invalid but the buffer position is not being reset.

So as a test I changed the code to:

Code: [Select]

                /* Seek to the next frame */
                if(framelen < totframelen)
                {
                    lseek(fd, totframelen - framelen, SEEK_CUR);
                    bufferpos = 0;
                }

Which solved the problem.   Now my files are being properly tagged under RB.


Can someone confirm this is a valid change?



Regards,

Jamie.

[gevaerts]

Could you open a task on the tracker for this? This looks very promising, but I don't know this part of the code at all and lots of developers don't read the forums. I'd hate this to get lost.

[rhinobanga]

Done ... http://www.rockbox.org/tracker/task/10240