Bugzilla – Bug 2351
Reloading playlist frame causes actions to be repeated
Last modified: 2008-09-15 14:37:04 UTC
If the playlist frame is reloaded, the previous action is repeated. For example, if you click Clear in the playlist frame, the Clear happens again when the frame is reloaded. This is apparent in conjunction with Random Mix. If you clear the playlist using the Clear link in the playlist frame, then add a new mix using a link in the Random Mix frame, the playlist frame gets reloaded and promptly obliterates the newly created mix. Likewise, jump commands get reexecuted, leading to situations where new mixes start half way through (and in fact a new mix is added to the end of the first one, as a result of the extra jump being detected). In an ideal world, I believe this would be a 6.2 blocker, as the behaviour that results is very confusing!
Should have mentioned that I'm using Firefox 1.07 on Windows XP. I don't know if this happens with other browsers.
The problem is actually in the way that randomplay_list.html reloads the status frame. It simply does a reload(), without making any attempt to clear the existing url parameters. A better solution would be to replace the url with whatever is needed to make it display the right player's info and preserve whatever state is needed. The status frame is in turn responsible for the refreshing of the playlist. This code may or may not need changing to suppress stuff. I can work on this tomorrow evening but not before.
When loaded in the same playlist, Squeezebox2 will not progress from one track to the next without intervention with the SKIP button. Softsqueeze is happily able to play the lot without needing to be touched. Also, bitrate displayed in information is incorrect (100000kbps+) but I'm unsure if this is related. Using WMAs from http://www.users.on.net/~tass/audio/NewOrder/ and nightly SVN at 23rd Oct 2005.
Please ignore my comment... Was meant to add a NEW bug
Created attachment 947 [details] Patch against 6.2 to fix the problem I've attached a patch that fixes this problem by changing the reload to a replace. The replaced url includes the player and refresh=1, but nothing else. It doesn't include start (I don't know what this does!). I believe this is fine, but do tell me if you know otherwise! This patch is against the 6.2 branch. I would like it to be included in 6.2.1 if possible.
Great! Please check it in. You can merge it to the 6.2.1 branch as well.
Commited to branch. I still need to do this on the trunk.
Fixed on trunk. R4873