Bugzilla – Bug 308
changing skins causes pages to load with little or no content on them...
Last modified: 2008-06-30 12:00:39 UTC
...until server is restarted, or a different browser is used. Customer reported bug, also. STR: 1) Install 5.1.5 or latest nightly (I tested with 5/12/04 nightly) on WinXP SP1 or SP2 2) Open web interface in a web browser or SlimServer.exe (I tried IE6 on XPSP2, Safari on OSX10.3.3, and SlimServer.exe on XPSP2) 3) go to Server Settings -> Add'l Server Settings, change skin to Purple 4) Hit reload, and the pages will not load properly.
if you leave it to refresh automatically, it seems to then work.
Created attachment 32 [details] debug log I found this. Cearly it is not accepting the css file if the chosen skin has a slimserver.cdd file date earlier than the previous skin. somehow on refresh, the header is set to no-cache, so it then loads.
ok, I'm not sure how to do this, but if you can detect that the Referrer contains skin=<someskin> then that would indicate a skin change, and maybe you can then set the response not to check the $mtime on slimserver.css.
I think I've got a fix for this. Change the last line of _getFileContent to: return (\$content, time()); So that the first time we load a new file from the cache, we return a new mod time, forcing an update. Subsequent loads use the true time.
no dice on that one. seems to be even worse, unpredictable. Sometimes it would change properly, only to find that going back to fishbone meant purple fish!
seems to work ok with the cvs update May 14
I'm still seeing this here and there. Just retested last night using 5/23 (i think) nightly, and was seeing some erratic problems. Just tested this again with the 5/26 nightly and I definitely see a problem when I switch from Standard to Purple or vice versa. status_header.html does not load properly on the right side... It loads a blank document after switching from Standard to Purple, then when I switch back from Purple to Standard, it loads status.html twice on the right side (instead of status_header.html on the top and statu.html on the bottom)... Funny thing is it loads fine if i open a new tab in safari and go to localhost:9000... Another thing of note, I wasn't able to reproduce this behavior with the server installed on MacOS, but I'm seeing it on MacOS as well now (with 5/26 nightly) How can I help here?
I can't reproduce this with the latest nightly. Is it still happening?
Might the fix for bug 341 also fixed this?
I can't reproduce this here in safari, but in IE6 it's confused until I hit reload a second time.
I just got another report of this from a user. Oops, and yet another (over the phone) while I was typing this up! The gentleman I spoke with over the phone said that he was using Windows XP and SlimServer v5.2.1. But I also asked him to post to the bug... I asked for more details from the gentleman that e-mailed me, but I am able to reproduce it on: - Win XP SP2 - SlimServer v5.2.0 or v5.2.1 - Safari or IE6 or SlimServer.exe web app by doing the following: - Open SlimServer.exe - Go to Server Settings -> Additional Server Settings, change skin from Default to Purple - Click the 'Click here to refresh with the new skin' button - Go to Server Settings again, and the only thing that loads on the page is: Server Settings Squeezebox Home -------------------------------------------------------------------------------- SlimServer Version: 5.2.1 the source for the purple skin's Server Settings page with nothing showing up looks like this: <html> <head> <title>Server Settings</title> <link rel="stylesheet" href="/Purple/slimserver.css"> </head> <body bgcolor="#FFFFFF"> <p> <h3>Server Settings</h3><p> <a href="home.html?player=">Squeezebox Home</a> <hr> <form method="get" action="setup.html"> <input type=hidden value="" name="player"> <input type=hidden value="" name="playerid"> <input type=hidden value="server" name="page"> </form> <p>SlimServer Version: 5.2.1</p> </body> </html>
Created attachment 58 [details] d_http log.txt of reproducing this problem
Comment on attachment 58 [details] d_http log.txt of reproducing this problem This one is not very good. Attaching a better one.
I'm unable to reproduce this with a linux server or windows/activePerl. both IE and FireFox fully render the server settings pages. I don't have access to SP2 for XP however (btw, is this RC1 or RC2?)
Created attachment 59 [details] newer, better, faster.
It's XP SP2 RC1 I believe, but I can't figure out how to tell for sure. msinfo32 says: Version 5.1.2600 Service Pack 2, v.2096 Build 2600 Also, I could not seem to reproduce this while running with Cygwin perl. And I can't seem to reproduce it on my mac any longer, either...
Vidur: did you take a look at this?
It turns out to be a Template Toolkit problem caused by a difference between the way PerlApp-generated executables and directly invoked interpreted Perl scripts deal with the %INC hash. To cut a long story short, I think it's a bug in PerlApp and I posted something to the PDK mailing list (http://aspn.activestate.com/ASPN/Mail/Message/PDK/2117308). I've attached a stop-gap patch to our version of Template Toolkit. Let me know if it works for you.
Created attachment 68 [details] Template Toolkit patch
would this be considered fixed at this point?
Marking this one as fixed, though we're still working with the workaround - no new word of a fix to the PDK.
This Slimserver bug was fixed a very long time ago, and is now being marked as Closed. If you're still experiencing this issue, please verify you are running a current version of Slimserver and re-open the bug.