Bugzilla – Bug 16404
invalid JSON from server
Last modified: 2012-01-09 08:40:15 UTC
from time to time I get invalid JSON from server 7.5.1: -------------- 2010-07-26 23:12:34.798 SqueezePad-iPad[602:207] <0x1d39d0 JSONResponseEvaluator.m:(90)> Dropping invalid JSON-message: [{"data":{"seq_no":0,"mixer volume":27,"player_name":"Living Room","playlist_tracks":1,"player_connected":1,"time":11,199,"mode":"pause","playlist_timestamp":1280178454,19925,"remote":1,"rate":1,"power":1,"playlist mode":"off","playlist repeat":0,"playlist_cur_index":"0","playlist_loop":[{"playlist index":0,"id":-68341456,"title":"Blue Moon","coverart":"0","artist":"Radio Fritz 102.6","duration":"0","remote":"1","artwork_url":"http://radiotime-logos.s3.amazonaws.com/p235703q.png"}],"signalstrength":49,"remoteMeta":{"id":-68341456,"title":"Blue Moon","coverart":"0","artist":"Radio Fritz 102.6","duration":"0","remote":"1","artwork_url":"http://radiotime-logos.s3.amazonaws.com/p235703q.png"},"playlist shuffle":1,"current_title":"Fritz vom rbb live hören - www.fritz.de (c) Rundfunk Berlin-Brandenburg","player_ip":"192.168.1.10:36270"},"id":"10","channel":"/ae8a735f/slim/playerstatus/00:04:20:17:1d:38","ext":{"priority":""}}] --------- This prevents status updates as my JSON parser is quite strict (but I also guess that SqueezePlay might get into trouble with these). Problem here is the part "playlist_timestamp":1280178454,19925 The decimal point uses german number format (and the comma is also a JSON delimiter). Probably the timestamp also should have decimal points - but with this radio stream it seams to happen.
I assume your OS locale is set to German format for numbers?
yes: root@STEMUSIC:/ locale LANG=de_DE@euro LC_CTYPE="de_DE@euro" LC_NUMERIC="de_DE@euro" LC_TIME="de_DE@euro" LC_COLLATE="de_DE@euro" LC_MONETARY="de_DE@euro" LC_MESSAGES="de_DE@euro" LC_PAPER="de_DE@euro" LC_NAME="de_DE@euro" LC_ADDRESS="de_DE@euro" LC_TELEPHONE="de_DE@euro" LC_MEASUREMENT="de_DE@euro" LC_IDENTIFICATION="de_DE@euro" LC_ALL=
Hi Andy, and progress on this ? Today I got a second parameter with wrong encoding: "time":2509,156 Here is the full JSON I received from the server: 2010-08-16 22:46:33.735 SqueezePad-iPad[384:207] <0x6324f40 JSONResponseEvaluator.m:(97)> Dropping invalid JSON-message: [{"data":{"seq_no":"12","mixer volume":0,"player_name":"Duet Controller","playlist_tracks":1,"player_connected":1,"time":2509,156,"mode":"play","playlist_timestamp":1281938036,38556,"remote":1,"rate":1,"power":1,"playlist mode":"off","playlist repeat":0,"playlist_cur_index":"0","playlist_loop":[{"playlist index":0,"id":-78918888,"title":"Blue Moon","coverart":"0","artist":"Radio Fritz 102.6","duration":"0","remote":"1","artwork_url":"http://radiotime-logos.s3.amazonaws.com/p235703q.png"}],"signalstrength":0,"remoteMeta":{"id":-78918888,"title":"Blue Moon","coverart":"0","artist":"Radio Fritz 102.6","duration":"0","remote":"1","artwork_url":"http://radiotime-logos.s3.amazonaws.com/p235703q.png"},"playlist shuffle":0,"player_ip":"192.168.1.3:35163","current_title":"Fritz vom rbb live hören - www.fritz.de (c) Rundfunk Berlin-Brandenburg","waitingToPlay":1},"id":"6","channel":"/8efa0cde/slim/playerstatus/00:04:20:1b:25:88","ext":{"priority":""}}]
The problem doesn't happen when I reboot my SheevaPlug. This only seems to happen after I did a /etc/init.d/squeezeboxserver stop /etc/init.d/squeezeboxserver start very strange, as I wouldn't expect it to make a difference. Maybe when SheevaPlug is started, the squeezeboxserver is starting before the language settings are applied? And after I manually restarted the server it runs under a german locale. (I'm still running 7.5.x)
At the risk of stating the obvious, the server should convert the number to a string, and then replace commas with periods, before adding it to the JSON object. Also, it's often a good idea to pass numbers (everything except boolean values, really) as strings, i.e. enclosed in double quotes. If this had been done in this case, only the "time" and the "playlist_timestamp" values would have been invalidated, not the entire JSON object. It would then have been easier to make a patch to correct it client-side before parsing.
Andy - shouldn't the JSON encode create _valid_ JSON, which means no localization on numbers? We could of course make sure all those numbers are converted to strings manually, but this seems a poor plan.