musicmagic issue.  they know about it, and are working on it.

KDF: is this something we'll need to address in our software or is it purely on the other side?

it seems to be purely MusicMagic, and I believe currently it is ok on linux versions (is for me).  Windows version is not yet handling unicode in the data delivery so I'm not sure what we could do about it. Perhaps more users need to bring it up in the Predixis forums.

Some of the issue is being covered here:
http://forums.predixis.com/index.php?showtopic=1874&hl=unicode&st=15

Peter - can you try the latest MusicMagic - http://www.musicip.com/ and see if this issue still exists?

Thanks

Peter, this seems to work for me now.  Are you still having problems?

Hi,

I've just tested again with official 6.2.2 release and latest MusicIP. First I rescan without MIP, and everything is perfect. Then I start MIP and stop/start Slim and finally I enable MusicMagic. After this rescan i get over 1000 dublicate song entrys. Album and artist count is uncnanged. All songs that are dublicated are with Danish characters (������).
Another remark: I un-installed MusicMacic and MusicIP and installed the newest version from start saving only my reg-key and the library file. The songs are not dublicated in MIP, only in SlimServer.

Using Jun 20 6.3, and MusicIP 1.6RC2 (not 1.6b2), I'm not seeing duplicates.
Loading ONLY from musicIP (no music folder setting), the albums are still showing up as garbled characters, but with a music folder setting (thus combined data from folder and musicIP import) the characters may display properly and data appears merged...depending on which importer gets to the files first:  Loading with both enabled and an empty db leaves the characters looking wrong, but merged.  Scanning folders only then enabling MIP shows the right chars.

So, nearly there, but something still isn't right.

KDF, so is this more problems from the MusicMagic side, or is this our bug?

Hard to say offhand.  Linux seems to work fine, so it seems to be a windows thing (at least in my case).  I can never be sure if the international setup is working right on my windows machine at work.  The duplication was due to mangled urls, since we match based on that.  The bad display is due to recognising the matched url and not overwriting existing data.

Question is, whether the data is bad from MIP or simply bad because slimserver isn't doing the unicode conversion.  Arguments for the former would be that slimserver works when the data is in linux, so clearly it IS converting at some point.  Argument for the latter would be that perhaps slimserver isn't determining the codeset correctly when it is talking to the API under windows.

I really can't trust my setup.  After all, I can see innternational characters in the slimserver UI, but then on bugzilla the international chars that get pasted in comments never look right.

Certainly users need to be working with MIP 1.6RC2 at minimum, and I expect Dan will know better who is at fault.

it seems that the MusicIP forums still have this indicated as an ongoing issue.

Okay, well, we're down to the wire on 6.3 now.  I'll shift this to 6.5 and leave it assigned to me for another look.

I'm new to MusicIP - and it's problems. But I can't confirm the case kdf mentions: my MIP is having problems with non-latin characters on _Linux_, but not on Windows... But then this is still 1.6b2 (which is the official latest release, isn't it?) - where would I get the rc2?

A few more details: MIP 1.6 is now official and final (according to the support). But it still has some issues with non-latin characters on Linux: some of my artists/albums/songs (eg. "Bj�rk", "S�o Vicente"...) aren't found/listed by MIP due this issue. That's clearly a MIP problem.

I then dumped the slimserver DB, removed paths and scanned the MIP collection. I then see VA albums listed separately for every artist, though I've set Slimserver to group them.

After adding paths and scanning again I see the missing albums, but they're obviously not mixable.

SlimServer Version: 6.3.1 - 8425 - Linux - DE - iso-8859-1

What you are observing now is bug 3733.  One user has reported success with a workaround involving setting the ALBUMARTIST tag for affected tracks to "Various Artists".  It's currently in my list to evaluate how well MusicMagic works with the upcoming 6.5 release.

I see MusicIP 1.7 seems to be out.

only for Windows.  Mac and Linux are still 1.6 officially.  Linux does have a 1.7 beta.
1.7 for windows claims to fix the accented chars on their end.  However, I have been unable to see the improvements.  I do have some files for testing, but they don't appear to be valid any longer (garbled by ftp I guess).

I just did a rescan using MIP 1.7, SlimServer (trunk): some files with eg. umlauts in their name, show up, but are not mixable. On the other hand there's "Bj�rk" which (as artist) is mixable, but the albums/songs are not. And then there's "Ali Farka Tour�" with the album "Niafunk�" which is perfectly mixable - as I've remove all non-latin characters from folders and filenames (but left them in the tags).

I can't find any duplicated songs right now. All seem to show up once, but not mixable, if there's some non-latin character somewhere in the path - a MIP issue, I assume.

Created attachment 1506 [details]
Import songs with non-latin characters in the file path

With this small change SlimServer would now display Bj�rk's song as mixable, too. But mixes based on one such song will create a one song playlist with exactly that song (bug 3949?).

Subject: Re:  MusicMagic: Songs with national chars get duplicated

Michael - see the utf8encode_locale() call a few lines below.. I'm wondering
if MMM changed how they are presenting latin1 files.

Can you see if the line below has any affect?

Thanks

ping

> Michael - see the utf8encode_locale() call a few lines below.. I'm wondering
> if MMM changed how they are presenting latin1 files.

Yeah, I had seen that, but it did not seem to be working for me.

> Can you see if the line below has any affect?

Which line?

I don't want to make any changes here this late in the game, until Chris & I have had time to test on multiple platforms.

Fixed in change 10068