Bugzilla – Bug 8928
Change in response structure breaks parsing
Last modified: 2009-07-31 10:26:06 UTC
My name is Steve McNally and I maintain the code for our Crestron integration module that you can see here http://www.thecontrolworks.com/slimserver_squeezebox.htm . For some reason the upgrade to SqueezeCenter 7.0.1 & 7.1 caused our Internet Radio section to break. While troubleshooting I noticed that our module sends out a request for the list and then a status request. With SqueezeCenter 7.0.0 I would get the response for the list request followed by the status response. But with 7.0.1 & 7.1 I get the Status response first and then the list response which basically screws up my parsing. Was this changed for a reason or is it a bug? It seems like it used to respond with a first in first out behaviour and now responds with a last in first out behavior. I can fix my program to deal with it, but didn't want to put a lot of work into it if it turns out to be something that wasn't intentional on your part. Thanks for your time, -Steve Steve McNally Applications Engineer ControlWorks Consulting, LLC Crestron Authorized Independent Programmer V: 508.695.0188 F: 781.459.0237 www.controlworks.com <http://www.controlworks.com/>
please leave target fields undefined for new reports. thanks.
Andy, can you comment on this please
Can you include a sample of the input/output you're seeing?
This is what I get with v7.0.1 and 7.1 tx$ -> radiotime items 0 10 FOR-00:04:20:16:19:62\x0A tx$ -> 00:04:20:16:19:62 status - 1\x0A rx$ -> 00:04:20:16:19:62 status - 1 player_name:Duet player_connected:1 player_ip:10.3.0.52:35261 power:1 mode:play time:32 rate:1 duration:152.111 can_seek:1 mixer volume:70 playlist repeat:2 playlist shuffle:0 playlist_cur_index:4 playlist_timestamp:1217427437.22702 playlist_tracks:35 playlist index:4 id:501 title:Wind Up genre:Grunge artist:Foo Fighters album:The Colour and the Shape duration:152.111\x0A rx$ -> 00:04:20:16:19:62 radiotime items 0 10 FOR-00:04:20:16:19:62 title:RadioTime id:0 name:Local Radio type:link isaudio:0 hasitems:1 id:1 name:Browse Talk type:link isaudio:0 hasitems:1 id:2 name:Browse Music type:link isaudio:0 hasitems:1 id:3 name:Browse by Location type:link isaudio:0 hasitems:1 id:4 name:Search RadioTime type:search isaudio:0 hasitems:1 id:5 name:Browse Podcasts type:link isaudio:0 hasitems:1 id:6 name:My Presets (Please Sign In) type:link isaudio:0 hasitems:1 count:7\x0A 00:04:20:16:19:62 status - 1 player_name:Duet player_connected:1 player_ip:10.3.0.52:35261 power:1 mode:play time:32 rate:1 duration:152.111 can_seek:1 mixer volume:70 playlist repeat:2 playlist shuffle:0 playlist_cur_index:4 playlist_timestamp:1217427437.22702 playlist_tracks:35 playlist index:4 id:501 title:Wind Up genre:Grunge artist:Foo Fighters album:The Colour and the Shape duration:152.111\x0A This is what I used to get with the earlier versions tx$ -> radiotime items 0 10 FOR-00:04:20:16:19:62\x0A tx$ -> 00:04:20:16:19:62 status - 1\x0A rx$ -> 00:04:20:16:19:62 radiotime items 0 10 FOR-00:04:20:16:19:62 title:RadioTime id:0 name:Local Radio type:link isaudio:0 hasitems:1 id:1 name:Browse Talk type:link isaudio:0 hasitems:1 id:2 name:Browse Music type:link isaudio:0 hasitems:1 id:3 name:Browse by Location type:link isaudio:0 hasitems:1 id:4 name:Search RadioTime type:search isaudio:0 hasitems:1 id:5 name:Browse Podcasts type:link isaudio:0 hasitems:1 id:6 name:My Presets (Please Sign In) type:link isaudio:0 hasitems:1 count:7\x0A rx$ -> 00:04:20:16:19:62 status - 1 player_name:Duet player_connected:1 player_ip:10.3.0.52:35261 power:1 mode:play time:32 rate:1 duration:152.111 can_seek:1 mixer volume:70 playlist repeat:2 playlist shuffle:0 playlist_cur_index:4 playlist_timestamp:1217427437.22702 playlist_tracks:35 playlist index:4 id:501 title:Wind Up genre:Grunge artist:Foo Fighters album:The Colour and the Shape duration:152.111\x0A Also, just to avoid confusion, it is sending the status request before it fully receives the response. I'm thinking that is part of the problem, but it was never an issue in the past.
OK, thanks, I'll take a look and see why this changed and if it's possible to fix it. But I'm not sure you should rely on getting data back in any particular order. For example, a subscription response could come back at any time.
Thanks. I will try to make it so our system doesn't rely on the order the responses come in. Unfortunately a 90% of the code was written by someone else so it may be a ton of work on my end to get to that point. Thanks for looking into it for me.
Async data may be returned at any time, this is a won't fix. Clients should be able to handle any response in any order. Buffering async responses in order to preserve request order would result in some bad behavior, for example if a request for Rhapsody albums took 45 seconds, you'd be unable to receive any other data while waiting for that response to come back.
Hi Andy, I just had more time to look into this and realized that the problem isn't due to the order it is received. The issue that is messing us up is that the response for the radio stations now has the MAC address of the device before and after the response. I just tested it with both 7.0 and 7.1 and as an example when I send "shoutcast items 0 10 FOR-00:04:20:16:19:62" I'm getting these for responses. 7.0 shoutcast items 0 10 FOR-00:04:20:16:19:62 title:SHOUTcast Internet Radio id:0 name:By Genre type:link isaudio:0 hasitems:1 id:1 name:Top 500 type:link isaudio:0 hasitems:1 id:2 na 7.1 00:04:20:16:19:62 shoutcast items 0 10 FOR-00:04:20:16:19:62 title:SHOUTcast Internet Radio id:0 name:By Genre type:link isaudio:0 hasitems:1 id:1 name:Top 500 type:link isaudio:0 hasitems:1 id:2 na Does that make sense? Sorry for the confusion earlier.
I assume what you pasted is the output after your own app parses the response? Please use the raw output when you need to paste requests/responses. If you make a request that requires a client but don't include a client ID (such as radio requests), it will assign a random client to the request and output it back as part of the response. So you get: shoutcast items 0 10 00%3A04%3A20%3Aff%3Aff%3A01 shoutcast items 0 10 title%3ASHOUTcast%20Internet%20Radio id%3A0 name%3ABy%20Genre type%3Alink isaudio%3A0 hasitems%3A1 id%3A1 name%3ATop%20500 type%3Alink isaudio%3A0 hasitems%3A1 id%3A2 name%3ARandom%20100 type%3Alink isaudio%3A0 hasitems%3A1 count%3A3
Sorry about the format I pasted. Your response actually looks different than mine. Yours has the client id appearing only at the very beginning but mine is showing it appearing before and after the " shoutcast items 0 10 " Should it be appearing before and after that? Or is it because of the way I'm sending the request? Also, should I be asking this stuff via email instead of this bug report since it isn't really related anymore?
It's fine to discuss here. I meant that the "FOR-$MAC" part of the response is not something we include in the response, so where did it come from?
Ahhh... I just figured it out :) The "FOR-$MAC" is just being echoed back. I just spoke with the person who initially wrote our interface module and he said he was inserting the "FOR-$MAC" into the commands for browsing functions so our programming module could keep track of which client it was talking to in certain situations where a client ID wasn't needed. So what is happening is the response structure was changed to include the client id and the "extra" client id I'm seeing is just the system echoing back garbage that it doesn't know what to do with. Sorry about all the confusion. It looks like I just need to tweak our program to work with the client ID being in that section of the response.
Reduce number of active targets for SC