Bugzilla – Bug 3903
no tracks, albums, or artists are Music Magic mixable
Last modified: 2008-09-15 14:39:24 UTC
Clean install of SlimServer Version: 6.5b1 - 8880 - Windows XP - EN - cp1252. Scanned library, and no "MM" icon appears in web interface for any tracks, albums, or artists. Checked the database (MySQL 5.0) and musicmagix_mixable is set to NULL for every row in tracks, albums, artists. Using MusicIP Mixer Version 1.7. Verified that MusicMagic Service is running fine.
d_musicmagic. guaranteed this is a suport issue, and not a bug. works fine here. musicmagic MUST be running before slimserver starts up. Use Musicmagic must be selected in server settings. This will not start a scan on it's own so you need to launch one. 'new and changed' should suffice.
KDF, I'll email support if you think that's best. But I definitely started musicmagic before starting slimserver, and I have "Use MusicMagic" selected in the server settings. I know there have been many forum posts and some bug reports about very similar problems, but I've had it working in every previous version. I'll fiddle around with my settings some more and if I still can't make it work I'll contact support. Thanks.
Just tried SlimServer Version: 6.3.1 - 8468 - Windows XP - EN - cp1252. Made sure MusicMagic was running first, made sure "Use MusicMagic" is checked on the Server Settings page. Initiated a rescan. I see the "MM" icon all over the place and can make MM mixes fine through the web interface. I cannot do this with 6.5b1 - 8880.
Also see http://forums.slimdevices.com/showthread.php?p=127884
Created attachment 1412 [details] Log file This is my log file from running: C:\Program Files\SlimServer 6.5\server\slim.exe --d_musicmagic --d_import --d_scan --d_sql --d_mysql FYI - the log includes a full scan so the uncompressed text file is over 100 MB. At the end of the scan, none of my tracks were mixable.
2006-08-10 18:11:23.6724 MusicMagic: start export 2006-08-10 18:11:23.6994 MusicMagic: Got 29713 song(s). 2006-08-10 18:11:23.7003 MusicMagic: Fetching ALL song data via songs/extended.. 2006-08-10 18:11:31.3453 SELECT me.name, me.value FROM metainformation me WHERE ( name = ? ): 'isScanning' 2006-08-10 18:12:31.3612 SELECT me.name, me.value FROM metainformation me WHERE ( name = ? ): 'isScanning' 2006-08-10 18:13:31.3768 SELECT me.name, me.value FROM metainformation me WHERE ( name = ? ): 'isScanning' 2006-08-10 18:14:24.0312 ERROR: MusicMagic: Couldn't connect to http://localhost:10002/api/songs?extended ! : No such file or directory 2006-08-10 18:14:24.0937 MusicMagic: got playlist A Rainy Night with Chinese Food with 91 items the songs?extended API is supported and works. no idea why there is no reponse to the request in this case. But, with no response, there are no songs for Slimserver to parse and nothing is mixable. Perhaps 29k songs is too much, or takes too long to come back and slimserver is timing out.
So is this a bug? It works find in 6.3 - should I post my 6.3 scan log as well?
Still compiling my 6.3 log, computer rebooted twice due to a power failure so I had to start over. In the meantime, I got this response when I asked Wendell at Music IP about api/songs?extended never returning: ----------------- It may indeed be bogged down trying to create an over large response. You can use the paging options added in 1.6 to get the data in smaller chunks: For instance, adding: page=0&results=100 will return just the first 100 results (note that page is 0 indexed). If you enable paging, then you need to make sure to change the parsing of the results, as the first thing returned will be the total number of items (so you can calculate how many pages of data need to be retrieved). ----------------- While http://localhost:10002/api/songs?extended never came back for me on my machine, http://localhost:10002/api/songs?page=0&results=100 worked fine. Since the error is resulting from the Music IP API timing out, I understand why you may look at this like a Music IP bug and not a SlimServer one; however, obviously the methodology for getting tracks out of Music IP changed between 6.3 and 6.5 since I am able to make Music IP mixes successfully in 6.3. If it worked in 6.3 and not in 6.5 I would view that as a SlimServer bug. Log file for 6.3 coming soon.
I'll try to have a look at this today or early next week. For my own notes: I should probably start with 6.3.1, verify it works there, and then upgrade to 6.5, since that will be the typical user case.
1) known issue with musicmagic in 6.3.1, where any tracks imported from folder will be marked as "still valid" and not updated in the musicmagic scan as mixable. 2) I have 6.5 working on windows with a small library of 400 tracks, MIP 1.7b4, Linux latest v of MIP with 11,000 songs. If what I suspect is the problem, you'll need at huge library of at least 20k or so in order to see this failure. With 6.5 ALL songs are grabbed in one chunk from MIP as a playlist, then parsed. This means we may need to allow the response to take a while, if there is in fact any sort of timeout on LWP.
Log file for 6.3 is not needed. The import method is different enough to be irrelevant to this problem.
Got it, thanks (won't post a 6.3 log). And thanks again to all involved for looking into this. In terms of library size, mine is ~29K, another forum poster who seems to be having this problem as well is at ~23K songs.
Ah thanks KDF. I really need to figure out how to simulate a very large library on my test platforms.
FYI - I got api/songs?extended to load in my browser, but it took around 12 minutes.
Another FYI - just got another update from Wendell over at Music IP: ------------- I've just optimized the associated code in the API - we can now return 90k tracks in 3 seconds, which should make the problem go away in any case. This fix will be in 1.7 beta 5 Wendell -------------- So maybe this will go away on its own when the next beta of Music IP comes out.
New beta of Music IP is out - I can get localhost:10002/api/songs?extended to return all my tracks in a few seconds. Am trying another re-scan of the library now with this new version. Other forum posters have reported success by upgrading Music IP API.
Yep - Wendell fixed the issue. For reference, MusicIP 1.7b5 and greater have this fixed.