Bugzilla – Bug 3082
player frame refreshes without any delay sometimes in firefox 1.5
Last modified: 2008-09-15 14:39:24 UTC
Sometimes(!) when I open de slimserver interface with fishbone, the player frame (top right, above playlist) goes into a loop of refreshes so fast that it remains blank (and black too). I can't really tell if it is related to this thread: http://forums.slimdevices.com/showthread.php?t=14907, I don't really think so, because I don't have any of those settings set to true. I think this started happening when I installed firefox 1.5 (now at 1.5.0.1). At the time I was running slimserver 6.2.x on linux. The client was running on another linux machine or on the same machine. PS, would the interface not benefit greatly from an AJAX makeover?
I've never seen this. Can you provide more details on how to reproduce this on demand?
I'm not sure how much and what kind of detail you need for this. I can't reproduce it in another browser (konqueror refuses to show anything but an error when connecting to the slimserver, opera doesn't show me anything). This is kind of worrying, perhaps I need to try a clean re-install... The Linux distro is mandriva 2006.0 with updates. The last version of slimserver I installed/upgraded to was slimserver-2006_02_25-1.noarch.rpm. If necessary I can run a tcpdump/ethereal to track the specific exchange?
you could try wiping the templates cache (/usr/local/slimserver/Cache/templates, or maybe ~/Cache/templates) This will clear up anything that might have been cached from your last install of 6.5 the refresh timing is delivered by the server, so I expect you might run into this with any skin. It may have to do with mixed up metadata from a track since the server does try to trigger a refresh near a song transition and adjusts the refresh timing down when that event is less than the server preference for refresh timing. It is also different if you have no players connected when you load the web interface.
I don't see the problem (but the player is not playing right now) after removing /usr/local/slimserver/templates (/usr/local/slimserver is set in /etc/slimserver.conf as cache dir, for some odd reason) (I suppose that it's still a kind of bug, but then for upgrades not cleaning the cache ;-) I'll keep an eye on it over the next few days. I'll do a complete re-install after cleaning away everything to see what the current configuration looks like... /Simon
I've seen it happen again on the "clean" install of 6.5 nightly (of that one I installed earlier in this report). I haven't re-installed yet with the cache in a sensible place (not /usr/local/slimserver, but something like /usr/local/slimserver/cache), so it may still be a config problem. But it was over for a while and after a while (not sure if the host was restarted during this period) it did happen again. still keeping an eye out... /Simon
This still happens with the nightly of 6.5b1 of 25th of March. I've moved the cache directory to /var/cache/slimserver (not that it matters) It seems to happen if I do this: - Play random mix of songs - stop the playing - move the files away that are in the playlist - start playing (don't even know if this is necessary) But there may be more things that cause this (whatever it is)
if you have moved the files away, then the server will see unreadable tracks, and skip through them. This will also mean a zero duration, thus a minimum refresh (set in the server as 5 seconds. This is also intended to time the refresh near a song transition. Nevertheless, the song skipping should stop at the end of playlist regardless of repeat setting, and the refreshing should go back to 30 once the playback is "stopped". Granted, this couldd be a long run for a very long playlist, but deliberately removing all the files is a bit of a contrivance too ;) The real point is, does 5 seconds seem to be fitting for what you describe as "without any delay"? or does the real problem have nothing to do with what I've said above, and is refreshing faster than 5 seonds? If you can managed to trap a page long enough to view source, it would be interesting to know what the META lines contain.
I think the problem is due to a script in the randomplay plugin page (also in trackstat plugin) that refreshes the status pan. When you reload the browser, a cookie will try to restore the last page chosen on the browser side. It seems that if the status page isn't loaded yet, the script gets locked up trying to refresh a bugus location. I've got a potential fix that I will put into 6.5 tonight to check that there is a valid location in the status side before refreshing. Please give tomorrow's build a run and see if you can reproduce the bug or not.
Simon - did KDF's fix work for you? Thanks.
is there anybody...out there??
in the absence of any other reproduceable case, or any reponse regarding any continuing issues, I'm marking this one fixed. Please re-open if this problem occurs again.