Rockbox mail archiveSubject: Re: Remove broken fuzzy runtime-data resurrection for next release? FS#12076
Re: Remove broken fuzzy runtime-data resurrection for next release? FS#12076
From: Jonathan Gordon <jdgordy_at_gmail.com>
Date: Sun, 12 Jun 2011 10:12:05 +1000
On Jun 12, 2011 8:24 AM, "sideral" <sideral_at_rockbox.org> wrote:
> 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.
My immediate response is that I think the old behaviour was broken and would
easily make mistakes. I think a good fix would be to keep a list of possible
track moves and add a ui to give the user the choice to import or not.
Received on 2011-06-12