Problem with duplicate DB entries when ripping CDs

Purkolator · Post by **Purkolator** » Fri Jul 30, 2004 1:35 am

Here is my problem.

I am using the latest version of MM as my librarian. I rip my discs with CDex using the LAME encoder. I have a seperate server that I keep all my media on (music, pics, vids, etc). When I rip a CD, I usually do it on my main computer (not the media box) and rip it over my network to the media box. I have MM on the media box and when the rip is done and I go to look at the album in MM I always see duplicate filenames for each song. Every column in the MM main window has the same information for each set of duplicates except the "path" column. This is what a typical set of duplicate pathes would look like...

E:\OUR MUSIC\Ben Folds Five\Whatever and Ever Amen\Brick.mp3
E:\OUR MUSIC\BENFOL~1\WHATEV~1\Brick.mp3

Obviously the first path is what I expect to see. I am not sure where the second path is coming from. Both library entries most definitly reference the same file because if I delete either one using "delete from library and computer" the other one becomes unusable.

I can fix the problem by deleting the mystery entry with "delete from library" but I shouldn't have to go through that step for each album I encode.

Any thoughts?

thanks!
Brad Purkey

purkolator · Post by **purkolator** » Mon Aug 02, 2004 11:39 am

Bump

Am I really the only one who has this problem? Maybe its the voodoo lady who lives out back?

Post by **jiri** » Tue Aug 03, 2004 3:58 am

The second path is an old DOS representation of the first path (8 chars for each folder/file name). Why does it appear there? Hard to say, MM doesn't use such old paths by default. It depends on your environment, e.g. what OS versions do you use or how do you scan for new files - e.g. manually using 'Scan...' command or automatically usin gFile monitor from the Gold version? Which paths are scanned in any of the cases?

Jiri

purkolator · Post by **purkolator** » Tue Aug 03, 2004 1:42 pm

Well, I am using the filemonitor in the Gold version to scan for tracks. I have a whole share dedicated to music and I believe the entire share is being monitored (I am at work now, but will double check this when I get home). I have also tried manually scanning to see if it will clean it up with no luck.

I am running Win2k with all updates on my media server and WinXP with all updates on the box that I rip from (remember I mentioned in my first post that I typically rip over the network. My WinXP box rips the discs to the Win2k box).

... the plot thickens...

thanks for the help!
Brad

Purkolator · Post by **Purkolator** » Mon Aug 09, 2004 4:30 pm

Bumping again with a couple more clues...

I have done a bit of experimenting and I notice that if I don't rip over the network, this problem does not happen.

In other words, if I simply rip straight to the internal drive of my main 'puter and then drag the files over the network to my media box, there are no duplicate entries.

So now I have 2 fixes that I don't really want to have to use, because they both add an extra step to ripping CDs.

thanks in advance for the help!!
Brad

Post by **rusty** » Mon Aug 09, 2004 11:31 pm

Brad,

What happens if you rip on your remote box to the media box using a different application? i.e. does this only occur with CDex? or with any ripping app?

-Rusty

Purkolator · Post by **Purkolator** » Tue Aug 10, 2004 12:15 pm

I have tried encoding from both CDex and QCD player. Same problem with both apps.

Post by **Peke** » Tue Aug 10, 2004 7:41 pm

Well than problem is in networking settings. Some sort of filtering/converting.
I had same problems when few firms I worked for changed theirs netvork from old Novel Netware to Microsoft but still with Novel Server. All Longfilenames are been converted to its 8+3 representatives.

One Q, Is your Network Based on TCP/IP or IPX/SPX protocol?

munman · Post by **munman** » Wed Aug 11, 2004 2:04 pm

I have the same problem.

I did a Add/Rescan and got two sets of files as mentioned by Purkolator. It is the same physical file for both track entries listed, and the only difference is the Path.
I have an external USB HDD enclosure, with a copy of my collection on it at work. The drive connects itself as E: when started. The volume name for the external drive is 'USB160'.
There are two track entries for each file, one of which is greyed in MM.

The path for the one that is not greyed is something like:
E:\Santana - The Best of Santana\ Jingo - 01.mp3

The path for the one that is greyed out (from a previous Add/Rescan) is:
E[USB160]:\Santana - The Best of Santana\ Jingo - 01.mp3

I was able to clear my library, and re-scan the whole thing to get it fixed, but this is much more time consuming that simply adding/rescanning.

I am on Win2K SP3, and MM version 2.2.2.777.

I never noticed this before, and thought I would mention it in the event that it is a bug. Thanks.

purkolator · Post by **purkolator** » Wed Aug 11, 2004 2:20 pm

well, I have to show my relative naivete here. I think I am on a TCP/IP network, but am not really sure. It is a simple home network with DSL modem running into a Soyo router. Just set up a home network with Windows.

Does that sound right for TCP/IP

Post by **Lowlander** » Wed Aug 11, 2004 8:59 pm

Does MM show to locations in the location node? (E and E[160]).

You could delete one entry and keep the other, just make sure you delete entries in DB only and not files on computer.

In the Add/Rescan dialog do you have the two options (E and E[160]) listed?

Post by **rusty** » Wed Aug 11, 2004 11:49 pm

purkolator,

Sounds like you're running TCP/IP. One other test that might be helpful:
-Whan happens if close MM completely, and then do exactly as you indicated (copy tracks to the PC), and then run MediaMonkey and perform the scan (no filemonitor)? Does the bug still occur?

-Rusty

Post by **Peke** » Thu Aug 12, 2004 5:25 am

Maybe You can try to add IPX/SPX protocol in network Connection and try again I'm almost sure that IPX/SPX is safer.

Post by **rusty** » Thu Aug 12, 2004 7:26 am

Munman,

From your post I was unclear on one thing:
-Do you have 2 harddrives attached to your system (i.e. did you at one time have the tracks on your internal HD, and then at a later time scan them from your external hard drive? If so the change in drive serial# would account for the duplicates.
-If not, is this problem new to the 2.2.2 series? or did it exist in MM 2.2 as well?

Thx.

-Rusty

munman · Post by **munman** » Thu Aug 12, 2004 1:42 pm

Hi Rusty,

No, this is one external HD, and I had nothing on another HD.

Here's how it went:
- I copied my collection to the USB external HD. As I said, the Volume name for the external disk is USB160.
- I transported the external disk to work, and plugged it into my work computer (for a little listening music)

, and did and Add/Rescan of the external disk. Everything was fine at that point.
- Sometime later, I shut down the disk, took it home, and did a quick format of the external disk (I did not change the USB160 volume name). I then copied my latest (with many more tracks) collection back to the disk.
- I then reconnected the external disk again at work, and did a Add/Rescan of the new collection. That is when I began seeing the duplicates as mentioned above.

To remedy the situation, I did a Clear Library, and did a fresh Add/Rescan of the drive. This doesn't seem like it would be necessary though, if Add/Rescan worked like is is intended to.

I have only recently purchased MM, and have only used 2.2.2 version, so I can't say for sure about 2.2.

Hope this clarifies. Thanks for the help.

Problem with duplicate DB entries when ripping CDs

Problem with duplicate DB entries when ripping CDs

RE: Problem with duplicate DB entries when ripping CDs

idea

duplicate entries

Question for Munman