c:\program files\slimserver\server\slim.exe --logfile c:\mylog.txt --d_info --d_scan --d_musicmagic.

clear library and rebuild, then search the log for the known dupes, note any differences.

go to songinfo for two matching tracks of known duplicate albums, check location information VERY carefully and note any differences.

I'm not sure what you want me to look for in the log file� it's huge. I'll attach a zipped copy of it if you want to have a look.

Here's the location information for several songs from one of the compilation albums which SlimServer lists as 15 separate albums:
 Location: K:\MP3\_Compilations\A Very Special Christmas 1 [1987]\08 Christmas In Hollis - Run-D.M.C.mp3
 Location: K:\MP3\_Compilations\A Very Special Christmas 1 [1987]\10 Santa Baby - Madonna.mp3
 Location: K:\MP3\_Compilations\A Very Special Christmas 1 [1987]\09 Christmas (Baby Please Come Home) - U2.mp3
 Location: K:\MP3\_Compilations\A Very Special Christmas 1 [1987]\13 Back Door Santa - Bon Jovi.mp3
 Location: K:\MP3\_Compilations\A Very Special Christmas 1 [1987]\15 Silent Night - Stevie Nicks.mp3
 Location: K:\MP3\_Compilations\A Very Special Christmas 1 [1987]\14 The Coventry Carol - Alison Moyet.mp3

Another one:
 Location: K:\MP3\_Compilations\Music Inspired By The Chronicles Of Narnia\09 David Crowder Band - Turkish Delight.mp3
 Location: K:\MP3\_Compilations\Music Inspired By The Chronicles Of Narnia\08 Nichole Nordeman - I Will Believe.mp3
 Location: K:\MP3\_Compilations\Music Inspired By The Chronicles Of Narnia\11 Chris Tomlin - You're The One.mp3
 Location: K:\MP3\_Compilations\Music Inspired By The Chronicles Of Narnia\10 Kutless - More Than It Seems.mp3

And this is for one of the non-compilations that is split into two albums:
 Location: K:\MP3\Everclear\Ten Years Gone (Best of 1994-2004)\01 Wonderful.mp3
 Location: K:\MP3\Everclear\Ten Years Gone (Best of 1994-2004)\07 Learning How to Smile.mp3

Another one:
 Location: K:\MP3\No Doubt\2000 - Return Of Saturn\08 NEW.mp3
 Location: K:\MP3\No Doubt\2000 - Return Of Saturn\01 Ex Girlfriend.mp3

What differences am I supposed to be seeing?

Created attachment 1335 [details]
Copy of my log file

Unfortunately, my theory was that some albums are being created twice.  However, using "ten years gone" as a sample from your log, there is only one case of Creating Album 'Ten Years Gone.  If you look at song info for one song from each of the two instances of that album, does the link refer to the same album.id or not?

For the song "Wonderful" on "Ten Years Gone" The Album link is 
http://localhost:9000/browsedb.html?hierarchy=album,track&level=1&album=990&player=00%3A04%3A20%3A05%3Ad1%3A39

For the song "Learning How to Smile" on "Ten Years Gone" The Album link is 
http://localhost:9000/browsedb.html?hierarchy=album,track&level=1&album=1115&player=00%3A04%3A20%3A05%3Ad1%3A39

I'm guessing that album= part of the URL is the album ID, so they are different.

thanks sue.  I guess that would mean an album object is getting created somewhere, without a log entry to show it :)

If it isn't too much trouble (I'm not getting the duplicates problem in this manner), would it be possible to determine whether using MIP as the only data source shows dupes or not?  This would mean no music folder, no playlists folder.

No Problem. I just started the scan so it will be a few hours.

Part of the problem here may be that MusicMagic doesn't always group albums as a continuous cluster of songs.  It seems to sometimes throw another song in here and here.  This may fool the 'various artists' logic by introducing a different directory between groups of songs in an album.  If this is the case, I expect MIP scan by itself will still cause split/dupe albums.

