Bug 9004 - Problems connecting with slow server
: Problems connecting with slow server
Status: CLOSED FIXED
Product: SqueezePlay
Classification: Unclassified
Component: Networking
: unspecified
: PC Other
: P5 normal with 2 votes (vote)
: 7.4.0
Assigned To: Squeezebox QA Team email alias
: Verify_74
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-08-03 08:38 UTC by Blackketter Dean
Modified: 2009-10-05 14:28 UTC (History)
9 users (show)

See Also:
Category: Bug


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Blackketter Dean 2008-08-03 08:38:06 UTC
Sent via PM by JJD:

Many people have been complaining about the controller losing connection to the music source. I have been experiencing this as well (see: http://forums.slimdevices.com/showpost.php?p=324795&postcount=246)
I think I have found the how to solve the issue. After experimenting with some different disk units I found out that the throughput of the disk is extremely important. A slow (network) drive causes the problem instantly. It does not matter if you have the Database/Cache on the internal fsat drive. If the actual track files (MP# or whatever) reside on the slow disk the problem occurs as soon as the individual songs have to be presented on the controller. I think you have build in some max. response times in the slim server software that are exceeded at that moment combined with some strange error handling. My suggestion increase the delay time (or give users the ability to change it) and adapt the error handling.
I hope this hleps to make the product more stable.
Comment 1 John Dreu 2008-08-04 03:12:46 UTC
Extra info.
Even with all songs on the slower Network Drive. The squeeze Center software works fine, but the controller loses the connection to the SB.
This problem may have someting to do with Bug 311 as well, because I have my songs on a network drive. 
Comment 2 Ben Klaas 2008-08-04 08:56:24 UTC
*** Bug 9018 has been marked as a duplicate of this bug. ***
Comment 3 Matt Wise 2008-08-04 08:58:25 UTC
Oops! Sorry about the duplicate! Here were my comments on the issue:

I started seeing very similar behavior last Thursday... it turns out that on
Thursday one of the drives in my NAS array started having errors and the
network access to that unit has been extremely slow ever since. Fast enough to
stream music, but too slow for the Controller I guess. Almost every time I use
the controller now it looses connection to the SqueezeCenter server even though
music is playing just fine.

I have to attribute this change in behavior to the slow back-end storage of the
music library.. (4200+ flac songs over NFS). 
Comment 4 Chris Owens 2008-08-04 09:13:17 UTC
Give Matt an SD card so he can get a log.

We should focus on the connection issues, not the async IO issues that may in some sense be the root cause.

QA to also try reproducing with a music library on a network drive.
Comment 5 James Richardson 2008-08-06 10:44:18 UTC
Bumping to 7.3 and increasing the priority
Comment 6 Ross Levine 2008-10-22 13:18:59 UTC
*** Bug 9176 has been marked as a duplicate of this bug. ***
Comment 7 Ross Levine 2008-10-23 16:27:47 UTC
Ross to check against new schema build. Try DD-WRT with port slowed down. 
Comment 8 Ross Levine 2008-11-06 17:28:50 UTC
To slow things down I've set scanner priority to the highest, set artwork resampling to resize, and rescanned a large library on my ReadyNAS. SqueezeCenter running on the NAS doesn't handle this well. 7.2 and 7.2.1 the Controller gets a blue icon while trying to browse music during the scan, and it never recovers even after the scan is complete. When you browse to music it attempts to connect to the source but fails. 7.3 (r3253) also gets into this state with the blue icon / fail to reach source, but when the scan completes the Controller reconnects. 
Comment 9 Mickey Gee 2008-11-12 15:04:28 UTC
Ping Brandon on status ....
Comment 10 Emmanuele Patti 2008-11-18 13:25:53 UTC
I also had exactly these problems with my ReadyNAS NV+. I ended up buying a ReadyNas PRO. I believe the NV+ is to slow or the software not optimized for it...
Comment 11 Blackketter Dean 2009-07-22 08:39:20 UTC
Moving to the product SqueezePlay because this bug appears to apply to any player based on that application code.  Feel free to move it back if it's specific to the single original product.
Comment 12 Richard Titmuss 2009-07-27 01:13:20 UTC
Reset priority before triage.
Comment 13 Brandon Black 2009-07-30 14:08:43 UTC
Removing new_schema tag, this isn't directly related to new_schema
Comment 14 James Richardson 2009-08-17 11:06:56 UTC
Has anyone running SC 7.4 seen this error happen again?
Comment 15 Ben Klaas 2009-08-26 07:47:17 UTC
this is an administrative shuffle on priority fields to help make better judgment on the top end of the priority list. P4->P5, P3->P4, and P2->P3.
Comment 16 James Richardson 2009-09-23 10:17:38 UTC
QA has been unable to reproduce this with 7.4.  Please retest with that version, if you still see an issue please reopen and provide logs.
Comment 17 James Richardson 2009-10-05 14:28:52 UTC
This bug has been marked as fixed in the 7.4.0 release version of SqueezeBox Server!
    * SqueezeCenter: 28672
    * Squeezebox 2 and 3: 130
    * Transporter: 80
    * Receiver: 65
    * Boom: 50
    * Controller: 7790
    * Radio: 7790  

Please see the Release Notes for all the details: http://wiki.slimdevices.com/index.php/Release_Notes

If you haven't already, please download and install the new version from http://www.logitechsqueezebox.com/support/download-squeezebox-server.html

If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.