Bugzilla – Bug 704
getting many reports of the Rescan button failing to find new music
Last modified: 2008-12-18 11:50:15 UTC
Getting many many reports of this. Have been suggesting the wipe cache button be used instead of rescan, however, I had not filed a bug yet since I still have not been able to reproduce this problem.
I've seen claims of this too, and to my mind it seems to be windows machines that suffer from it (can't quite say which flavour). I've never noticed anything myself on any os, but then I'm not adding music at any incredible rate, nor do I go very long between cache wipes thanks to so much code testing :)
I'd like to understand this for 5.4.1
Does anyone have a notion of whether this is with or without iTunes? I'm unable to recreate the specific problem without iTunes on Windows XP SP 2. With iTunes, the updates don't propagate until iTunes itself is made aware of the addition (which, from what I know, needs to be done explicitly). Once the new files/folders are added to iTunes, a rescan does seem to bring it into our database. Another thought, in cases where the rescan doesn't work, are people using Windows shortcuts?
My setup is WinXP Pro SP2. All of my music is on a single drive (F:\), and is organized with individual albums in their own folder. I do not organize the albums under artist folders. No iTunes and no shortcuts. If I use the rescan button, the server goes through the motions like it's recanning but never turns up the new files. The other suggestion for adding new files without a complete cache wipe is to browse the music folder. This also doesn't work for me. Could the problems be related?
They could definitely be related. Some questions: 1) Are the new files within a new directory or an existing directory? 2) What type of files are they? What format? Do they have Digital Rights Management associated with them? 3) Would it be possible for you to do a rescan with the --d_scan debug flag turned on? If so, could you see if the scan gets to the containing directory and post the relevant section of the debug output as an attachment to the bug? Thanks.
Okay, all of the songs in my collection are Ogg Vorbis files, so no DRM I have CDEX encode them and put them in a new folder on f:\. The new folder bears the name of the album, so the f:\ drive is never more than one directory deep. New files never go to an existing directory. I'll a test rescan as soon as I get some time.
Well, I'm afraid I don't have anything interesting to report from the recan. The log doesn't even mention the new folder. It goes from the previous folder (F:\Boy Child. The Best Of) to the next folder (F:\Brian Eno's Taking Tiger Mountain By Strategy) while ignoring the folder in-between them (F:\Boys Don't Cry) A full wipe and rescan did turn up the folder as expected.
I have similar problems; running Win98SE, Slimserver 5.4.1. I have about 30 albums ripped as 256KB MP3, one or two as FLAC, 80 or so as WAV. I haven't had a problem finding new music if I wipe cache, but Browse Music Folder doesn't work before I've done so. I thought Browse Music Folder once worked to find new music; come to think of it, that could have been before I began ripping to WAV. Could that be a clue? Unfortunately, I can't do any more testing because the C: drive on my server is toast, and I may not stay with Win98 when I put things back together.
This message came across the mailing list today: http://article.gmane.org/gmane.music.equipment.slimdevices.general/19174/ I tested the criteria that the poster mentioned in his post and he's right on. First, I put an Ogg in "f:\zzzzzz" and did a rebuild and a Browse Music Folder and it turned up nothing. I put the 'zzzzzz' folder inside an already-indexed folder (making it "F:\#1 Record\zzzzzz") and did a Browse Music Folder and there it was. After I browsed to the file and looked at its info, it appeared under the regular Browse Artists view. As a second test, I made a new "f:\zzzzzz" and put a file in that. Browsing didn't turn up anything so I altered the URL to browse to the file directly (http://localhost:9000/browse.html?&dir=zzzzzz) and that turned up my new file and folder. However, even after browsing the file and having the song show up in Browse Artists, I still couldn't see it under Browse Music Folder. So, from what I'm looking at, rescan and browse won't pick up new folder that is placed just inside the root of the music folder unless you force the HTML interface to look there.
I'm guessing you cant get a "last modified" number for a root directory. To test this theory, you'd need to do Steve's test again using f:\music (or similar) as the music folder (thus add f:\music\zzzzz, etc). If there is no 'last modified' tag on a root folder, then the server would have to always check the audiodir directly. This would get ugly in cases where users store a large number of files/folders at the top level.
Just in case it helps, I am seeing the same issue with a somewhat different setup. I run a W2K server and the music folder is located at \\server\share. Included in the share is a shortcut to another \\server\share entry. Apparently, this problem exists with shared network folders as well as local. Manual Rescan never find new music. Only Wipe Cache or Scheduled Rescans.
I expect network shares are influenced by some level of caching. We have that problem at work where the particular server we use, in combination with win2k caching settings causes us to have files locked from access for no reason. I expect win2k is stuck reporting the same modification date so that the server has no way of knowing anything has changed.
Regarding the distinction between adding a new folder under the main music folder (e.g. new artist) as opposed to adding to an existing folder (e.g. a new album for an existing artist), I must report that "Browse Music Folder" failed to find an album for me in the latter case. I previously had two Adrian Belew albums; when I added a third, "Browse Music Folder" didn't find it, nor did the scheduled nightly scan, which surprised me since I thought the scheduled scans wiped the cache first. This is Win98SE, though I had the same problem when I had SlimServer running on my WinXP Home laptop (same music library).
I just used the tip in Steve Barnard's comment #9 (entered the URL to browse the new album directly) and sure enough, it found it and added the album to the list under Browse Artists - but it's still not there under Browse Music Folder! Even more peculiar, the timestamp for slimserver.db hasn't changed (although the server seems to save it every hour or so).
I needed to wipe cache the other day, and as SlimServer was rescanning, I was able to browse the music folder and find new items. (Of course, since I'd like to be able to browse to new items to *avoid* rescanning, this doesn't help much.) The performance was more than acceptable; I'm wondering why it was deemed necessary to use the directory information stored in slimserver.db unless a folder timestamp has changed (or so I've been told). I suppose if I had a thousand artists or so, this might be more of a problem, but one I'd be happy to live with if it enabled Browse Music Folder to work as advertised. Perhaps a "Behavior" setting could be provided that determines whether Browse Music Folder uses cached data?
Don, et al - have you had a chance to try the recent 6.0 nightlies? The rescan logic has been improved quite a bit, and this bug should be fixed.
*** Bug 585 has been marked as a duplicate of this bug. ***
I just tried this out on Win2k. create a dir and refresh music folder, the dir shows up immediately. descending into it scanned the file I placed inside. confirmed with d_info.
This has been fixed for 6.0
Routine bug db maintenance; removing old versions which cause confusion. I apologize for the inconvenience.