Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Patches
  • Category ID3 / meta data
  • Assigned To No-one
  • Operating System All players
  • Severity Low
  • Priority Very Low
  • Reported Version Rbutil git
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by rasher - 2010-11-26
Last edited by saratoga - 2010-12-11

FS#11776 - Metadata read log

This patch adds a menu entry to the debug menu which will allow the user to toggle writing of a log of files being read for metadata in /metadata.log. The filename is written before Rockbox attempts to read metadata from the file, so if Rockbox crashes when scanning for the DB, the last filename in the log should be the file that caused the crash. This should greatly help debug metadata reader problems.

Closed by  saratoga
2010-12-11 04:31
Reason for closing:  Accepted
Additional comments about closing:  

Committed in r28789.

mentioned in irc but incase it gets forgotten or someone else says the same thing… 1) fd == 0 is valid so that needs to be changed
2) the 2 write()’s should really be a snprintf() and a write() (or just fprintf() if we have that). putting a MAX_BUF array on the stack is no big deal here (get_metadata() shouldnt be being called recursively)

Fix the fd check to >= 0 (0 is a valid fd)

Comments from IRC:
“I’d do snprintf() then write instead of two write()’s” - this way a) was simpler b) doesn’t use more stack (probably not important)

“opening it every time isnt very nice either” - agreed, it’s not nice, but it gets the job done and makes sure no potential buffering messes up if Rockbox were to close with the file open. Performance is unimportant - getting the right result is very important.

I’ll try it out later with a target full of music to see how long it takes.

This patch does not work right in the simulator on any filesystem that supports permissions, as no file mode is provided in the call to open. The new log file is created without write permission, which prevents reopening the file after the first logentry was written.

The applied patch fixes the bug.

Well this was not the case in the sim. I don’t know where else it would be the case. Can’t hurt though.

In my somewhat unscientific testing, building the DB goes from taking about 35 seconds without logging to about 55 seconds with logging (e200 with 1180 music files).

Not sure there’s any reason not to commit this?

IMO this should already be in SVN.

Feel free to commit it. I probably won’t in the near future.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing