Philip Meyer;343124 Wrote: > > What do you feel would be the optimal way to do the match? I was > thinking that for each track url from the restore file, I could run > some SQL that finds the matching track table records where the end-part > of the search-for-url matches. However, this would be a "LIKE '%' + > @search-for-url" search, which may not be too fast. This could be made > faster by creating a view that returns all track urls reversed (which > can then be indexed), and searching "LIKE @reversed-search-for-url + > '%'"? > > Or, should I read all track urls into memory and use regexp matches? > As usual, start simple and make it work then optimize if needed.
I would suggest to start with a simple "LIKE '%' + @search-for-url", if it doesn't get fast enough you can always optimize it later. We are talking about a special case when you perform a restore after you have moved files around, so I don't think it matters if the restore operation will take some time. Of course, if it takes hours some optimization is probably a good idea, but if we are talking about 15 minutes I don't see a major problem. If we include this in an official TrackStat release we should probably not rely on that everyone uses a tree level "artist/album/track" structure in their directory tree. Personally I have only two levels "album/track" and I suppose other users might have four level like "artist/album/disk/track". I'm guessing that it might be unique enough to start at checking four level, if that doesn't match check if you find a three level match and if that doesn't match maybe check if you find a two level match. So if an url points to something like: C:\Documents and Settings\xxx\My Documents\My Music\iTunes\iTunes Music\Artist1\Album1\Disk1\Track1.mp3 You would check: 1. Check the exact url 2. Check url's that end with: iTunes Music\Artist1\Album1\Disk1\Track1.mp3 3. Check url's that end with: Artist1\Album1\Disk1\Track1.mp3 4. Check url's that end with: Album1\Disk1\Track1.mp3 5. Check url's that end with: Disk1\Track1.mp3 Step 5 can obviously cause some problems, I'm not sure which way it would be easiest to avoid that and still support users who store the music behind urls like: C:\Documents and Settings\xxx\My Documents\My Music\iTunes\iTunes Music\Artist1 - Album1 - Disk1\Track1.mp3 I think one way is to stop at the three level check at step 4, another might be to only perform the two level check if the last directory name is at least 10 characters. Users that have a "album/track" structure are probably going to have pretty long album names to make them uniqe, in my own setup I include the artist name in the album directory name. You can also choose to make it simple and only do the three level check which should be able to handle most cases and users with a flat "album/track" structure would have to fall back to edit the XML file manually. The other users I've heard that have had similar problems as you has only moved the music to a new mount path and in that situation it's fairly simple to open the XML file in a text editor and do a replace all of the beginning of the path. -- erland Erland Isaksson 'My homepage' (http://erland.isaksson.info) 'My download page' (http://erland.isaksson.info/download) (Developer of 'TrackStat, SQLPlayList, DynamicPlayList, Custom Browse, Custom Scan, Custom Skip, Multi Library and Database Query plugins' (http://wiki.erland.isaksson.info/index.php/Category:SlimServer)) ------------------------------------------------------------------------ erland's Profile: http://forums.slimdevices.com/member.php?userid=3124 View this thread: http://forums.slimdevices.com/showthread.php?t=52937 _______________________________________________ plugins mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/plugins
