Bugzilla – Bug 2184
Safari Refresh generates new MusicMagic playlist
Last modified: 2011-11-06 23:22:46 UTC
2005-09-24 nightly. A Safari reload stops a Music Magic Mix playlist playing + the browser interface is not being updated when tracks are added to playlist. The problems appear to be specific to Safari (I am using 2.0.1). They do not happen with Firefox or Internet Explorer. 1. Create a Music Magic Playlist by clicking the "m" icon next to a track 2. Click the Play icon beside "This entire playlist" at the top of the playlist. The first track in the playlist starts playing. 3. On the browser "Music Player" interface (right hand side of browser), "Now Playing" shows the first track in the playlist. "THE CURRENT PLAYLIST" is empty and the rest of the MMM playlist is not shown (see screen shot 1) 4. Do a browser reload. The music stops and the browser refresh takes approximately 10 seconds. The browser "Music Player" interface shows Stopped. "THE CURRENT PLAYLIST" shows the first MMM playlist. The browser "MusicMagic Mix" interface (left hand side of browser) shows a NEW mix based upon the original seed track. (see screen shot 2) Browser reloads do not affect non-MMM playlists however there appears to be another bug where "THE CURRENT PLAYLIST" requires a browser reload to display a track added to the playlist. 1. Click the Play icon beside a track. The tracks starts playing and "Now Playing" on the browser "Music Player" interface shows the track title. 2. Click the + icon beside a track. "The Current Playlist" remains empty and the track added to the playlist is not shown. 3. Do a Browser reload. The track added to "The Current Playlist" is now shown. The problems still happen after doing a Reset and Empty Cache on Safari.
Created attachment 850 [details] screen capture 1 Current Playlist empty and does not contain the rest of the playlist.
Created attachment 851 [details] Screen capture 2. After browser refresh. Music stopped. Current Playlist shows first playlist. New playlist has been generated on left hand side of browser.
kdf - any ideas here? I've been noticing similar (and not just MMM) when using Safari.
all skins or just default? the mmm case isn't unique, but does happen to require two bits of magic to happen at once. passing a listref to playtracks is tricky, as is controlling a refresh when the command is directed at a template that isn't status_header or status.html. it would help to know if this is all skins or perhaps which ones fail/pass. also, try d_source and d_command to see what is stopping the playback. thanks.
two things here. the status page load, which is supposed to trigger a reload of the playlist, does not work in safari. second, and far more stupid and annoying: Safari does a full browser reload keeping the frames in the previous state! this means the musicmagic query is redone, AND the command to start playback is RESENT to status_header.html. I'm fairly sure this must be something new, in both cases for safari. I'm not really very adept at debugging with safari, nor familiar with its inner workings. I'll do some searching, but I'm really not having a good feeling about this second issue.
Created attachment 853 [details] Traces during browser reload Two sets of debug traces with d_source and d_command. MMM playlist was played then Safari reloaded. The song stopped playing each time.
I quickly tried a few other skins. Fishbone: the music stopped when doing a browser reload and the full playlist did not appear under "The current playlist" Purple: the music stopped for a few seconds then started playing the first track in the playlist from the beginning. The complete playlist does appear under "The current playlist". Bagpuss: the music stopped for a few seconds then started playing the first track in the playlist from the beginning. The complete playlist does appear under "The current playlist".
The page-not-updating issue should be fixed in change 4528. I made the JS include a timestamp in the URL, to absolutely force a refresh.
sadly, full refresh is still going to be an issue. jacob's patch only gets the playlist load working. a page reload in safari will still re-issue commands in the frameset urls.
kdf - what's the status here? Do you have a patch?
nope. I can't find any info about this. As far as I can tell, safari seems to do this all on its own. A full browser refresh seems to remember the url for each frame. unless we follow all of our commands with a secondary reload of the frame using a blank url, I have nothing to offer on this aside from the aforementioned observations. I may, in fact, be totally wrong on what is really happening. that's just my best guess.
perhaps faking a for POST will do what we need. I've tried out a quick and dirty test: <FORM METHOD="POST" NAME="myForm" action="[% webroot %]status.html?player=[% player %]" target="status"> <INPUT TYPE="HIDDEN" NAME="listref" VALUE="musicmagic_mix"> <INPUT TYPE="HIDDEN" NAME="command" VALUE="playlist"> <INPUT TYPE="HIDDEN" NAME="subcommand" VALUE="addtracks"> <INPUT TYPE="HIDDEN" NAME="player" VALUE="[% player %]"> </FORM> <td><A HREF="javascript:" onClick="document.myForm.submit();return false">test link</A><td> Using this form, the status pane URL is still generic. I'll have to test with safari to confirm that it works. I also still need to see if this can be worked into the current templates in a way that isn't completely horrible (like it is now)
just noticed something else. the old p0-p6 params seem to disappear from the url if used. the command/subcommand params seem to persist. Removing those would also solve the problem. however, I dont yet know where those differences are created.
nix that last one. I'm clearly on drugs. The p0-p4 params are there. I just must have caught the refresh at the right timing. using the post does work to avoid the restart of playback, but the mix is still regenerating. The mixerlink would have to be a form as well, and this makes it complicated.
Created attachment 902 [details] test option This is a test patch, that may work. This creates a form for the mixerlink, so that the mix wont be regenerated. There is also a new link at the top of the mix list for "this entire playlist" which will do the play command via a form post. This will allow safari to reload the full window, with the drawback of disallowing any specific frame reload via a right click menu (it warns about resending POSTDATA). let me know if this seems ok, or what might be the best way to handle the UI with these changes.
Seems to work fine in 6.2b2, thanks.
Closing this, as Mike says it works now.
oops, I closed this too soon. The original bug mentioned 3 problems, a) the now playing song list in Safari wasn't being updated after adding songs to the playlist b) Doing a Safari refresh stopped the music playing c) Doing a Safari refresh generated a new MMM playlist The first 2 problems are fixed but the third still exists- if you generate a MMM playlist in Safari then do a refresh, a new MMM playlist is produced. To be honest, I'm not that bothered about the remaining problem and it looks pretty complex given the comments on the bug report so I'll leave it up to you guys how you want to handle this - but I won't be complaining if it isn't fixed in 6.2. Thanks,
Yeah - let's push C) off to 6.5 - it seems to be a more complicated fix.
Steven to try to reproduce.
I still see the behavior described in Comment #18 in SqueezeCenter 7 with the classic skin. With the new default skin if one was to do a refresh the left pane is returned to the home menu. So in a way this is not an issue with the new default skin. I may have stumbled on another manifestation of this bug though. Using the classic skin in Safari, if I add tracks to the current playlist, either a single track or multiple tracks, and do a refresh, those tracks will be added again to the bottom of the current playlist. Each time I hit refresh more of the same tracks will be added. It does not seem to matter what is current on the left pane and this is independent MusicIP. This does not happen in the new default skin or Firefox either.
the reason the new default skin works is that most commands are done via a background JS call, rather than an http query to a frame. No query, no problem with reloads on safari.
Chris, I was able to reproduce the described behavior in SC7 so I changed the version to 7.0a1 and assigned it to you.
Unassigned bugs cannot have a priority.