Myth ripper fails to identify CD's correctly

[christian.wittrock@…]

Hi,

I have just ripped "The essential Alice In Chains", which is a 2 CD box. I have then inserted "Belouis Some - Some People" but the Myth ripper sees this CD as being "The essential Alice In Chains"

I have the same problem with "INXS - The Greatest Hits" and "The very best of the Irish". The ripper claims the "The very best.." is "INXS..."

I have not had this problem on my Windows PC so something must be wrong in MythMusic since it does not detect the CD's correctly. I have stopped ripping my CD's as I encountered those two problems having only ripped 15 CD's...

[dekarl@…]

Can you verify if the disc ID for the wrongly identified disc is the same as the ID of the disc it gets identified as?

Taking a glimpse at ​http://code.mythtv.org/cgit/mythtv/tree/mythplugins/mythmusic/mythmusic/cddb.cpp it appears as if the disc ID alone is the primary key for the metadata cache. (should be genre + disc ID, but thats not really good either)

The issue and a possible solution (switch to Musicbrainz) are written about at ​http://blog.adamspiers.org/2011/09/13/freedb-is-dead-long-live-freedb/

[stuartm]

Are you pressing 'Scan CD' after inserting the new disc?

[christian.wittrock@…]

Replying to stuartm:

Are you pressing 'Scan CD' after inserting the new disc?

Yes, I do that and the CD Title and song titles are updated. But instead of seeing the correct titles I see the incorrect ones.

C

[christian.wittrock@…]

I can check the two ID's this evening, if someone can instruct in me how to grab this info. But I assume that this (or something similar) is the cause. That the parameters used for distinguishing between disc's are insufficient for proper identification. I would be very surprised if there is a bug in retrieving disc information.

[Lawrence Rust <lvr@…>]

This could be a problem with the cddb diskid cache. Could you execute this:

rm -rf ~/.cddb/

and then retry the CD scan. If there's no difference then it probably is a disid clash.

To show the diskids you should execute:

mythfrontend -v media --loglevel debug

and then re-run the CD scan

[christian.wittrock@…]

log file from CD scan. First Alice In Chains, next Belouis Some

[christian.wittrock@…]

I tried to clear the cache after which the CD was correctly identified. But I only have to insert and scan the Alice In Chains CD and then the Belouis Some CD is not identified correctly

[Lawrence Rust <lvr@…>]

It looks like there's a diskid clash. To diagnose what's going on could you provide the log output from

mythfrontend -v media --loglevel debug

Could you start with an empty CD drive then insert "Alice In Chains", press Scan CD, eject the CD, insert "Belouis Some" and then press Scan CD. Thanks.

[christian.wittrock@…]

Replying to Lawrence Rust <lvr@…>:

It looks like there's a diskid clash. To diagnose what's going on could you provide the log output from

mythfrontend -v media --loglevel debug

Could you start with an empty CD drive then insert "Alice In Chains", press Scan CD, eject the CD, insert "Belouis Some" and then press Scan CD. Thanks.

That is exactly what I did. Please take a look at the log file I attached yesterday.

[dekarl@…]

ohh, d0115410 != ce116f0f, but it still matches somehow

from the logfile

2012-07-11 22:43:41.679447 D  getNumTracks = 16
2012-07-11 22:43:41.773688 D  Cddb CacheGet found d0115410 folk Alice in Chains / The Essential Alice in Chains (CD 1)
...
2012-07-11 22:44:01.797911 D  getNumTracks = 15
2012-07-11 22:44:01.892594 D  Cddb CacheGet found ce116f0f misc Belouis Some / Some People
2012-07-11 22:44:01.892658 D  Cddb CacheGet found ce116f0f folk Alice in Chains / The Essential Alice in Chains (CD 1)

[Lawrence Rust <lvr@…>]

Sorry, missed that you had posted the log.

The problem appears to be that CacheGet suddenly switches to returning the previous CD info. Looking at the code and some testing shows this only happens when the calculated discID and that from cddb don't match exactly. In this case the code creates a local alias for the CD. From then on cache lookups can return incorrect values.

From testing it appears that the problem is in Qt's QMap::find. I'm not sure exactly what tickles the problem but I've added some code that works around the problems that I've seen. Perhaps you could try the attached patch (for today's 0.25 fixes) and see it that fixes it for you?

[Lawrence Rust <lvr@…>]

In cba55d74506f98e3da0575312c638562e0509dc0/mythtv:

Error: Processor CommitTicketReference failed

GIT backend not available