I've been thinking of just trashing the MIP cache and recreating it from scratch because I have notced other weirdness of late. For example, the other day I changed an Album name from "...Hits" to "Hits." I refreshed the songs in MIP and verified that the new album name was showing correctly there. Today, it was back to being listed as "...Hits" in MIP! I refreshed the songs again and it went back to "Hits" but will it stay that way this time? That's just one example but there have been other times where I make changes to tags, reresh the songs in MIP and some of the changes don't stick.  Since the name change, MusicMagic really does seem to have lost its "magic." I enjoy using it when it works, but lately it seem to run slow and cause a lot of problems. 

There is definately something wrong in the import parsing OR the API.  I'm getting tracks that come in to slimserver with simply the wrong data.  I think I can reproduce this problem reliably now, but I am unsure how to share the test suite, since it does not seem to be tied to the track itself.  The tags are correct, MIP seems to list it right in it's own UI, but what slimserver gets by the time it hits DBIStore is incorrect.  Will try to dig up more.

KDF et al, are y'all looking at fixing this in the 6.3.1 branch or in 6.5?

I'm still just trying to find out what is getting buggered up in 6.3.1 to cause the bug.  I haven't even thought about where/how to solve it yet.

It seems that in my case, it is being caused by a compilation album mixed in with other songs not from that album in the same folder.  When track not on that album comes in, the info is stored for 'lasttrack'.  Then when a track compilation album is encountered again, the search for teh existing album fails becuase it looks for an album with that artist, which may not be the same as any other artist already on compilation album.  Thus, the search fails and a new album is created.

I dont' have the ability to fix tags on this setup, so I don't know if setting the compilation tag clears this one up. Going by the code, I'd say that having compilation=1 in ALL tracks should solve what I'm seeing.  However, I'm unsure if musicmagic passes this info through the api, but since we readTags, it should be covered.

As it stands...I don't have a case for reproducing non-compilation splitting/duplication.

Well, I don't know what the deal is, but I left that rescan going for at least 8 hours untouched and it says it is still scanning. Looking at what's it's done so far, it looks like the non-compilations are only listed once, but the compilations are still being split.

So last night I did a clean start with MIP by trashing the default.m3lib file and creating a new one. Then a did a rescan from SS without music folder or playlist folder. The non-compilation duplicates are gone, but the compilations are still listed multiple times.

Two obvious cases to look for with compilations:

check for dupes of track number, as slimserver will assume multiple albums if a song comes along with a track number matching one that already exists.

multiple compilation albums in the same folder. Musicmagic doesn't group the song list by album through the API, so if one album is coming through, interrupted by another, then back slimserver will no longer have a match on the compilation album for that folder..  Since it can't match by artist, compilation albums rely on being in the same folder.

The track numbers are correct. I'm pretty meticulous about my tagging, and these are albums that have been in my collection for years, and were previously listed correctly up until the switch from 6.2 to 6.3. And don't forget they are reported correctly when MM is taken out of the equation.

My compilations (actually all my music) is organized as one album per folder. 
Example: K:\MP3\_Compilations\A Very Special Christmas 1 [1987]

By the way, I have a few compilations where I have used the albumartist tag. These are not listed as duplicates. I could work around this just by filling in albumartist for all of them, but I'd like to help you resolve the issue.

Musicmagic works differently from folder scan.  Folder scan can separate by folder.  Musicmagic can serve in awkward order. I never forget that difference. 

For 6.3 putposes, using compilation tag or albumartist tag might be a valid resolution as the real fix is likely going to take some more major refactoring than might be desired for a 6.3.1 build.  

I'll see if I can figure out some useful new debugs to add so that we can isolate compilations issue, since the only thing I can see directly really does require one of the two conditions I've listed above.  If neither of these exist, I'm at a loss with the current info.

Well, thank you for your effort. I'll do the albumartist workaround for now because scrolling past 74 lines of "a very special Christmas" is starting to annoy me in July. I'll stay CC'd on this if you need more info/testing help� it's always a good work avoidance tactic. ;-)

