Squeemote connectivity issues

06 November 2010 Squeemote connectivity issues

I'd like to take this opportunity to discuss some of the issues in the recent Squeemote update.

Squeemote 1.3.5 went live at the beginning of last week. It was quite a significant update in terms of enhancements and bug-fixes (it probably could have warranted a 1.4 version).

Some of the main changes include:

  • Multi-tasking support for devices that support it
  • Enhanced artwork and support for retina displays
  • Fixed a bug with artwork caching
  • Fixed a bug that prevented Squeemote from working with the Spotify plugin properly
  • Volume control enhancements
  • Optional Wake-On-LAN support
  • Fixed some serious crashing bugs relating to playlists and bad data received from the server

Unfortunately, this version shipped with one serious crashing bug and some connectivity issues. Before I explain these in detail, first let me publicly apologise for letting this version ship with these bugs.

This isn't an excuse, but Squeemote is a very tough app to test thoroughly. Numerous combinations of devices, server platforms and versions and connectivity settings make it hard to test every possible combination and sometimes these issues slip past me and the App Store review team.

One of the biggest App Store weaknesses?

All I can do when these bugs arise is try and fix them as quickly as possible - the biggest annoyance with bugs like these is that no matter how quickly I can fix them, I'm still at the mercy of the App Store review process - to me, not being able to get critical updates out to users is one of the biggest issues with the App Store.

Nevertheless, I was able to identify and these issues reasonably quickly and with the help of some patient customers I have been able to fix both of these issues; an update (1.3.6) was submitted to Apple on Saturday morning (6 Nov) and should be with you soon.

So what went wrong?

The first issue was a crashing bug on startup that only happens if you are using a hostname rather than an IP address (e.g. myserver.local).

For most users, this won't be a problem as the automatic server detection will use the IP address of the server. If you are affected by this issue, you can work around it in the meantime by going to Settings.app on your device, locating the Squeemote settings and replacing the hostname with your server IP address.

The second issue is related to Squeemote losing it's connection to the server, resulting in controls stopping from working. I've had various reports of this issue for a while and I'm not sure that this is a problem that was introduced in 1.3.5 however with the introduction of multi-tasking support, it has become more apparent.

Until now, I hadn't been able to track down and resolve the issue so last week, I really knuckled down and resolved to fix this issue once and for all.

I'm confident that I've finally cracked this problem and Squeemote should now be far more resilient and reliable when it loses connection to the server and should re-establish it's connection straight away.

In cases where it is unable to quickly re-establish a connection (e.g. because it is waiting for a dropped WiFi connection to come back up), a "Reconnecting" screen will be displayed until it has re-established a connection.

In a future blog post, I hope to talk about some of the technical issues surrounding this problem and what I did to overcome it. In the meantime, keep an eye out for the 1.3.6 update and once again, I apologise for the inconvenience caused.