Bugzilla – Bug 14848
Rhapsody menus don't add single track through SqueezePlay
Last modified: 2010-03-21 10:39:05 UTC
The SP Rhapsody menus will never add a single track but always a whole playlist since "add" always issues an "addall". This is independent of the players "play other songs in album" setting, anyway this setting should not have any effect on "add", shouldn't it, single tracks should always be added, right? Example of a menu item within a Rhapsody playlist: { actions => { add => { cmd => ["myapps", "playlist", "addall"], itemsParams => "params", params => { favorites_title => "7. The Pebble And The Boy by Paul Weller from Catch-Flame!", favorites_url => "rhapd://Tra.10874949.mp3", isContextMenu => 1, item_id => "b90af083.6.0.0.2.0", play_index => 17, type => "link", }, player => 0, }, "add-hold" => { cmd => ["myapps", "playlist", "insert"], itemsParams => "params", params => { favorites_title => "7. The Pebble And The Boy by Paul Weller from Catch-Flame!", favorites_url => "rhapd://Tra.10874949.mp3", isContextMenu => 1, item_id => "b90af083.6.0.0.2.0.17", type => "link", }, player => 0, }, go => { cmd => ["myapps", "playlist", "playall"], itemsParams => "params", nextWindow => "nowPlaying", params => 'fix', player => 0, }, more => { cmd => ["myapps", "items"], itemsParams => "params", params => { favorites_title => "7. The Pebble And The Boy by Paul Weller from Catch-Flame!", favorites_url => "rhapd://Tra.10874949.mp3", isContextMenu => 1, item_id => "b90af083.6.0.0.2.0.17", menu => "myapps", type => "link", }, }, }, params => 'fix', playAction => "go", style => "itemplay", text => "7. The Pebble And The Boy by Paul Weller from Catch-Flame!", },
Ben to look into this, should be a simple fix
== Auto-comment from SVN commit #29011 to the slim repo by bklaas == == https://svn.slimdevices.com/slim?view=revision&revision=29011 == Fixed Bug: 14848 Description: consensus is that add should only add single track and never the entire album changed command to do that only
I'm still seeing this in r29204 In addition, I also now see the behavior from https://bugs-archive.lyrion.org/show_bug.cgi?id=14617 [09-11-14 23:20:57.5452] Slim::Web::Cometd::handler (143) Cometd request: [ { channel => "/slim/request", data => { request => [ "00:04:20:26:00:4d", [ "napster", "playlist", "addall", "isContextMenu:1", "play_index:4", "favorites_url:napster://track:30151513.wma", "favorites_title:Do You Mind by Robbie Williams from Reality Killed The Video Star", "type:link", "item_id:f28cb034.1.1.0", "favorites_type:link", ], ], response => "/527eda8f/slim/request", }, id => 70, }, ] [09-11-14 23:20:57.5948] Slim::Web::Cometd::requestCallback (858) requestCallback got results for /1830db13/slim/displaystatus/00:04:20:26:00:4d / 60 [09-11-14 23:20:57.5964] Slim::Web::Cometd::Manager::deliver_events (214) Sending event on channel /1830db13/slim/displaystatus/00:04:20:26:00:4d to 1830db13 [09-11-14 23:20:57.6013] Slim::Web::Cometd::Manager::deliver_events (228) Delivering events to 1830db13: [ { channel => "/1830db13/slim/displaystatus/00:04:20:26:00:4d", data => { display => { "icon-id" => "/html/music/cover.png", style => "add", text => [ "to play next...", "Do You Mind by Robbie Williams from Reality Killed The Video Star", ], type => "mixed", }, type => "showbriefly", }, ext => { priority => "" }, id => 60, }, ] [09-11-14 23:20:57.6033] Slim::Web::Cometd::sendHTTPResponse (669) Sending Cometd chunk: [{"data":{"type":"showbriefly","display":{"icon-id":"/html/music/cover.png","text":["to play next...","Do You Mind by Robbie Williams from Reality Killed The Video Star"],"style":"add","type":"mixed"}},"id":"60","channel":"/1830db13/slim/displaystatus/00:04:20:26:00:4d","ext":{"priority":""}}] [09-11-14 23:20:57.6076] Slim::Web::Cometd::handleRequest (835) Request for /527eda8f/slim/request / 70 is not async [09-11-14 23:20:57.6094] Slim::Web::Cometd::Manager::deliver_events (214) Sending event on channel /527eda8f/slim/request to 527eda8f
see above. Still seeing this.
Looking at the comet responses from napster track listings, the 'actions'->'add' handler for a track item is still coming back as 'addall' actions => { add => { cmd => ["napster", "playlist", "addall"], itemsParams => "params", params => { favorites_title => "Prizefighter by Eels from Hombre Lobo", favorites_type => "link", favorites_url => "napster://track:28154743.wma", isContextMenu => 1, item_id => "2f9bda56.0.1.3.0", play_index => 0, type => "link", }, player => 0, }, But when the CM is raised it is correctly formatted as 'add' actions => { go => { cmd => ["napster", "playlist", "add"], nextWindow => "parentNoRefresh", params => { favorites_title => "That Look You Give That Guy by Eels from Hombre Lobo", favorites_type => "link", favorites_url => "napster://track:28154744.wma", icon => undef, item_id => "2f9bda56.0.1.3.0.1", menu => "napster", type => "link", }, player => 0, }, }, text => "Add to End", }, I believe this means its just crossed the line to something Andy needs to fix...Andy, I'm assuming the 'addall' construction is happening on SN?
MySB still runs 7.4 trunk code, it probably won't run the 7.5 code for a while.
So this may be a fix that should be back-ported to 7.4.
Why does the add action handler for the item show up as 'addall' though? The checkin for this bug doesn't cover that afaict and I don't see any code in XMLBrowser.pm that does that construction. I'm assuming that there's something on the Napster/SN side that's making that an 'addall' for the base block of the track listings...as soon as it crosses the line into your territory Andy I have no idea what's going on over there. Black box to me.
wish me luck with this one...
== Auto-comment from SVN commit #29517 to the slim repo by michael == == https://svn.slimdevices.com/slim?view=revision&revision=29517 == Fixed Bug: 14848 Description: backport changes 29011 and 29225 from 7.5 to 7.4 in order to fix the issue on mysb.com. Don't play full playlist when only one track should be played.
Is this one certainly fixed? I am on latest 7.5 nightly (SqueezeboxServer-7.5.0-29526.exe) and using IPENG I am now unable to add anything using ipeng to the end of the playlist, before I was on standard 7.4 build and if I added one track it would add the whole album but like i say now it wont add anything. Cheers Stu
> Is this one certainly fixed? It's a mysb.com server side thing. The change has been implemented, but not rolled out to the production systems yet.
(In reply to comment #12) > > Is this one certainly fixed? > > It's a mysb.com server side thing. The change has been implemented, but > not rolled out to the production systems yet. any ideas on timescales? don't want to sound impatient but just dont know how you manage these rollouts, are multiple fixes rolled on to prod at once or as they come up. Cheers Stu
I'm seeing the behavior Stu mentions even on test.SN I can not "add" anything - neither single tracks nor whole albums - on Rhapsody. Play and Play Next works as expected, it's just "ADD".
Could you please set logging for formats.xml to info, then try again. You should see some log entry like "Playing/adding all items: ..." or "Playing one item: ..." Around Slim::Control::XMLBrowser line 780
Umm.. Michael, this is SN, can't log there. I'll try to extract the commands through iPeng and will post.
Just to clarify: test.SN
> Umm.. Michael, this is SN, can't log there. > I'll try to extract the commands through iPeng and will post. SN _only_, no SBS involved? Then I'm looking in the wrong place...
This is working for me and a Touch. What player are you testing with? Please don't be mislead by the command as returned in the menu structure: even if it says "addall" it only adds the one item if that option is selected.
It does not add _ANYTHING_ if I use the command. It simply doesn't work. Maybe touch still doesn't use the commands in the menu at all? This definitely doesn't work with iPeng.
Could you please describe the exact configuration you're using: what is controlling? What should be playing? This is working fine for me, controlling a Touch using itself, through test.mysb.com. Haven't tested with iPeng yet.
Currently I'm controlling a receiver with iPeng. I believe I've seen exactly the same controlling a Touch with iPeng but will try that later. I'm not sure what Squeezeplay will send, but this is the command that is provided in the menu by the server and it doesn't work. Play works, insert works, add does not work. Same for Rhapsody and Napster. The command looks exactly the same as for play and insert (play is also a command called "playall") Here's an example of what iPeng will send, replace "addall" with "playall" and you get the play command which works: { "channel" = "/slim/request", "id" = 160, "data" = { "request" = [ "00:04:20:16:0d:8a", [ "myapps", "playlist", "addall", "isContextMenu:1", "play_index:3", "favorites_url:rhapd://Tra.18094560.mp3", "favorites_title:4. Some Unholy War (Down Tempo) by Amy Winehouse from Back To Black The B-Sides", "type:link", "item_id:01dcc7ab.12.0.1.0", "favorites_type:link" ] ], "response" = "/88612Xfa133f2ab3497fcee1d811db9a141af963223b33X0021e96c4fa5X0X1262607359Xe45edb0a/slim/request" } }
Created attachment 6416 [details] log file from SBS of iPeng controlling a Radio and trying to add a track from Rhapsody OK, I do see the same issue using SBS and could create some log. This is two tries to add a track.
Thanks for the log: [10-01-04 14:10:30.7043] Slim::Control::XMLBrowser::_cliQuery_done (777) Playing/adding all items: This line should only be hit if playtrackalbum is _set_. Could you please check whether you still have a server wide value for that pref? It used to be server wide before we moved it to per player at some point. If there's no player pref for this value, it would fall back to the old server pref. This might be what you're running into.
Should not be the issue I'm seeing if the same thing happens on SBS and directly on test.SN. Also, highly unlikely that I have an old setting in there since I never migrated any settings to Squeezebox Server so all settings I'm having were created after that name change. How do I find out whether I have a server-wide setting? I seem to have two per player in server.prefs
== Auto-comment from SVN commit #29720 to the slim repo by michael == == https://svn.slimdevices.com/slim?view=revision&revision=29720 == Bug: 14848 Description: need to send a addtracks command, not add only
J�rg - Ben and I have been trying to understand what's going on here. While my previous change should help already, your commands are still hitting the wrong path, and we don't know why. So my question is: how to you build the add/play/insert menu items used in the context menu? AFAICT they're not items returned by the CM query. But while SP is using the base action defined in that response, you seem to be using something different, very likely the actions as returned by the query for the track list. Is this correct? The problem is (as Ben mentioned in comment #5) that sometimes xmlbrowser is returning addall, when add should be used. While the context menu is correct in that regard, the track listing isn't.
So you say a base action should override an action that is sent with an item? That can't be true, can't it? I mean: how am I supposed to determine when to use what? This way around doesn't make any sense and is opposed to what's written here: http://wiki.slimdevices.com/index.php/SqueezeCenterSqueezePlayInterface "The action fields specify the command sent by Jive when the user performs an action on the item, for example presses a key. In many cases, the command to be performed is the same regardless of the item (f.e., play), only one parameter will change for each item (f.e., the item id). The syntax therefore allows actions to be defined in the [#base_fields <base_fields>] and being completed in the [#item_fields <item_fields>]. It is however possible to define completely a command at the item level. ... Actions are identified by their name, corresponding to the keys or other controls available on Jive. Actions can refer to a JSON command or a URL (this shall remain coherent between base and item level). Actions can be set as "null" to have no effect (to prevent a pre-defined or base-defined command to work on a particular menu or item)." CustomBrowse and also the Rhapsody menus do provide details menus that are supposed to override the base query. If the base command is supposed to be used, why do you send an item command at all.
To elaborate on what I do: iPeng first looks for an item action, if there is one, that's what is being used. If there is none, it uses the base query and completes it with parameters delivered with the item. I think that's how it's supposed to be.
Andy - the "addall" vs. "add" issue Ben is commenting on in #5 imho is due to the "playall" fix for bug 13462: http://svn.slimdevices.com/slim?view=revision&revision=28558 Why should a single track have a playall flag?
item actions should always take precedence over base actions.
Ok, but that's what I'm doing!
J�rg - the quest goes on... There's still a difference how play vs. add items is handled. Assuming the following snippet: { actions => { add => { cmd => ["myapps", "playlist", "add"], itemsParams => "params", params => { favorites_title => "1. Break It Down by Tony Levin from Resonator", favorites_type => "link", favorites_url => "rhapd://Tra.9574318.mp3", isContextMenu => 1, item_id => "80d86656.7.0.1.3.0", type => "link", }, player => 0, }, "add-hold" => { cmd => ["myapps", "playlist", "insert"], itemsParams => "params", params => 'fix', player => 0, }, go => { cmd => ["myapps", "playlist", "play"], itemsParams => "params", nextWindow => "nowPlaying", params => 'fix', player => 0, }, more => { cmd => ["myapps", "items"], itemsParams => "params", params => { favorites_title => "1. Break It Down by Tony Levin from Resonator", favorites_type => "link", favorites_url => "rhapd://Tra.9574318.mp3", isContextMenu => 1, item_id => "80d86656.7.0.1.3.0", menu => "myapps", type => "link", }, }, }, params => 'fix', playAction => "go", style => "itemplay", text => "1. Break It Down by Tony Levin from Resonator", }, And playing an item from iPeng's track menu, I'm seeing the following command being sent: [10-01-06 13:02:40.4071] Slim::Web::Cometd::handler (143) Cometd request: [ { channel => "/slim/request", data => { request => [ "00:04:20:16:01:1c", [ "myapps", "playlist", "play", "favorites_type:playlist", "menu:myapps", "isContextMenu:1", "favorites_url:http://www.test.mysqueezebox.com/api/rhapsody/v1/opml/library/getAllTracksForAlbumInLibrary?albumId=Alb.9571202", "favorites_title:Resonator by Tony Levin (2006)", "type:playlist", "item_id:80d86656.7.0.1.3", "icon:http://image.listen.com/img/170x170/6/8/0/3/793086_170x170.jpg", ], ], response => "/53de6eb6/slim/request", }, id => 1071, }, ] Toggling to "add" instead and pressing the same item I see this: [10-01-06 13:03:18.9866] Slim::Web::Cometd::handler (143) Cometd request: [ { channel => "/slim/request", data => { request => [ "00:04:20:16:01:1c", [ "myapps", "playlist", "add", "isContextMenu:1", "favorites_url:rhapd://Tra.9574320.mp3", "favorites_title:3. Throw The God A Bone by Tony Levin from Resonator", "type:link", "item_id:80d86656.7.0.1.3.2", "favorites_type:link", ], ], response => "/53de6eb6/slim/request", }, id => 1087, }, ] For whatever reason play is asking to play the playlist, while add is correctly asking for the single track I want. This is when pressing a track, not the "..all" item at the top of the menu. Is the play action taken from the same menu item params as for the add action? I'm using the beta you've been sending me a while back to thest the string localization issue. Don't know whether this is the latest iPeng code I should be using.
That's correct. This is because by default iPeng overrides the "play other Tracks in album" behavior -there have Bern issues with this on some Server versions and iPeng has to support them all, also it hasn't been a default in the past on SC. If you enable "Play single Tracks" in the iPeng settings it should use the item action.
He... would have been nice if you had mentioned this earlier... just spent too much time trying to figure out what was wrong there. Good to know. Could you please test my patch attached to bug 13462. IMHO it should fix this issue here as well. Thanks!
Sorry. Didn't think about it because we were always talking about "add". Will try the patch. Looks like I finally have to find out why "patch" always didn't work for me with your patches on Ubuntu :)
== Auto-comment from SVN commit #29726 to the slim repo by michael == == https://svn.slimdevices.com/slim?view=revision&revision=29726 == Fixed Bug: 14848 Fixed Bug: 13462 Description: don't send playall/addall unless user has playtrackalbum pref set. I wish us all good luck!
I'm seeing that an addall is also being sent whenever the playothertracks flag is set. Is this expected behavior? Should not "ADD" only add a single track?
I really believe this is not as it should be right now. http://forums.slimdevices.com/showthread.php?t=75800 Adding the whole album when a track is selected is not what happens on the local library, isn't it? Also, it means that there is no way to add a single track anymore. This is wrong. Reopening.
This was a design decision around the playtrackalbum pref. Note to self: find the user-facing pref in Player | Basic for users that are confused by this. Joerg, I want to accomodate you if this is a problem for iPeng. Maybe we can approach this issue by asking you to clarify your goal, and consider other ways to get to that goal? Thanks
Well, I need a command to add a single track to a playlist. I get a lot of commands by users who don't like adding whole albums. I render the Rhapsody albums as a menu, so I can't just go and issue a "playlist loadtracks id" command but I have to rely on a menu. So the "clean" way to solve this would be to provide two menu actions: "add => {}" to add a single track and "add_all" => {}" to add an album or "add_track" => {}" to only add a single track It should be said that "whole albums" in Rhapsody can be up to 300 tracks long if it's a playlist. Plus this behavior, even if it was a design decision, is NOT consistent to what happens in your local library, you will get a lot of user complaints, yet this is not my problem since for the local library I have my own commands. If you tell me that the command used in the action will always be "myapps", "playlist", "addall" and there's an alternative "myapps", "playlist", "add" command that would be valid, I could remove the ambiguity for myself and leave the complaints to you :)
Oh and add a comment to your pref that says "If you set "playtrackalbum" to "ON" then Squeezeplay will behave the following way: - Albums will always be played as a whole if you ADD a track then - if it's your local library, only this track will be added - if it's Rhapsody or Napster, the whole Album or Playlist will be added " since this is the current behavior!
BTW, does the "design decision" also include that this works differently between MySB and SBS? This is 7.5 beta and test.mysb
"Plus this behavior, even if it was a design decision, is NOT consistent to what happens in your local library, you will get a lot of user complaints, yet this is not my problem since for the local library I have my own commands." Chalk me up as one of the complainers here. How can it be the design intent to have the local library behave differently than the Rhapsody library? Please please please fix this.