Bugzilla – Bug 9698
Install pauses at "creating directories" for a long time (approx 1.5 minutes)
Last modified: 2011-04-29 08:46:42 UTC
Windows XP sp3, fully updated with windows updates. Symantic/Norton Anti-Virus and Firewall 2008. The installer pauses for approx. 1.5 minutes with the "Creating Directories" message and no apparent activity is seen during that time. SC is run as a local service (no user id/password). It was shut down manually (Windows Service, stop) PRIOR to starting the installer EXE. Also SqueezeTray was exited prior to starting the installer EXE. Also, the installer also pauses for approx. 15 seconds while it is waiting for SqueezeCenter to shut down (however, as noted, it was manually stopped prior to the installer being started). In past tests shutting down the anti-virus/firewall had no impact on install times. This was a while ago, though, so may need to be reconfirmed.
This pause also occurs for me when updating under Windows Home Server. I don't think it's as long as 1.5 minutes on my system, but it happens. I don't manually shut down the SC service before installing. No anti-virus, Windows standard firewall.
Tested this on XP and was able to reproduce it the very first time I run the update, but not on subsequent runs. Can you confirm this behaviour?
I installed xx520 on top of xx520. Windows XP sp3. Other environment factors and steps the same as previous tests. SC and SqueezeTray were manually shutdown prior to starting the install. The "waiting for squeezecenter" to shutdown time was essentially the same. The "Creating Directories" time seemed to be approx. half of what it was previously. Only 45 seconds or so. The install failed, however, in that SC wouldn't start after installing over the top of itself with the same version. I did NOT uninstall prior to installing again. Installing new nightlies hasn't usually been an issue with this process. Uninstalling and then reinstalling, resetting it to run as a service worked - it started. Also, there were no pauses in the install processes.
Also, the uninstall/reinstall method triggered a full library scan. Takes a lot of time and makes players loose their playlists - not very convenient for normal usage.
QA to try to find a reliable way to reproduce.
From user experience and a bit of directed testing it seems like the easiest way to duplicate this is to install different nightlies without uninstalling in between them. Not sure if the failure to run after installing the same nightly build twice without first uninstalling should be part of this or it's own bug...
Doug: have you seen this slow down again? This sounds to me like an issue with MySQL not stopping quick enough during an install. I was able to repo this, but ONLY when SC was doing a scan, and I then installed SC. If I stopped SC first, then installed, I never saw this problem. IMHO there is nothing for us to fix here. Closing this bug for now, if you feel differently please reopen the bug and add your comments.
Unfortunatly for this theory, I have always manually stopped SC prior to starting the install process so I would think that the MySQL would be shut down already. It does look like it has stopped from the Windows Service, anyway (from memory, I'll recheck with next upgrade). I can guarentee that a scan was NOT in process when the upgrade was started nor when SC was shutdown. Michael mentioned that it was only reproducable the first time a particular build was installed. It happens 100% of the time on my system when I install a new 7.3 update. Agree that it almost certainly isn't the highest priority issue and that you may not be able to do anything about it, but the proposed causes put forth don't correlate with the observations, unfortunately.
Reconfirmed that it is still occuring. Confirmed that SqueezeCenter and SqueezeMySQL services were FULLY shutdown prior to starting the install. Reconfirmed that SqueezeTray had been exited prior to starting the install. Still had the original problem(s), as noted. This was installing a NEW nightly version of SC. Others have noted that it only occurs when changing versions.
Doug: thank you for the response. Michael: is there any type of log that would help diagnose this issue? QA: to investigate installer logging software
Ok, one more idea: next time before you update, please shut down SC, remove it's cache folder before installing, then do the update. We tell the installer to make our data folder (which contains the cache folder) user writable. The installer might go through all of those files and check permissions. If you have a large collection and/or a well populated cache folder this can take a while. If you want to see in detail what's going on, you might want to install Sysinternals' DiskMon utility (http://technet.microsoft.com/en-us/sysinternals/bb896646.aspx). It will show any disk activity while some process is running. It might help you understand what's going on.
Took a couple of days for a Windows nightly .exe file to show up, but worth the wait!!! Yes, I deleted the contents of the cache folder in "C:\Documents and Settings\All Users\Application Data\SqueezeCenter" on my Windows XP sp3 box and it went through the creating directories prompt in less than a second and started in on installing files right away. Not sure what the corrective action is, though. A prompt with something other than "creating directories" would be fine with me. If the bar could move that would also be great. Could the setting permissions piece be moved after the files are installed? It would make more sense to a user that something was taking a while then...
Doug - thanks for the confirmation! > Not sure what the corrective action is, though. Neither do I :-(. > Could the setting permissions piece be moved after the > files are installed? It would make more sense to a user that something was > taking a while then... It's not part of our code, but some standard routine the installer does. I guess they usually don't have to take care of thousands of files.
Michael: could we write in a 'clean up' routine to the installer? to empty select parts of the cache file during an install
The only reson I reported it is because it seemed to be taking long enough that I thought that the install had hung, etc. and that others would to. The 1 extra minute or so install time I wouldn't think would be critical. Adding another piece of text and/or changing the label a bit while it is processing (how about something like "veryifying installation location and settings - may take a minute") would clear it up for me.
Matt: your thoughts on adding text to the Windows installer as Doug suggests?
James - this is less of a design problem, than a technical problem. There's no (simple) way to add that message to the installer, as it's part of the installer's routine tasks which we can't influence. We could disable this and add our own code, but I'd rather not want to do this. I'll see whether we could partially exclude the action so it doesn't go through our cache folders.
Agree with Michael, the correct fix is for this to not take 1 1/2 minutes :). Barring that fix, since this sounds like an unusual case, I'm fine with providing a dialog box (and yes a progress bar would be great) that is appropriate - open to suggestions on the syntax.
Not sure that it is really an unusual case. It occurs anytime you upgrade without deleting first - probably the normal case? Or do I upgrade oddly? Granted you don't upgrade that often unless you run beta, though... Too bad you just can't change the text a bit.
Strill trying to figure out whether we can customize that message at all... Doug: how many tracks do you have in your collection? How many files and folders are below our cache folder (see folder properties)? James: > Michael: could we write in a 'clean up' routine to the installer? to empty > select parts of the cache file during an install Cleaning those folders up would only help us customize the message, but not improve the user experience. Removing them will take the same or longer amount of time as checking the permissions. But otoh the user would have to do a rescan after the installation to restore his data. The files in there are mostly cached artwork files which we create during the scan to speed up display in web UI and on the Controller.
6861 tracks, total. Cache folder has 5525 files and 3517 folders.
== Auto-comment from SVN commit #30396 to the slim repo by mherger == == https://svn.slimdevices.com/slim?view=revision&revision=30396 == Fixed Bug: 9698 Description: the Artwork cache folder can contain several thousands of files. The Windows installer would check permission on all of these files during the "creating directories" stage of the installation. This lead several users to think the installer had crashed. Now that we no longer use the Artwork cache folder we should get rid of it to speed up updates. Please note that you'll not notice any improvement the first time you install this update, as removing the folder will take the same amount of time as checking permissions. But subsequent updates will no longer see this delay.
(In reply to comment #22) > == Auto-comment from SVN commit #30396 to the slim repo by mherger == > == https://svn.slimdevices.com/slim?view=revision&revision=30396 == > > Fixed Bug: 9698 > Description: the Artwork cache folder can contain several thousands of files. > The Windows installer would check permission on all of these files during the > "creating directories" stage of the installation. This lead several users to > think the installer had crashed. > > Now that we no longer use the Artwork cache folder we should get rid of it to > speed up updates. > > Please note that you'll not notice any improvement the first time you install > this update, as removing the folder will take the same amount of time as > checking permissions. But subsequent updates will no longer see this delay. closing this one