PDA

View Full Version : Linkstation Rescan?



jackmanfred
2005-10-20, 14:39
Hi,

I was wondering if someone could help me out.

I own a 300GB Linkstation which is running Slimserver 6.2 nightly. I've got about 250GB of music which is roughly 1700 albums.

I would like to know if there is any point in using the rescan button as it seems to take ages to complete, like a week! Is this normal? and you seem to get the same view if you use the browse music folder.

Thanks

ultra238a
2005-10-20, 15:01
Your box is using a 200/266Mhz CPU with 64Mb of memory - it ain't going to get any quicker. Just set it to run over night from the web front end at say 2:00am then you won't notice it.

Paul
Progressive Consumer Electronics

JJZolx
2005-10-20, 16:13
Your box is using a 200/266Mhz CPU with 64Mb of memory - it ain't going to get any quicker. Just set it to run over night from the web front end at say 2:00am then you won't notice it.
You will if it takes a _week_.

JJZolx
2005-10-20, 16:32
I would like to know if there is any point in using the rescan button as it seems to take ages to complete, like a week! Is this normal? and you seem to get the same view if you use the browse music folder.
Using browse music folder to pick up new music should work. There are some differences from doing a full rescan that you might want to be aware of. Such as not picking up artwork. See:

http://bugs.slimdevices.com/show_bug.cgi?id=2116

It's probably the fastest way for you to get SlimServer to pick up newly added albums. Just navigate down to the album folder and SlimServer will add all the tracks in the folder to its database. As long as you don't regularly add dozens of albums at a time, it beats waiting a week for a rescan.

Another limitation is that SlimServer may not (or is it definitely will not?) pick up changes that you've made to files which have already been cataloged. For instance, if you were to change tags in a file, such as changing the artist or album name. I've always thought it would be good to have the ability to rescan just a portion of the music folder tree.

You might consider the advantages to running a dedicated machine for SlimServer. I suppose the Linkstation is attractive in that it's low powered and probably quiet, but if my SlimServer took a week to rescan my music collection, I'd dump it. I can't imagine browsing is any too quick on a device like that either.

Michaelwagner
2005-10-20, 18:44
Another limitation is that SlimServer may not (or is it definitely will not?) pick up changes that you've made to files which have already been cataloged.
This is certainly true in 6.1. Haven't tried the new improved 6.2 yet. But I'm pretty sure this is a bug, not "working as designed".

JJZolx
2005-10-20, 18:49
This is certainly true in 6.1. Haven't tried the new improved 6.2 yet. But I'm pretty sure this is a bug, not "working as designed".
I'm not talking about picking up changes during a rescan. I'm sure the intent there is to recognize all changes to files (including deleted files and directories) and update the database accordingly.

I was referring to picking up changes while using Browse Music Folder. I know the goal was to make BMF as fast as possible, so I'm not certain if it's intended to pick up on changes, or if it's only supposed to catalog new content.

Marc D.Field
2005-10-20, 22:39
jackmanfred wrote:
>I would like to know if there is any point in using the rescan button
>as it seems to take ages to complete, like a week! Is this normal? and
>you seem to get the same view if you use the browse music folder.


Hi,

This does not sound normal. I run SlimServer on a LinkStation and have about 60G of music, and it takes only 2-3 hours to rescan. You might run top to see whether some other processes are using lots of resources on your LinkStation, or just try rebooting it. Or maybe 4x as much music takes *far* more than 4x as much time to scan...

Marc

Michaelwagner
2005-10-21, 07:22
maybe 4x as much music takes *far* more than 4x as much time to scan...
It's possible. I went over the MP3 tag scanning code and, while some of it may be "improveable", the performance numbers weren't all that bad. Dean wrote me that he thinks the "scanning performance problem" isn't really in the scanning code but may be in the database back end. Depending on how the database works (and I don't know anything about that part of the code), it could be considerably less than linear.

I said I would benchmark whether it's the database or the MP3 scanning code that's so slow in a week or so. Unfortunately, that's probably going to take another week longer than I thought.

(long story short, my girlfriend's spa is taking longer to open than we thought, and I have to help out).

jackmanfred
2005-10-21, 09:31
Marc,

Heres the output from the top command, when running a rescan. I would really like to see some benchmarks results from your tests mike.

Maybe as theres a lot of people out there running linkstations and slimserver, slimdevices might be able to write a cut down version of slimserver for the linkstation.

Mem: 58580K used, 3264K free, 0K shrd, 1304K buff, 47892K cached
Load average: 0.37, 0.31, 0.19 (State: S=sleeping R=running, W=waiting)

PID USER STATUS RSS PPID %CPU %MEM COMMAND
274 root R 33M 1 99.2 56.2 slimserver.pl
435 root R 544 434 0.5 0.8 top
15 root SW 0 1 0.1 0.0 kjournald
247 root S 592 1 0.0 0.9 nmbd
220 root S 388 1 0.0 0.6 thttpd
245 root S 348 1 0.0 0.5 smbd
434 root S 324 185 0.0 0.5 bash
231 root S 232 1 0.0 0.3 cron
197 root S 220 1 0.0 0.3 syslogd
1 root S 208 0 0.0 0.3 init
244 root S 208 1 0.0 0.3 atalkd
354 root S N 204 1 0.0 0.3 ls_servd
203 root S 184 1 0.0 0.2 ekpd
206 root S 184 204 0.0 0.2 ekpd
204 root S 184 203 0.0 0.2 ekpd
205 root S 184 204 0.0 0.2 ekpd
263 root S 172 1 0.0 0.2 mc_ctld
272 root S 168 1 0.0 0.2 afpd
270 root S 164 1 0.0 0.2 papd

Thanks