freedb only caches the disc that's used or selected

[GoogleCodeExporter]

1) Please describe the steps to reproduce the situation:
a. Insert a disc which has multiple freedb results.
b. Find that “Always use first hit” happened to choose the wrong tracklist
c. Be unable to load the right one, because the wrong tracklist was cached.
d. delete .cache/rubyripper/freedb.yaml

2) What is the expected output? What do you see instead?
Rubyripper will continue to load the wrong information from cache instead of 
offering the choice again.

3) What version of rubyripper are you using? On what operating system? The gtk2 
of commandline interface?
0.6.0, on Linux (Ubuntu).  GTK interface.

4) Is this not already fixed with the latest & greatest code? See for
instructions the Source tab above.
No, it is not.

5) Does the problem happen with all discs? If not, please attach
the output of cdparanoia -Q with a disc that gives trouble.
$ cdparanoia -Q
cdparanoia III release 10.2 (September 11, 2008)

Table of contents (audio tracks only):
track        length               begin        copy pre ch
===========================================================
  1.     7208 [01:36.08]        0 [00:00.00]    no   no  2
  2.     5764 [01:16.64]     7208 [01:36.08]    no   no  2
  3.    31295 [06:57.20]    12972 [02:52.72]    no   no  2
  4.    14204 [03:09.29]    44267 [09:50.17]    no   no  2
  5.    15272 [03:23.47]    58471 [12:59.46]    no   no  2
  6.    14482 [03:13.07]    73743 [16:23.18]    no   no  2
  7.     9689 [02:09.14]    88225 [19:36.25]    no   no  2
  8.      611 [00:08.11]    97914 [21:45.39]    no   no  2
  9.    24572 [05:27.47]    98525 [21:53.50]    no   no  2
 10.    13260 [02:56.60]   123097 [27:21.22]    no   no  2
 11.     2637 [00:35.12]   136357 [30:18.07]    no   no  2
 12.    13723 [03:02.73]   138994 [30:53.19]    no   no  2
 13.    18195 [04:02.45]   152717 [33:56.17]    no   no  2
 14.      501 [00:06.51]   170912 [37:58.62]    no   no  2
 15.    13595 [03:01.20]   171413 [38:05.38]    no   no  2
 16.    12587 [02:47.62]   185008 [41:06.58]    no   no  2
 17.    10583 [02:21.08]   197595 [43:54.45]    no   no  2
 18.      586 [00:07.61]   208178 [46:15.53]    no   no  2
 19.    12031 [02:40.31]   208764 [46:23.39]    no   no  2
 20.      957 [00:12.57]   220795 [49:03.70]    no   no  2
 21.    15955 [03:32.55]   221752 [49:16.52]    no   no  2
 22.     7070 [01:34.20]   237707 [52:49.32]    no   no  2
 23.    12510 [02:46.60]   244777 [54:23.52]    no   no  2
 24.      667 [00:08.67]   257287 [57:10.37]    no   no  2
 25.    21201 [04:42.51]   257954 [57:19.29]    no   no  2
 26.     2297 [00:30.47]   279155 [62:02.05]    no   no  2
 27.    13120 [02:54.70]   281452 [62:32.52]    no   no  2
 28.    12568 [02:47.43]   294572 [65:27.47]    no   no  2
 29.    13272 [02:56.72]   307140 [68:15.15]    no   no  2
 30.    10654 [02:22.04]   320412 [71:12.12]    no   no  2
TOTAL  331066 [73:34.16]    (audio only)

6) Please explain why this change is important for you. Also, how many
users would benefit from this change?
The workaround for the problem is not obvious, and would likely baffle users 
not familiar with caching, or likely locations for cached data.  Anyone with an 
affected disc would benefit from the change.

Original issue reported on code.google.com by hawk...@gmail.com on 26 Feb 2011 at 3:19

[GoogleCodeExporter]

By default a known result will get loaded indeed. But a simple refresh should 
work. Are you sure you actually tried this?

Original comment by boukewou...@gmail.com on 26 Feb 2011 at 9:09

[GoogleCodeExporter]

I tried "rescan disc" and it always came back with the cached result.  Is there 
some other "refresh" that should re-prompt for disc selection?

Original comment by hawk...@gmail.com on 26 Feb 2011 at 7:00