Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[rjm]

I am cleaning up my CD Database by removing discs I do not want to track.

I am observing some weirdness in that it seems I need to delete an item twice before it is removed from the CD Database.

[marko]

I've not cleaned mine up for a while now, but when I last did that job, I noticed that too. Choosing the option to remove from library and permanently delete from disc gets the delete done in one go.

Now, seeing as you brought up the cd\dvd database, I thought it a suitable time to reiterate a post I made away back in December of 2004....

I've not looked in mine for absolutely ages. The last few days I've been paying it some attention while I hone a few smartlists for searching all of my media, both hard drive and cd based, from one list.

The first thing I noticed was that it had catalogued every single cd/dvd that mc had "seen". This meant that there were numerous cd's and dvd's catalogued that really, I just didn't want or need to be there.

I'm talking about things like device driver discs, game dvd's and cd's and magazine cover discs.

I went through the database deleting all these unwanted entries, then began to look at ways to avoid this happening in the future. So far, I've been unable to sort out anything that works, so figured I'd bring the problem to interact for a shakedown...

I got to thinking that for the most part, I actually like the way that it silently catalogues the cd's in the way that it does, so I don't *think* I want that to change.

What I think would be neat, is if the "don't import previously deleted items" functionality could be extended to disc volume names, because as sure as eggs is eggs, over time, most of the cd's/dvd's I've just removed from the database will be re-imported and I'll need to remove them. Again.

Anyone else got any ideas or suggestions?

-marko.

I still feel that the "ignore previously deleted items" option should be honored as far as volume names and the cd database are concerned.
After all this time, I still have to periodically go through the database and remove program and game discs from the database.

Also, there would seem to be some annoying persistance of memory going too. What I mean is this...
If I have a data cd or dvd in the database with a volume name of mp3-1 and delete from library and disc, it is indeed apparently gone from the database, but, if I then make another cd or dvd and give it a volume name of mp3-1, MC adds it to the database as 'mp3-1 (1)'. Why? ? In my experience, MC only does this when two names collide, but as there is no pre-existing mp3-1 volume name in the database surely this should not happen?

-marko.

[rjm]

Also, there would seem to be some annoying persistance of memory going too. What I mean is this...
If I have a data cd or dvd in the database with a volume name of mp3-1 and delete from library and disc, it is indeed apparently gone from the database, but, if I then make another cd or dvd and give it a volume name of mp3-1, MC adds it to the database as 'mp3-1 (1)'. Why?  In my experience, MC only does this when two names collide, but as there is no pre-existing mp3-1 volume name in the database surely this should not happen?

marko,

I am so glad you raised this issue. I was about to launch a thread on this topic. I too have noticed this behavior and it really bugs me because I have several volume names that I am unable to name as I desire without the "(1)" suffix.

I am almost certain that MC maintains a database of unique volume names and that it is hidden from our access.

I think JRiver should delete (and make available for reuse) the volume name when the related disc is deleted from the CD Database. Or as an interim measure, assuming my assumption is correct, tell us which JMD file we can hack.

As an aside, I would love to know the algorithm used for identifying optical discs. Is it related to the volume label I give the disc when I burn it? And therefore, do I need to ensure my volume labels are unique? I suspect not, but would like confirmation.

[Matt]

MC does force volume names to be unique, but this seems unnecessary.

We'll remove this in a coming build.

[MrC]

MC does force volume names to be unique, but this seems unnecessary.

We'll remove this in a coming build.

Interesting.  Perhaps this requirement on volume names is a contributing factor in a bug I reported some time ago.  MC create two volumes both named "TH", and it refused to allow any changes to the volume name thereafter. I had to delete both entries manually, and re-insert the CDs.