Headliner II

Sonos with node.js, my attempt!

391 replies
110099 views

INFO

Source code here: https://github.com/jishi/node-sonos-http-api
Sonos Web Controller draft (work in progress!): https://github.com/jishi/node-sonos-web-controller
Sonos IR control (requires lircd and IR reciever): https://github.com/jishi/node-sonos-remote-control

==============================================================

I know that there already is an attempt at this by this guy: http://forums.sonos.com/showthread.php?t=32643, but I found it to be a bit lacking in functionality so I decided to write up my own.

I have created a simple web-based API using what I have, which could be useful for integrating stuff with other applications. This web based API is inspired by other RESTful APIs, however I don't think it follows the correct guidelines to be called a REST API.

IT supports most basic features like:

play, pause, seek, next, prev, volume, mute, setAVTransportURI

It also supports these advanced fatures:

State of player as JSON, zone info as JSON, Play favorite item, presets (grouping, volume, avTransportURI)

You can read more in the README for each project.

To run it as a service under linux, I suggest using pm2 (https://github.com/Unitech/pm2). You need to run it in forked mode (-x)!

For Windows, you might try Winser http://jfromaniello.github.io/winser/

Cheers!

This topic has been closed for further comments. You can use the search bar to find a similar topic, or create a new one by clicking Create Topic at the top of the page.

Show previous replies

S

steelrat

Trending Lyricist I

Agreed.... I've got node running in a ubuntu vm, and hosting from there....

So far any testing from desktops and the netbook are working.... Haven't tried the ipad, or the "phablet", phones....

Definitely great work.....

S

steelrat

Trending Lyricist I

Hey J,

Been running the controller through pm2 for just over an hour now....

I've noticed on the "pm2 list", that the memory in use seems to be "slowly" increasing from:

22.5 mb, up to currently 41.992 mb....

Not saying there's a memory leak, as I have no idea what exactly pm2 is reporting for memory utilization. And a lot of that time it would seem that the "page" is in the background browser window.

But I thought you should know, since it's maybe something related to the node 10.0.21 build I've got vs your 0.8.x....

J

jishiAuthor

Headliner II

I haven't really looked into the memory utilization yet, so any observations are of interest.

I don't know how aggressive the garbage collect in node is, and if you have a lot of free memory I wouldn't be surprised it the memory usage seems high. When you've had it running for a few days, it would be nice to hear what your consumption would be.

J

jishiAuthor

Headliner II

And a lot of that time it would seem that the "page" is in the background browser window.

Could you explain what you mean by that?

Y

ynot

Contributor I

I can report after 36 hours of continuous run time node shows no significant change in memory utilization. Configuration is:
freeBSD 9.1
node - development 0.9.3
Web Clients include: Windows, Puppy linux, Ipad, Z10 and Android.

Thanks

J

jishiAuthor

Headliner II

Current status:

http://upload.grabbarna.se/files/sonos-web-controller-0.4.2.png, you can update it like usual (git pull, rm -r node_modules, npm install)

I have added functional queue listing, which means that it list the queue of the selected zone and you can double click in it to change track. It will lazy load the album art from the players (I use all players for this to speed things up), and then cache it locally for faster access next time. First time load can be a pain though, if you have a large queue.

It doesn't lazy load the queue, but load it in batches of 100 items. On a 3000 items queue this takes approx 30 seconds on my machine, but I think the bottleneck is the Sonos players.

I haven't yet optimized the loading behavior and it is kind of heavy on the browser atm, and it will not reflect changes to the queue yet.

Regarding memory foot print, it seems like there has been some changes between v 0.8 and 0.10. In 0.8 I rarely got over 30 MB, but in 0.10 I can easily use up towards 70 MB. Some says that they have introduced a less aggressive garbage collect, which might explain this. However, it would be nice to hear about your impressions on systems with less RAM, because hopefully it would be more aggressive when you have little free RAM left.

S

steelrat

Trending Lyricist I

Heh, I still don't follow. What exactly was the problem? Didn't it update? Or did it update and you didn't expect it to?

No... it's was fine. Giving you context for the memory stuff. Didn't want you to think I was clicking around or modifying things. Just letting it do it's thing in the background. Just like to do with one of the desktop controllers....

Found after running 24+ hours, ram was between 35->50megs or so....

Bigger issue was a log file generated with pm2....

/root/.pm2/logs/[pm2-name]-out.log

Was 35ish meg.

tail/view the log file, it was all the info dumps server.js ... When you start in console window with node server.js, it dumps a running log right... well the -out.log file was basically those screen dumps put to log file. Longer, or more activity, the faster the growth in the file.

I'm sure there's a pm2 option I need to set to prune the logs after x. I just haven't found it in the documentation.

J

jishiAuthor

Headliner II

Seems like one doesn't always have an albumArtURI for the queue and favorites, i added a fallback for it. I don't think it has anything to do with socket.io, at least the error show no indication of that.

I also added dynamic favicon and title. Maybe it's just confusing if it keeps changing the favicon, however I thought it was nice :)

Anyway, I just pushed an update for sonos-discovery and the web controller, update as per usual. I have also lowered the amount of output generated from the process, especially from socket.io, which will greatly reduce the log file size.

D

danielschell

Contributor III

Hey guys, great project - I'm looking forward to getting this up and running.

I've tried getting this up and running on my NAS and think I'm pretty close but may have possibly run into a bug.

I git cloned the latest web controller, ran npm install and started node server.js which seems to start fine, but once I browse to the website it half loads and crashes - it appears to be related to album art.

code:


# node server.js
scanning for players...
   info  - socket.io started
http server listening on port 8080
creating cache dir failed, this is probably normal { [Error: EEXIST, mkdir './cache'] errno: 47, code: 'EEXIST', path: './cache' }
trying to subscribe to topology 192.168.188.26
subscribing to events 192.168.188.25 Lounge Room RINCON_000E58B0B84E01400 600
subscribing to events 192.168.188.26 Bedroom RINCON_000E5880C3F401400 600
topology change emit
trying to subscribe to topology 192.168.188.25
triggering state volume Bedroom 6
calculating group volume Bedroom
Lounge Room "urn:schemas-upnp-org:service:ContentDirectory:1#Browse" STATUS: 200
triggering state volume Lounge Room 16
calculating group volume Lounge Room
trying to subscribe to topology 192.168.188.50
Bedroom "urn:schemas-upnp-org:service:ContentDirectory:1#Browse" STATUS: 200
Lounge Room "urn:schemas-upnp-org:service:ContentDirectory:1#Browse" STATUS: 200
fetching album art from 192.168.188.25
fetching album art from 192.168.188.26
fetching album art from 192.168.188.25
fetching album art from 192.168.188.26
404 'linking' 'L2dldGFhP3U9eC1maWxlLWNpZnMlM2ElMmYlMmZkcm9ibyUyZm11c2ljJTJmQXVkaWFibGUlMmZBdEhvbWVBU2hvcnRIaXN0b3J5b2ZQcml2YXRlTGlmZVVuYWJyaWRnZWRQYXJ0MV9tcDMzMl9kYW5pZWxzY2hlbGwuYWEmdj0yNzk='
serving /getaa?u=x-file-cifs%3a%2f%2fdrobo%2fmusic%2fAudiable%2fAtHomeAShortHistoryofPrivateLifeUnabridgedPart1_mp332_danielschell.aa&v=279

stream.js:81
      throw er; // Unhandled stream error in pipe.
            ^
Error: ENAMETOOLONG, open './cache/L2dldGFhP3U9eC1maWxlLWNpZnMlM2ElMmYlMmZkcm9ibyUyZm11c2ljJTJmTWFqb3IlMjUyMExhemVyJTI1MjAtJTI1MjBGcmVlJTI1MjB0aGUlMjUyMFVuaXZlcnNlJTI1MjAoMjAxMyklMmYwMSUyNTIwWW91J3JlJTI1MjBObyUyNTIwR29vZCUyNTIwKGZlYXQlMjUyMFNhbnRpZ29sZCwlMjUyMFZ5YnolMjUyMEthcnRlbCwlMjUyMERhbmllbGxlJTI1MjBIYWltJTI1MjAlMjUyNiUyNTIwWWFzbWluKS5tcDMmdj0yOTA='
#

Screenshot of how much loads can be found here:
https://www.dropbox.com/s/f8bnu621qcevxbb/webcontrollercrash.png

Any suggests would be appreciated!

J

jishiAuthor

Headliner II

Hi, yeah got the same report from another user. I have pushed an update which will use a hash for filename instead, which will prevent the filename too long error.

run a git pull and try again. No changes to the dependencies so you don't need to remove the node_modules folder or run npm install this time.

Show more replies

Sign up

Login to the community