Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Bugs
  • Category ID3 / meta data
  • Assigned To
    Buschel
  • Operating System Sansa AMSv2
  • Severity High
  • Priority Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by LucaLeonardoScorcia - 2011-02-21
Last edited by Buschel - 2011-02-21

FS#11955 - Corrupted metadata as of r29350

Hello. I want to report that metadata display is broken on r29350 on my FuzeV2. It shows some random buffer, sometimes text, sometimes GUIDs, sometimes ‘boxes’. The problem is not present in r29348.
Rebuilding the database fails with data abort at 30800530 address 0x646c6f47. I checked the map file and 30800530 is inside strlen.

Closed by  Buschel
2011-02-21 21:36
Reason for closing:  Fixed
Additional comments about closing:  

Submitted with r29372

Quick fix. I've never dealt with the metadata code before, and don't fully understand how exactly it was broken, but this seems to be the straight forward way to do what was intended to be done at that line, and it seems to work for me.

This one should also handle the case where the tag gets removed completely. Thanks jhMikeS for pointing out.

Seems like I missed a few facts :/

I reviewed the parser this morning, but I will need some additional time to check the handling when replaygain data is contained in the tag.

If I do not have a proper solution this evening I will reject my change to ensure svn Trunk is working fine. In this case I will re-open  FS#11920  and close this one.

Sorry for the inconvenience…

The simple fix, I think, is to only do the buffer adjustment if the expression "(!tr→binary && !tr→ppFunc)" is true (works in a quick test at least). That way, a ppFunc can/should do its own adjustments (the replaygain parser does that), while still allowing unicode_munge to read all strings (and the replaygain parser needs that).

It was a bad idea to perform trimming after calling ppFunc. The different parsers which are called via ppFunc have different internal handling and need different trimming. The attached patch does four changes to the broken svn:
1) revert r29349 → fixes the error in svn
2) implement trimming inside parsegenre() → saves buffer as intended
3) implement trimming inside parseuser() in case of "ALBUM ARTIST" → saves buffer as intended
4) correct trimming inside parseuser in case of !"ALBUM ART" and !CONFIG_CODEC == SWCODEC → error in svn

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing