PDA

View Full Version : Slim 6.5.1 and MusicIP problems



chris.mason
2006-10-03, 03:44
I upgraded to the latest 6.5.1 build last night (SlimServer Version: 6.5.1 - 10130 - Windows XP - EN - cp1252), and did a rescan, ending up with 0 albums.

I have MusicIP server installed and running, and everything worked correctly under 6.5 (official release). If I switch off "Use MusicMagic", and rescan, my library reappears. I've checked my MIP configuration, and that everything is running, but whenever I switch "Use MusicMagic" back on and rescan, I get no music.

Anybody else see this behaviour?

C>

jeffluckett
2006-10-03, 04:05
I posted another MusicIP related problem for this nightly in this thread:
http://forums.slimdevices.com/showthread.php?t=28214

Basically, I did a full rescan and it did manage to import my library (1036 albums, 6147 songs, 704 artists), but it crashes the server and scanner (presumably)just before importing the MusicIP information, as none of my music is "mixable". If I manually restart the server, it's fine as long as I don't initiate a scan.

I'm using the latest nightly (10130) on Win2k3 Server.

chris.mason
2006-10-03, 05:52
Thanks Jeff, maybe its a related issue..?

I've not got any problems with accented characters coming from MIP, but I used to have problems. I spent some time investigating this and discovered the issue lay with file and directory names (at least on Windows) that had accented names. I figured out that the MIP API or SlimServer were not correctly passing/receiving file/directory names with extended characters, which meant that when Slim looked for the files on the disk, it couldn't find them.

I then decided to just remove the extended characters from the file and folder names, keeping the track name tags intact with their accented characters. This has worked perfectly ever since.

Chris.

jeffluckett
2006-10-03, 06:00
Thanks Jeff, maybe its a related issue..?

I've not got any problems with accented characters coming from MIP, but I used to have problems. I spent some time investigating this and discovered the issue lay with file and directory names (at least on Windows) that had accented names. I figured out that the MIP API or SlimServer were not correctly passing/receiving file/directory names with extended characters, which meant that when Slim looked for the files on the disk, it couldn't find them.

I then decided to just remove the extended characters from the file and folder names, keeping the track name tags intact with their accented characters. This has worked perfectly ever since.

Chris.


Getting rid of the extended characters would certainly be a work-around to that issue. However, I actually have quite a bit of latin music and Classical music in my library ... both of which tend to have quite a bit of extended ASCII characters in the names ... so it would be quite an undertaking to clean up the file and folder names. Additionally, I use MusicBrainz for tagging and renaming ... and it always uses 'proper' spelling with accented characters. Not really a viable option for me.

I had heard that the issue was to be addressed in 6.5.1 ... but since I can't complete a scan, I can't tell if that's true yet.

chris.mason
2006-10-03, 06:03
Yeah, I agree its not an ideal solution, and not one I really wanted to implement, but it was the only way I was going to get my classical music to appear properly in Slim.

If I recall, I used tag&rename or mp3tagger (can't remember which) to change the files/folder names. There was a simple macro which you could run over all the file names so it wasn't too onerous a task.

gutted
2006-10-03, 06:26
Jeff - do you store MIP music fingerprint into your tags? If so, then in theory, a quick(ish) test would be to create a new music folder (test, for example) with only 1 track in it. You could use MIP to store fingerprint into the track tags and then get Slim to try and scan the track in; if that fails, try removing the fingerprint data and rescan the single track again.

If it is, indeed, something to do with fingerprint data and you performed the test above you could log it as a bug (?)

jeffluckett
2006-10-03, 07:31
Jeff - do you store MIP music fingerprint into your tags? If so, then in theory, a quick(ish) test would be to create a new music folder (test, for example) with only 1 track in it. You could use MIP to store fingerprint into the track tags and then get Slim to try and scan the track in; if that fails, try removing the fingerprint data and rescan the single track again.

If it is, indeed, something to do with fingerprint data and you performed the test above you could log it as a bug (?)

Ok, here's what I did:

I created a folder, and added a single file (without accented characters to keep things simple).

The track is Zenyatta Mondatta-11-The Other Way of Stopping.flac, and it did indeed have MisicMagic fingerprint tags in it.

First, I pointed SlimServer at this test folder, and did a clear and rescan. It dumped my database, found the single track, added it to my library and then crashed.

Second,used Mp3Tag v32.36 to remove the MusicMagic tags from the file (there were still a bunch of MusicBrainz tags in there through), did a clear and rescan with the same result as above.

Third, I turned off the "Use MusicMagic" setting, and did a clear/rescan and again, it crashed.

Fourth, I disabled TrackStat and rescanned ... no crash ... so it looks like the problem is with TrackStat.

Fifth, I replaced the file with the original to restore the mIP tags, re-enabled "Use MusicMagic" and rescanned ... no crash ... but the song also didn't end up with the "mm" link indicating it should be mixable. I think this is not a surprise, however, since the track isn't where it's "supposed" to be.

I'm currently rescanning my entire library now, with TrackStat disabled, and MusicMagic ENABLED ... I'll report back when that completes.

gutted
2006-10-03, 07:45
Nicely done... Looks like you're onto something with the TrackStat.

(What is TrackStat, out of interest? I could Google it, but I'm very lazy :P )

jeffluckett
2006-10-03, 07:49
Nicely done... Looks like you're onto something with the TrackStat.

(What is TrackStat, out of interest? I could Google it, but I'm very lazy :P )

TrackStat is a plugin that keeps track of play counts, ratings, etc...

It's supposed to be able to survive rescans, unlike the 'default' track statistics. It also allows you to make playlists based upon varous stats like "highest rated", "Most frequently played", "Least Frequently Played", etc...

Still scanning BTW... No crash yet. ;)

gutted
2006-10-03, 07:51
Sounds very cool (apart from the crashes and all ;)

You sure you're running a version which is suitable for your updated version of slim? Maybe there are some old plugin files hanging around which are upsetting slim?

jeffluckett
2006-10-03, 07:52
Sounds very cool (apart from the crashes and all ;)

You sure you're running a version which is suitable for your updated version of slim? Maybe there are some old plugin files hanging around which are upsetting slim?

It was running fine under 6.5.0 ... didn't see anything in the 3rd party Newsgroup about an update for 6.5.1, so maybe this is something new.

jeffluckett
2006-10-03, 07:54
Ok ... the scan completed, and SlimServer did not crash *BUT* none of my tracks are mixable, so it seems MusicMagic data isn't being brought in, or the MusicMagic plugin is borked.

jeffluckett
2006-10-03, 07:58
I should add that I did confirm that MusicMagic was enabled in my settings, and that the MusicMagicServer is indeed running and accessible via http://[server_ip]:10002

gutted
2006-10-03, 08:20
This happens on a recent nightly? If so, I'm not sure whether users like ourselves are supposed to log problems (in bugzilla) for nightlies since they are - in effect - "beta" versions.

Hopefully someone else will know how to address reproducible problems in nightly releases and whether they should be logged (and where they should be logged)

jeffluckett
2006-10-03, 08:22
This happens on a recent nightly? If so, I'm not sure whether users like ourselves are supposed to log problems (in bugzilla) for nightlies since they are - in effect - "beta" versions.

Hopefully someone else will know how to address reproducible problems in nightly releases and whether they should be logged (and where they should be logged)

Yeah ... on last night's nightly build. I won't log a bug unless directed to by someone.

I cross-linked this thread to the one I originally started in the Beta newsgroup, before this one became the active discussion thread. :P

Hopefully someone will pick up on it there.

chris.mason
2006-10-03, 11:59
Yeah ... on last night's nightly build. I won't log a bug unless directed to by someone.

I cross-linked this thread to the one I originally started in the Beta newsgroup, before this one became the active discussion thread. :P

Hopefully someone will pick up on it there.

I think (now you've got it to at least stop crashing) you are seeing what I am in 6.5.1 (same build). I just reverted to 6.5.0, and MIP mixable tracks are once again working.

jeffluckett
2006-10-04, 20:25
I installed the Oct. 4th nightly this evening (SlimServer Version: 6.5.1 - 10169 ) and appears that MusicMagic is back in business for me now.

...and to completely round out my joy ... songs with accented characters in thier titles are now presenting as mixable.

Good job to whoever was involved in that fix.

[UPDATE:] - My joy was short-lived. Even though they get the "mm" link now ... they return empty playlists. This is true of all tracks I've tried ... not just ones with accented chars.