Bugzilla – Bug 9484
Connection loss between controller and Squeezecenter while accessing large directories/albums (Music Folder Browsing)
Last modified: 2008-12-15 12:07:40 UTC
Hi, Currently I'm having some difficulties with albums having more than 500 entry's in it (eg Top 1000 lists). The controller tries to access the album, but gets disconnected and turns up in an unusable state. Also a powercycle of the controller will not solve this issue and the entire connection to the Squeecenter and Squeezebox are lost. Any thoughts?
If you are using Browse Music Folder on slowish hardware, you might want to give the latest 7.2.1 nightly build a try. Other than that please provide us with more information about your system, music organization and how you try to access that album (with >500 tracks?!?).
What format is your music in? Where is your music located? What are the specifications of the system you are running SC on? Please do as Michael suggested, and try 7.2.1 I run a NAS server with over 30K tracks, and do not see this issue.
Hi, Sorry for the late response. Please find the details below: - What format is your music in: MP3 - Where is your music located: NAS, DS207+ - What are the specifications of the system you are running SC on: DS207+, SSODS, SC7.2 - Please do as Michael suggested, and try 7.2.1 Will do! - I run a NAS server with over 30K tracks, and do not see this issue. I have approx 800 mp3s in one directory (its a top 880). The issue is resolved a little by creating a playlist in winamp and storing that in the targetdirectory. Could it be that SC is taking a lot of time to create the playlist.
Do you see this issue when selecting "Music Folder" from the controller? or when browsing 'Artists' or 'Albums' from the controller? I was able to reproduce the issue when having 1K tracks in a single folder, then browse Music Library > Music Folder. I was able to get the controller to react slowly, but not able to get it to lock up. Browsing Artists or Album did not have the same issues. Nor did accessing a predefined Playlist I'm sure SC on a Synology NAS (3rd party SSODS plugin) would have time out issues.
James to capture logs network.commentd
See attached logs. Make a single folder with 1000 tracks in it. Point SC to this folder Clear & Rescan Wait for scan to finish Pick up Controller Browse by Artist / Album, NOTE: no delay or performance problems Browse by Music Folder, NOTE: it will take ~15 seconds to respond, scrolling is VERY slow and halts as the various chunks are loaded. Even with this method, I am unable to get my controller to 'lock up' or behave in any other way except slowly. Using a MacBook Pro with SC 7.2.1-23353 Controller 7.2r2920 Local Music Folder with 1k tracks
Created attachment 4086 [details] Server Log
Created attachment 4087 [details] Scanner log
James - my Controller took about 4 seconds to list those 1000 folders. Could you please zip your folder structure _without_ the files? Is this music folder stored on your local disk drive? Also could you please do "ls -l > folders.lst" in that main folder and upload the generated folders.lst? I wonder if there's something special in the folder names you've created.
Just upgraded to SC 7.2.1-23353 on SSODS. Will try again.
Guys, SC 7.2.1 - 23353 solved my issue. The controller opens all big directories more slowly, but this does not result in a timeout. No entries appear in the server.log Great!
Created attachment 4091 [details] Folder.LST (In reply to comment #9) > James - my Controller took about 4 seconds to list those 1000 folders. Could > you please zip your folder structure _without_ the files? Is this music folder > stored on your local disk drive? It's a Single Folder, with 1000 tracks in it. Located at the ROOT of a USB HDD ' /Volumes/Time Machine Backups/1000 tracks/' > > Also could you please do "ls -l > folders.lst" in that main folder and upload > the generated folders.lst? I wonder if there's something special in the folder > names you've created. > There are no folder names, just a pile of tracks. Attached per your instructions above
Sorry about the confusion... I misread your comment and thought you were talking about 1000 _folders_ instead of tracks. Will try to reproduce.
> ' /Volumes/Time Machine Backups/1000 tracks/' Is this a local volume?
*** Bug 9669 has been marked as a duplicate of this bug. ***
In my case, it is a local volume on a Linux Debian Etch system.
Created a folder with 816 tracks on a slowish (6yrs old) external 2.5" harddisk. The query takes SC 2-3 seconds to return. But Controller won't be available before 20-25 seconds later. SqueezePlay run on my computer would be back within another second or two - expected behaviour. Ben - I think we're hitting an issue in how the "play rest of album" is handled in Controller's BMF. It's most likely due to a huge playlist being added to the menu result: every track has a playlist of 200 items attached - which also reveals a bug in my performance fix... If it were correct, it would add the full list of 816 items to every track. Wouldn't help with the performance on the Controller.
change 23460 - move the "Play Other Songs In Album" handling from the musicfolder query to the play command handler. This greatly improves BMF performance on Controller with large libraries when this option is enabled. The big performance hit were the huge lists to be managed by Controller, plus a few seconds for the need in the query to loop through the list twice, to get the playlist created before the actual response. Moving the playlist creation to jivePlayTrackAlbumCommand cut down time from about 25 seconds to 5 seconds on my test configuration. Please give it a try. Ben - I've mostly re-used code of the Slim::Buttons::BrowseTree play event handler. For 7.3 we might want to wrap this in to the "playlist play ..." command.
This fixes bug 9669 which was my version of the problem.
This bug has been fixed in the 7.3.0 release version of SqueezeCenter! Please download the new version from http://www.slimdevices.com/su_downloads.html if you haven't already. If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.