As I recall, there is a performance problem, introduced by a well-meaning database call at the top of the browse pages. This call forces the database to enumerate all the tracks every time the web page refreshes.
This is why I believe this is what is happening to you: > > 2006-02-04 16:10:44.4561 browsedb - hierarchy: age,track level: 0 > 2006-02-04 16:11:12.7645 Generating page for status_header.html took: 0 > wallclock secs ( 0.02 usr + 0.00 sys = 0.02 CPU) > 2006-02-04 16:11:12.9464 ***Stream underrun: 200 > 2006-02-04 16:11:12.9479 00:04:20:04:19:5dBuffer drained, pausing > playback > 2006-02-04 16:11:12.9733 00:04:20:04:19:5d Buffer full, starting > playback > at 16:10:44, you started to generate a browse out of the database. 28 seconds later, it finishes and formats the status page. Then (and only then, because of the way Slimserver is architected) it notices that it underran the SLiMP3 buffer. But the SLiMP3 buffer is only about 5 or 10 seconds. So the music stopped. There are several solutions. As suggested, newer squeezeboxes have bigger buffers, so they hide this problem. Or remove the expensive and totally unnecessary database call. You can do this by hacking the web page yourself (hard) or upgrading to the 6.2.2 version, where they reduced the expense of the call by (I think) caching the result. A faster processor would have to be about 6 times faster (for your system) to reduce that 28 second delay to something the SLiMP3 can overlive. It's unlikely you'd find such a processor. -- Michaelwagner ------------------------------------------------------------------------ Michaelwagner's Profile: http://forums.slimdevices.com/member.php?userid=428 View this thread: http://forums.slimdevices.com/showthread.php?t=20783 _______________________________________________ Discuss mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/discuss
