h3x.se spotify remote


Roidify -> ReSpot… And a new Servify for Java release…

Decided to 'rebrand' roidify to ReSpot. Sounds a tad better at least.

In other news - a new version of the client has been released also! A bit more polished, and I've begun refactoring the code.
Unfortunately my android device (HTC Hero) has had a turn for the worse. The touchscreen is erratic/non-responding. So the latest version has not been tested on a real device.

A new version of Servify for Java is also available, a bit more stable, but has a long way to go before it's solid.
The big 'drawbacks' with the Java version;
Not as good error handling as in C# version
Sluggish to browse playlists
Sluggish to start tracks playback

As usual - you can get them here

Filed under: ReSpot, servify No Comments

Servify C# – 64bit systems now supported

The Spotify guys have updated the libspotify to version 0.0.3, and with that it now supports 64-bit systems. Still Linux only though.

The latest Servify version uses the new libspotify 0.0.3 and thus also now support 64-bit systems. Enjoy.

Update: Unfortunately Servify w/ libspotify 0.0.3 is not quite ready for prime time yet. Will post an update when some issues are ironed out. The regular Servify w/ libspotify 0.0.2 is still available however.

Filed under: servify No Comments

Servify in Java – Windows compatible

Brief update to announce Servify for Windows, written in Java. Based on Jotify.
It's quite unstable still and I expect it to improve rapidly within the coming days. Stay tuned for updates.

It's not as good as the C# / Linux version, so if you are a Linux user, continue to use the C# version.

Get it here.

Filed under: servify No Comments

You’ve Come a Long Way, Baby

New version of Roidify + Servify released. As usual Get It Here.

+ Revamped UI
+ Enqueue / Dequeue functionality

Default action in a Playlist is to Enqueue the selected track. Long click brings up the context menu.

Default action in the Playback view list is to start playback from the clicked track. Long click brings up the context menu.

Default action in the Search result is to Enqueue the selected track.


+ Code refactoring
+ Added support for enqueue / dequeue

Filed under: roidify, servify No Comments

Working on a Dream

or a new UI for the Playback screen. Ok - I may be overusing ListViews... but they're fancy!

The screenshot below contains the playback controls, volume controls and the new PlayQueue.
Interaction with the application has fundamentally changed, as you'll notice when I publish the new version. It's now possible to Enqueue and Dequeue tracks in the PlayQueue.
Default 'click action' in the Playlist Track View is to Enqueue track.
If you long-click a track or a playlist in the Playlist View a context menu popups, with options to Enqueue the song(s).
Default 'click action' in the Search Result is to Enqueue  track.

Filed under: roidify No Comments

Yet Another Release…

+Added volume controls, find them on the 'playback' tab.

Requires you to upgrade Servify + Roidify.

Also added better handling of client disconnects in Servify.

As usual you'll get it here

Filed under: roidify, servify No Comments

New version of Roidify + Servify. Let’s call it v0.1!

Finally implemented fancier listviews. It's high time to update the screenshots so here goes.

As you can see, they  look alot slicker than the earlier lists. But there's still room for plenty of GUI improvements...

As usual you can get it here!

Filed under: roidify, servify No Comments

New version of Roidify & Servify available!

Get them here : Install & Download


* should keep wifi-connection while device sleeps
* stores host & port settings
* offers to send bug-report after application crash
* various stability improvements


Need to upgrade in order to enjoy the latest roidfiy version

Filed under: roidify, servify No Comments

WifiLock’s not honored…

Been having issues with the WifiLock not being honored - causes roidify to lose connection to servify when the phone goes to sleep-mode...
It seems this may be a bug in android as described here: http://code.google.com/p/android/issues/detail?id=2059

Current workaround I'm deploying is using a WakeLock (as described in the above bug-report), however this does not alleviate the issue on it's own (or at all?). So I've further created a TimerTask that ping's the server every 5 seconds... Combined (or on its own?) is seems to do the trick.

It'd be great to see if it works on its own without the WakeLock but I'm sick of debugging the issue right now... If this works I'm happy.

This does waste more battery than ideal so let's hope that the WifiLock is fixed with later versions of Android, maybe it's fixed in >1.6.

Filed under: roidify No Comments