Bugzilla – Bug 1212
Adding item to playlist does not update properly
Last modified: 2008-08-18 10:54:04 UTC
Status.xml doesn't properly output the playlist when adding a song with the "p0=playlist&p1=add" syntax. The problem does not seem to occur during normal use of any of the skins except ExBrowse2/Default2. Within ExBrowse2, adding a single song causes the playlist count to update correctly, but the actual list does not update until the next refresh. This can be up to 5 seconds later. Both the add and the subsequent refresh use status.xml, not status_header or playlist. I've confirmed that slimserver does generate a status.xml with the correct "songcount" parameter but an incorrect playlist, so it's not just a Javascript issue. This only occurs with "p0=playlist&p1=add&p1=[% itempath %]". Using "command=playlist&subcommand=addtracks&track=[% item %]" works perfectly within ExBrowse2, so I could use that as a workaround for 6.0.0. Is there a better way of adding a single song by id? I'm guessing that this has something to do with svn 2528, keeping a pre-rendered cache of the now playing list on the server.
I can't actually find anywhere that 'add' is recognized as a valid command. Go ahead with the workaround for now.
I thought it was a synonym for "append". I'll check if using append fixes it.
Nope, still broken with "append". Workaround coming for 6.0.0.
Heya - we're trying to get 6.0 out tonight.. think you'll have a fix soon? :)
I'm working on it now, maybe an hour or so?
Jacob - I just took a look at this. Sending "playlist add itempath" on the CLI works fine. I notice a typo in your bug report - with p1=itempath - if that was the case in the code, it should really be p2
Typo in the bug report. I just checked svn and it was using p2=. Fooey. Does the CLI method report the new playlist immediately, or are you using an additional command to check it?
The CLI reports it immediately - and if I look at softsqueeze, it's been updated.
Jacob - have you had time to look at this? I'm going to assign it to you for now.. trying to get my bug list in manageable shape. Please reassign back if this is a real issue. Thanks.
I'll look at it some more. It's not affecting anything at the moment, since I switched all my skins to use addtracks/loadtracks instead.
Here's a new issue, but they seem to be related, so I'll put it here. Thanks to dbls for noticing this. Switching skins via the settings page causes the old playlist template to be partially used. The wrapper (playlist.html) is correct, but the items themselves (status_list.html) are not properly regenerated. When the list is modified, each item outputs correctly. This happens across all skins, although not when they are accessed explicitly with /SkinName/. Back to you, Dan...
could you please confirm this skin problem with the latest nightly? I noticed this a while back and put in a fix to reset the playlist cache when skin is changed. Remember, just changing the skin setting is never valid, you must still click the "click here to refresh" link, since changing the setting does not have any way to tell teh browser to reload.
Jacob: can you open a new bug with the info in comment 11? The other issue appears to be resolved. Thanks.