Sue, so are you setting albumartist to 'Various Artists' or some other string that is the same for all the tracks on the album?  Thanks for any info.

some other string that is the same for all the tracks on the album? < � this one. Usually I use (VA) followed by the name of the album. That way they sort together in the artist list, but are still listed separately by album.

Thanks Sue, I was basically fishing for good advice for other users.  :)

Now I need to get MusicIP set up on one of my 6.5 machines and really get this all sorted out.

FWIW, this is happening for me in the latest 6.5 (SlimServer Version: 6.5b1 - 8880 - Windows XP - EN - cp1252) as well.

Jordan - do you have both a Music Folder & MusicMagic enabled?

Thanks

I did have both enabled, yes.  When I cleared out the music folder path the duplicates stopped appearing.  I also disabled iTunes at the same time, so I'm not sure which one of them was responsible for the dupes.

Ok, thanks. Could you turn iTunes back on, and see what that does?

Then could you add your Music Folder back? Make sure it's the same case as the path you have in MusicMagic.

If the duplicates are still there, could you send the Location: string (found at the Track Info level) for two of the duplicated tracks?

Thanks

Dan,

I forgot which bug I was replying to earlier - I'm currently using 6.5, but I can go back to 6.3 if it will help you fix this bug.  I had a very similar problem in 6.5 (see bug 3949) where when I had iTunes enabled and had my music folder path entered and I got duplicates and other strange behavior.  Should I test in 6.5, or roll back to 6.3 and test there?  What would be the most helpful to you at this point?

Also, when I test, should I do a clear and rescan, or just a "new and changed" rescan?

I'm assuming I should do 1 run-through with MM + iTunes and another run-through with MM + folder path, then maybe one run-through with all 3?

Thanks,
Jordan

Subject: Re:  Many albums duplicated in 6.3 with MusicMagic

It would be most helpful to test with 6.5

We're not doing any more work on 6.3, and 6.5 will be released in ~2 weeks.

Testing with any and all combinations of Music Magic, iTunes & Music Folder will help.

Thanks.

Jordan / Anyone - updates here?

MMM with 6.5 is working fine for me, with a Music Folder set as well.

Thanks

I must be missing the obvious... I wanted to do some tests using MIP and 6.5 - but I can't find any trace of MIP in SlimServer. I'm running MIP on the same machine. The plugin is active, d_musicmagic gives me the following lines in the logs:

2006-09-10 22:46:10.1738 Requiring Plugins::MusicMagic::Plugin plugin.
2006-09-10 22:46:10.2076 MusicMagic: Testing for API on localhost:10002
2006-09-10 22:46:10.8213 MusicMagic: MusicIP Mixer. Version 1.7
2006-09-10 22:46:10.8231 MusicMagic: get filters list
2006-09-10 22:46:10.9412 MusicMagic: get moods list

So this seems to be ok. But there's neither the port setting nor the "use MusicMagic" nor a MusicMagic page in the settings. What am I doing wrong?!?

dean reworked the settings pages yesterday.  looks like he missed the plugins that add items to the basic settings page.

I'm back in the game, thanks kdf :-)

(In reply to comment #28)
> Jordan / Anyone - updates here?
> 
> MMM with 6.5 is working fine for me, with a Music Folder set as well.
> 
> Thanks
> 

Dan,

Just installed the latest 6.5 nightly and am doing a clear & re-scan with MM enabled and a music folder path.  I'll post my log/results when the scan is done.

Well I tried a full clear & rescan with the latest nightly build of SlimServer (details below) and I did not get duplicate albums, but I did get another problem where only the first track of mixable albums was actually mixable.  I've posted my log file and info in bug 3949. 

SlimServer Version: 6.5b3 - 9697 - Windows XP - EN - cp1252
Perl Version: 5.8.7 MSWin32-x86-multi-thread
MySQL Version: 5.0.22-community-nt 
Music Magic API v 1.7

I'm going to close this bug then, as bug 3949 is a different issue.

Thanks