Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Rockbox mail archive

Subject: Remove broken fuzzy runtime-data resurrection for next release? FS#12076

Remove broken fuzzy runtime-data resurrection for next release? FS#12076

From: sideral <sideral_at_rockbox.org>
Date: Sun, 12 Jun 2011 00:21:55 +0200

Rockbox developers,

The Rockbox database has a resurrection feature that allows it to
recover runtime data (playback statistics and resume info) for files
that have been renamed or moved into another directory. This feature
relies on fuzzy tag matching to identify known tracks with a new
filename: A track is considered known if it has the same playback
duration of a previously deleted track, and if at least two of the
following tags match: artist, album, title.

Recently it turned out that this matching is a little bit too fuzzy and
can resurrect stale runtime data for tracks that are actually new. This
problem is typically caused by podcasts with episodes that all have the
same length and very similar tags -- typically radio recordings.
FS#12076 has the complete story.

In current SVN, I have fixed this problem by requiring that all of the
artist, album, and title tags match before any data is resurrected,
thereby effectively removing fuzzy matching. Resurrection now only
works for files that were either renamed or retagged, but not both at
the same time.

Robert Kukla views this new behavior as a feature regression, and I tend
to agree with him. It might be possible to restore fuzzy matching with
a better method for distinguishing known from new tracks (again, see
FS#12076 for details). But I likely won't be able to implement and test
a new method before the next release.

This raises the question what should be done in the meantime. I prefer
the current intermediate behavior, which is more correct (doesn't
accidentally stick stale runtime data on new tracks) but looses fuzzy
matching. Robert seems to prefer restoring the old behavior, which
would fix the feature regression but reintroduce the bug.

I intend to keep the current intermediate behavior in SVN (and hence, in
the next release) until a good fix has been found, unless a developer
NAKs this resolution. If you think we must avoid the feature
regression, please speak up.

Cheers,
sideral
Received on 2011-06-12


Page was last modified "Jan 10 2012" The Rockbox Crew
aaa