View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002533 | MMW v4 | DB/FileMonitor | public | 2006-07-05 15:34 | 2006-08-18 04:49 |
| Reporter | rusty | Assigned To | |||
| Priority | immediate | Severity | major | Reproducibility | sometimes |
| Status | closed | Resolution | fixed | ||
| Fixed in Version | 2.5.4 | ||||
| Summary | 0002533: With some NAS devices, scans are incomplete | ||||
| Description | If MM is asked to scan \\storage001\music it only finds 70 files, but if I explicitly name all the sub-directories it finds all 2,700 of the files. By the same token, the File Monitor doesn't work on such devices (since only the top level directory is specified). Jiri thinks that the network software may be at fault but I can list all directories with no problem and the MM directory browser finds all sub-directories without problem .. it just wont scan the top level directory No other software has trouble scanning this drive and MM has no problem scanning drives on other devices on my network | ||||
| Additional Information | Device it is known to occur with (reported by Sean): Argosy_HD363N The device costs ~$75 if we want to purchase it. A log is posted to the ftp server. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | |||||
|
|
I have already analyzed this issue and the log doesn't indicate anything wrong, any exception or so. It looks like Windows routines simply report that there are no more files and that's it. I don't know what more could we do, only trying to play with the device mentioned, hopefully it will be reproducable... |
|
|
Actually, I got an idea: since the device is kind of limited PC, there can be some limitation on number of simultaneously openned handles. Currently, in AddToDatabaseRec() in MP3Utils.pas we have a handle (for FindFirstFile()) openned for each folder in a hierarchy, because as soon as FindNextFile() returns a folder, we go into the folder without prior closing the handle. So, I'd propose to scan content of a folder as we currently do, but don't use recursion until we close the handle (by Windows.FindClose( hndl)), keep list of found folders in a TWideStringList and go into the individually as the last part of the process. This could fix the reported problem and would be generally more friendly to resources. |
|
|
created change in scan routine (as jiri wrote), but now we need to check, if this solves the problem |
|
|
I've raised this to immediate since I've received 4 separate reports of this issue already. Hoping that the change is sufficiently low risk that we can include it in 2.4. |
|
|
Users have confirmed that the fix works. Closing. |
