Bug 3735 - Not all songs are MusicIP mixable with 6.3.0 and 6.3.1
: Not all songs are MusicIP mixable with 6.3.0 and 6.3.1
Status: RESOLVED WORKSFORME
Product: Logitech Media Server
Classification: Unclassified
Component: MusicIP
: 6.3.0
: PC Windows XP
: P4 normal (vote)
: ---
Assigned To: Chris Owens
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-07-12 04:55 UTC by Siduhe
Modified: 2008-09-15 14:39 UTC (History)
4 users (show)

See Also:
Category: ---


Attachments
Screen capture of log output on rescan where tracks are not mixable (464.64 KB, application/zip)
2006-07-12 15:45 UTC, Siduhe
Details
Screen capture of log output on rescan where tracks are not mixable (464.64 KB, image/jpeg)
2006-07-12 15:58 UTC, Siduhe
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Siduhe 2006-07-12 04:55:48 UTC
Forum discussion here: http://forums.slimdevices.com/showthread.php?t=25083

After upgrading to 6.3.0. or 6.3.1 some songs are no longer mixable in Music IP.

Some people have managed to get a complete set of mixable songs by stopping slimserver, deleting database cache, starting up Slimserver but with no file path set for the Music Library, in which case all songs show correctly as mixable (i.e. just calling from the MusicIP database).  The problems start when you try to have both MusicIP selected and a file path for your Music Library (which many people want to do for Browse Music or Artwork reasons).  Estimate about a third of my files are unmixable, even following the technique suggested in the thread.

Changing the reload interval to 1 and then to 0 doesn't fix the problem either for me.

There are no error messages and nothing of note in the d_scan or d_musicmagic debugging flags that I can see. Slimserver seems to call for and receive the MusicIP file paths just fine.  It seems more like it the way that Slimserver reads the tags from the files in the Music Library is not the same as the info it receives from MusicIP.

I'm using MusicIP Beta 1.6rc4.  Rolling back to a 28 May 6.3.0. nightly and doing a full clear and rescan fixes the problem for me.  The problem is the same with 6.3.1.

Currently on Windows XP using release SS 6.3.0.
Comment 1 KDF 2006-07-12 08:48:28 UTC
slimserver does not determine if a song/artist/album is mixable.  It is data fed from musicmagic, observable via d_musicmagic and d_info.  If you are into checking logs again, try those and see if you find any songs that you believe should be mixable that fail to show the mixable state in the scan.
Comment 2 Siduhe 2006-07-12 15:44:06 UTC
(In reply to comment #1)
> slimserver does not determine if a song/artist/album is mixable.  It is data
> fed from musicmagic, observable via d_musicmagic and d_info.  If you are into
> checking logs again, try those and see if you find any songs that you believe
> should be mixable that fail to show the mixable state in the scan.
> 
Thanks kdf, I'll attach a zip below showing the relevant parts of the scan.  As an example file, I've used "Pray for me" by the Basement Boys.  Picture A is post a "full clear and rescan" - some songs are mixable, others aren't including "Pray for Me".  Pictures B and C are to show that the song exists, is enabled, and is playable in both MIP and Slimserver.  The log outputs are also attached.  Log 2 shows that the track is being exported from MIP.  What's interesting is in the log with the d_info flag on, which shows that when Slimserver checks to see if the track has changed, it skips the update because it thinks the track is still valid.  I haven't been able to check comprehensively because of the speed that the log goes at, but this only happens on a few tracks, none of which are mixable.  The mixable tracks have a log output more like the "If you don't Love me" track below the "Pray for me" track on the log.


Comment 3 Siduhe 2006-07-12 15:45:24 UTC
Created attachment 1338 [details]
Screen capture of log output on rescan where tracks are not mixable
Comment 4 Siduhe 2006-07-12 15:58:35 UTC
Created attachment 1339 [details]
Screen capture of log output on rescan where tracks are not mixable
Comment 5 KDF 2006-07-12 16:15:07 UTC
If you run the server manually, you can store the log in a file for later review.  From a command prompt:
c:\program files\slimserver\server\slim.exe --d_info --d_musicmagic --logfile=c:\mylog.txt

another thing to try: delete the settings for music folder and playlst folder. wipe and rescan using ONLY musicmagic.  are they all mixable now?  I think, perhaps, some tracks arent' being updated beucase they are already in the db from the folder scan. This may be why you are seing the "Track still valid..." messages.

Comment 6 Siduhe 2006-07-12 16:35:08 UTC
> another thing to try: delete the settings for music folder and playlst folder.
> wipe and rescan using ONLY musicmagic.  are they all mixable now?  I think,
> perhaps, some tracks arent' being updated beucase they are already in the db
> from the folder scan. This may be why you are seing the "Track still valid..."
> messages.
> 

Yes, as noted above, if you delete the Music Library and Playlist Library settings, all songs are mixable and there are no "track skipped" entries in the log.  [But, as a result, now no Browse Music Folder Options or any playlists. ;-)]  Will try deleting the cache, then a full MIP scan, then adding the two library settings back in and seeing if that gives a complete, mixable set.
Comment 7 KDF 2006-07-12 16:54:31 UTC
This matches what I'm seeing.  As a workaround, clear/rescan with only musicmagic, then add music folder and playlist folder and click change, should work.  The music folder and playlist folder settings changes will initiate new/changed scans for both.

6.5 doesn't appear to have this problem.
Comment 8 Siduhe 2006-07-13 13:04:53 UTC
(In reply to comment #7)
> This matches what I'm seeing.  As a workaround, clear/rescan with only
> musicmagic, then add music folder and playlist folder and click change, should
> work.  The music folder and playlist folder settings changes will initiate
> new/changed scans for both.

Slightly OT but in case anyone else is following this workaround, changing the playlist folder doesn't appear to initiate a rescan, only changing the music library folder.  Playlists don't show up at the end of the scan either, although it does give a complete mixable set of songs as kdf suggests.  My workaround has been to add the playlists to MIP and access them that way.
Comment 9 Chris Owens 2006-07-17 12:50:24 UTC
This is not going to get fixed for 6.3.1 I'm afraid.  Setting it to 6.5 and leaving it assigned to me to verify KDF's findings that it doesn't happen and in the process add more musicIP tests to my procedure.
Comment 10 Siduhe 2006-07-17 14:26:42 UTC
(In reply to comment #9)
Thanks for the update Chris.  Can't speak for others, but post-kdf's workaround for the problem, I'm perfectly happy for efforts to concentrate on getting 6.5 stable enough for non-bleeding edge "nightly" users.
Comment 11 Dan Sully 2006-07-23 18:58:31 UTC
Ok - since we're focusing on 6.5, I'm going to close this.

Thanks