PDA

View Full Version : Implementing an alternate server



SumnerH
2007-09-04, 14:22
Hi all,

I'm interested in developing an alternate server for my squeezebox (mainly because the standard Perl server is very heavy and includes a lot of things I don't need, but also because I have a heavily customized music database already that I'd like to use).

The problem is that although I am interacting with the player (I can, for instance, change display brightness and get it to request a download on the HTTP port), I cannot get it to play any audible music.

My questions are:
1. Am I missing something to enable audio output or tell the squeezebox to actually play its buffers? I thought the "1" in strms1m should automatically start playback...
2. Is there something the httpport needs to be sending back other than a HTTP OK header and the mp3 stream? I can hit it successfully with a web browser and download the mp3, but I'm not sure if there's some additional header info that the squeezebox needs.
3. Is there a better document than http://wiki.slimdevices.com/index.cgi?SlimServerSpecification and the SlimProtoTCP, STAT, and STRM documents on that wiki for writing squeezebox server software?
4. Is there another forum I should be asking these sorts of questions in? FWIW I'm doing the initial implementation in Python on Linux/x86, but I'm planning on moving to C once the prototyping is done.

Here are the details of what I'm doing:
Setup and bind the slimproto and http(9000) ports
receive "HELO" from squeezebox (with proper deviceid)
send "vers" (so far I'm just spoofing "vers6.5.4", that'll change before I release anything but I'm trying to limit variance from the "standard" server until I have things working)
send strm message to stop any current stream ('s', 't', 'r', 'm', 'q', '0', 'm', '?', '?', '?', '?', '\xff', '\x00', '\x00', '0', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '#', '(', '\x00', '\x00', '\x00', '\x00')
sending grfb to adjust the brightness ('g', 'r', 'f', 'b', '\x00', '\x01')--this DOES cause the display brightness to change
sending aude to enable audio outputs ('a', 'u', 'd', 'e', '\x01', '\x01')
Sending audg to adjust gain ('a', 'u', 'd', 'g', '\x00', '\x00', '\x00', 'g', '\x00', '\x00', '\x00', 'g', '\x01', '\xff', '\x00', '\x00', 'r', '\x00', '\x00', '\x00', 'r', '\x00')

The above I'm queuing up, and after sending them I'm getting back
STAT null bytes (['EventCode', '\x00\x00\x00\x00'], ['NumCRLF', '\x00'], ['MASInitialized', '\x00'], ['MASMode', '\x00'], ['BufferSize', '\x000\x00\x00'], ['BufferFull', '\x00\x00\x00\x00'], ['BytesRecieved', '\x00\x00\x00\x00\x00\x00\x00\x00'], ['WirelessStrength', '\x00X'], ['Jiffies', '\x0fD\x0eX'], ['OutputBufferSize', '\x005\xd5@'], ['OutputBufferFull', '\x00\x00\x00\x00'], ['ElapsedSeconds', '\x00\x00\x00\x00'], ['Voltage', '\x00\x00']
I don't know what that indicates.
STAT STMf (presumably because of the strmq0m command)
STAT strm (I don't know what that indicates, probably just receipt of strm?)
STAT aude (likewise?)
STAT audg
Next, I'm:
Sending strm to start playing an mp3 ('s', 't', 'r', 'm', 's', '1', 'm', '?', '?', '?', '?', '\xff', '\x00', '\x00', '0', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '#', '(', '\x00', '\x00', '\x00', '\x00', 'G', 'E', 'T', ' ', '/', 's', 't', 'r', 'e', 'a', 'm', '.', 'm', 'p', '3', '?', 'p', 'l', 'a', 'y', 'e', 'r', '=', 'f', 'o', 'o', ' ', 'H', 'T', 'T', 'P', '/', '1', '.', '0', '\n', '\n')
STAT STMf (why a second one? just to indicate any old stream is dead?)
STAT STMc

Then I'm getting a connection on the http port with the GET request I had sent. I send the mp3 out the http port, and on the slimproto port I get:
STAT strm


The squeezebox is, indeed, connecting to the http port, requesting the mp3, and I'm writing the entire mp3 out successfully (it's not blocking or dropping the connection).

Unfortunately, there's no music playing. I've traced through the TCP communications from slimserver.pl and what I'm sending seems to agree with it aside from the grf* and visu commands (I've even tried adding in the STAT and duplicate audg commands to duplicate the slimserver.pl communications pretty closely)

Apologies if this is off-topic for the developers forum, I wasn't sure if this is for all slimserver dev or just of the standard perl implementation...

Thanks for your time,

Sumner

SumnerH
2007-09-05, 14:29
Okay, so now I'm getting the STMd response after an appropriate length of time for decoding. But I have a question about the contents of the STAT messages; mine look like this:
STAT 43 [['EventCode', 'stat'], ['NumCRLF', '\x00'], ['MASInitialized', '\x00'], ['MASMode', '\x00'], ['BufferSize', '\x000\x00\x00'], ['BufferFull', '\x00\x00\x00\x00'], ['BytesRecieved', '\x00\x00\x00\x00\x00\x00\x00\x00'], ['WirelessStrength', '\x00T'], ['Jiffies', '\x14xJ\xa0'], ['OutputBufferSize', '\x005\xd5@'], ['OutputBufferFull', '\x00\x00\x00\x00'], ['ElapsedSeconds', '\x00\x00\x00\x00'], ['Voltage', '\x00\x00']]
OP!!! DSCO 1 ['DSCO']
STAT 43 [['EventCode', 'STMd'], ['NumCRLF', '\x00'], ['MASInitialized', '\x00'], ['MASMode', '\x00'], ['BufferSize', '\x000\x00\x00'], ['BufferFull', '\x00\x00\x00\x00'], ['BytesRecieved', '\x00\x00\x00\x00\x00\x00\x00\x00'], ['WirelessStrength', '\x00S'], ['Jiffies', '\x14xJ\xbd'], ['OutputBufferSize', '\x005\xd5@'], ['OutputBufferFull', '\x00\x00\x00\x00'], ['ElapsedSeconds', '\x00\x00\x00\x00'], ['Voltage', '\x00\x00']]


I assume that for squeezebox v3, the MAS fields will be null (it uses software decoding, so the MAS stuff is irrelevant, right?) Are the BufferSize/BufferFull/OutputBufferSize/OutputBufferFull fields supposed to have real values on the v3 or are those null bytes fine? Suspiciously, the BufferSize field is actually \x00 "0" \x00 \x00, with the "0" being an ASCII 0--this is big-endian 16384, which seems like a possibly legit BufferSize.

But I'm always getting nulls for both BufferFull and OutputBufferFull.

Expected or a sign of problems?

SumnerH
2007-09-06, 11:06
I assume that for squeezebox v3, the MAS fields will be null (it uses software decoding, so the MAS stuff is irrelevant, right?) Are the BufferSize/BufferFull/OutputBufferSize/OutputBufferFull fields supposed to have real values on the v3 or are those null bytes fine? Suspiciously, the BufferSize field is actually \x00 "0" \x00 \x00, with the "0" being an ASCII 0--this is big-endian 16384, which seems like a possibly legit BufferSize.



But I'm always getting nulls for both BufferFull and OutputBufferFull.



Expected or a sign of problems?



It's a sign of problems, after fixing an incredibly dumb problem with CR/LF in the HTTP headers I'm now playing music successfully and the buffers are filling up.



FWIW, even with the prototype written in Python it's not a problem to continuously stream mp3s with a (software) server that is under 3.5 MB resident and maxes out around 2% CPU usage on an old Pentium 4/1.4Ghz (unsurprising since the client's doing all the decoding work).



I'm still having problems playing ogg files both with slimserver and my server (I get STMn "NOT SUPPORTED" messages back even though I'm on firmware 81), that's about the last issue I have to resolve so my first step will be to try to get them working with slimserver (6.5.4).

kdf
2007-09-06, 11:26
I'm still having problems playing ogg files both with slimserver and my server (I get STMn "NOT SUPPORTED" messages back even though I'm on firmware 81), that's about the last issue I have to resolve so my first step will be to try to get them working with slimserver (6.5.4).

There are some known issues with ogg playback:

http://bugs.slimdevices.com/show_bug.cgi?id=4819
http://bugs.slimdevices.com/show_bug.cgi?id=4723
http://bugs.slimdevices.com/show_bug.cgi?id=5278

-kdf

Robin Bowes
2007-09-06, 11:50
SumnerH wrote:

> It's a sign of problems, after fixing an incredibly dumb problem with
> CR/LF in the HTTP headers I'm now playing music successfully and the
> buffers are filling up.
>
> FWIW, even with the prototype written in Python it's not a problem to
> continuously stream mp3s with a (software) server that is under 3.5 MB
> resident and maxes out around 2% CPU usage on an old Pentium 4/1.4Ghz
> (unsurprising since the client's doing all the decoding work).

I'll be very interested in seeing your code when you release it. In
fact, I'm very interested now!!! :)

R.

SumnerH
2007-09-06, 12:29
There are some known issues with ogg playback:
http://bugs.slimdevices.com/show_bug.cgi?id=4723


Thanks for the link:
"Richard, the file that was included with this bug originally was created with a pre-release version of the Ogg Vorbis encoder."

That applies to my entire music collection, so I guess I'll be transcoding in the short-term--it'd be nice to support these files, but I'll probably wind up re-ripping a few hundred CDs I suspect since I can't imagine it's a very common (high-priority) case.

Thanks again for your time!

SumnerH
2007-09-06, 12:46
SumnerH wrote:

> It's a sign of problems, after fixing an incredibly dumb problem with
> CR/LF in the HTTP headers I'm now playing music successfully and the
> buffers are filling up.
>
> FWIW, even with the prototype written in Python it's not a problem to
> continuously stream mp3s with a (software) server that is under 3.5 MB
> resident and maxes out around 2% CPU usage on an old Pentium 4/1.4Ghz
> (unsurprising since the client's doing all the decoding work).

I'll be very interested in seeing your code when you release it. In
fact, I'm very interested now!!! :)

R.

It's hardly a real server right now--I can basically stream an arbitrary playlist out to the client and go forward/back through it with the remote, but there's no browsing of the library and no visual output at all yet, and certainly no Web interface.

At some point I'll probably toss the code out into public, but I want at least basic library browsing before then. And that's going to wait a bit--at the moment I'm just focused on getting things working well enough to have decent control over the tunes at a party this weekend and sync it with my music visualization setup.

funkstar
2007-09-07, 01:52
That applies to my entire music collection, so I guess I'll be transcoding in the short-term--it'd be nice to support these files, but I'll probably wind up re-ripping a few hundred CDs I suspect since I can't imagine it's a very common (high-priority) case.
As an aside, if you are going tore-rip, can i suggest doing it in FLAC? Then you can create any other lossy or lossless format from them without having to re-rip

Just an idea :)

SumnerH
2007-09-07, 13:30
As an aside, if you are going tore-rip, can i suggest doing it in FLAC? Then you can create any other lossy or lossless format from them without having to re-rip

Just an idea :)

Yeah, when I originally ripped in 2001 that wasn't an option (it's 35 GB as OGGs), but it's within the realm of possibility now. A few of my favorite albums are already FLACs so that's something.

funkstar
2007-09-08, 09:00
Yeah, when I originally ripped in 2001 that wasn't an option (it's 35 GB as OGGs), but it's within the realm of possibility now. A few of my favorite albums are already FLACs so that's something.
Good good :o)

SumnerH
2007-09-14, 13:08
It's hardly a real server right now--I can basically stream an arbitrary playlist out to the client and go forward/back through it with the remote, but there's no browsing of the library and no visual output at all yet, and certainly no Web interface.

Here's a drop of that code.

This is not meant to be used, just as a possibly helpful read for people implementing their own servers.

It's incredibly minimal (no display at all), it just plays the specified playlist and lets you skip forward/back with the remote. Connecting with multiple squeezeboxes will give odd results because of the global playlist (they'll both be able to play songs, but not sync'd and the playlist will behave oddly). Only mp3s are tested, though it _might_ work with ogg files. No security auditing has been done, so don't use it on a machine that's exposed to the internet or that has hostile local users.

I have played hours of music with it successfully. But expect it to break; it's more a look at the minimal wire protocol commands you need to play music than anything else. The code is horrifically ugly.

I expect that simply adding "=" to the start of the format strings would make this both 32- and 64-bit clean but I've not yet tested (e.g. change int_fromhl to use struct.unpack("=i", x) and so forth), so at the moment I'd guess this only works on 32-bit platforms.

I'm hopeful that it's endian-independent. It's only tested on Linux, but I believe that everything in there will work on Windows/Mac as well (but a few Windows networking gotchas wouldn't be surprising).

To run, you need python 2.5; save the attachment as "server.py" and create a playlist.py in the same directory with the lines:

playlist = [ "/home/first.mp3", "/home/second.mp3",
"/home/third.mp3" ]


(Or search the code for "Alternatively" and follow the directions)

Then run the attachment:

python2.5 server.py

and have your squeezebox connect to the machine. Obviously you can't have another program running on the required ports (e.g. the regular slimserver).

This code is licensed under the GNU Public License Version 2.0 (and that version _only_); see http://www.gnu.org/licenses/old-licenses/gpl-2.0.txt for more details.



At some point I'll probably toss the code out into public, but I want at least basic library browsing before then. And that's going to wait a bit--at the moment I'm just focused on getting things working well enough to have decent control over the tunes at a party this weekend and sync it with my music visualization setup.

I'm still planning on developing a bit of an interface and cleaning up the code significantly (and I've got some display stuff working on the wire but it's not plugged in to this code yet), but I figured I'd drop this out there in case anyone else is working on a server of their own and wants to look at the protocol stuff.

SumnerH
2007-09-20, 00:06
Here's a drop of that code.





I've got track display and basic playlist management working now, which pretty much makes it useable for my purposes. It's still < 4MB resident--is anyone actually looking at this or should I stop posting?

Robin Bowes
2007-09-20, 01:37
SumnerH wrote:
> SumnerH;227160 Wrote:
>> Here's a drop of that code.
>
> I've got track display and basic playlist management working now, which
> pretty much makes it useable for my purposes. It's still < 4MB
> resident--is anyone actually looking at this or should I stop posting?

I'm looking at it - I'm not all that interested in a python
implementation but I have this crazy idea of a server using apache to
handle connections and mysql to store state information and I find your
code useful to see how to implement from first principles.

Keep at it!

R.

jaysung
2007-09-20, 03:04
a Lightweight server has been requested more than once and especially for embeded devices running some sort of linux it may come in handy. So keep on developing. Don't understand python at all! ;)

SumnerH
2007-09-20, 11:21
SumnerH wrote:

> SumnerH;227160 Wrote:

>> Here's a drop of that code.

>

> I've got track display and basic playlist management working now, which

> pretty much makes it useable for my purposes. It's still < 4MB

> resident--is anyone actually looking at this or should I stop posting?



I'm looking at it - I'm not all that interested in a python

implementation but I have this crazy idea of a server using apache to

handle connections and mysql to store state information and I find your

code useful to see how to implement from first principles.





Cool. I'm probably going to do a C implementation of the whiole thing once I've got enough of the protocol figured out (it's easier to tinker in Python). The thing plugs into my own music database at home rather than using the static playlists, but that code's useless to the general public so I just did the static playlist hack for now. I'll try to do another code drop with display stuff and playlist management some time early next week.

revel
2007-09-26, 09:57
Let me preface by saying I am new to this forum and slim devices in general. But I have an idea that I think this code can be used for:

I use media monkey to organize and play my music. I would love not to have have two databases and applications to be able to play my music libary on my squeeze box (slimserver & media monkey). I am not that interested in being able to use the squeezebox interface or remote to search and play songs. I want the squeeze box to play what ever media monkey tells it to. I don't know if this is even the right track to be going down, but I want to make a plugin for MM, where you select something like, "Output to SqueezeBox" and it plays on the squeeze box. Something similar to the remote speakers/airtunes thing with the airport express and Itunes. From what I am reading, I think I will create A VB script (what MM uses for plugins) to create the playlist it is currently using in the format your py code uses, and then tell it to execute your code against the playlist is has just generated... I am a complte newb to this area, so I may be way in left feild, any guidace would be apreciated.

Thanks!

erland
2007-09-26, 10:02
Let me preface by saying I am new to this forum and slim devices in general. But I have an idea that I think this code can be used for:

I use media monkey to organize and play my music. I would love not to have have two databases and applications to be able to play my music libary on my squeeze box (slimserver & media monkey). I am not that interested in being able to use the squeezebox interface or remote to search and play songs. I want the squeeze box to play what ever media monkey tells it to. I don't know if this is even the right track to be going down, but I want to make a plugin for MM, where you select something like, "Output to SqueezeBox" and it plays on the squeeze box. Something similar to the remote speakers/airtunes thing with the airport express and Itunes. From what I am reading, I think I will create A VB script (what MM uses for plugins) to create the playlist it is currently using in the format your py code uses, and then tell it to execute your code against the playlist is has just generated... I am a complte newb to this area, so I may be way in left feild, any guidace would be apreciated.

Thanks!

I think you should look at the CLI interface for this, it will be a lot simpler than using SlimProto whick this thread is. The documentation for the CLI interface can be found in the SlimServer web interface under "Help/Technical Information/The SlimServer Command Line Interface".
My guess is that the "playlist play <url>" command should be pretty close to what you want.

SumnerH
2007-09-26, 10:04
Let me preface by saying I am new to this forum and slim devices in general. But I have an idea that I think this code can be used for:

I use media monkey to organize and play my music. I would love not to have have two databases and applications to be able to play my music libary on my squeeze box (slimserver & media monkey). I am not that interested in being able to use the squeezebox interface or remote to search and play songs. I want the squeeze box to play what ever media monkey tells it to. I don't know if this is even the right track to be going down, but I want to make a plugin for MM, where you select something like, "Output to SqueezeBox" and it plays on the squeeze box. Something similar to the remote speakers/airtunes thing with the airport express and Itunes. From what I am reading, I think I will create A VB script (what MM uses for plugins) to create the playlist it is currently using in the format your py code uses, and then tell it to execute your code against the playlist is has just generated... I am a complte newb to this area, so I may be way in left feild, any guidace would be apreciated.

Thanks!

This is entirely doable; there are a couple changes I could make to make it work more smoothly--basically, check the playlist periodically and (as a config option) either queue up the new, changed list after the current song ends, queue it up after the current list ends, or abort playback and start the new playlist.

It's kind of a hack, though, and I'm already integrating with my own music DB a lot more cleanly so maybe polishing up that API and publishing it would be more useful--it'd be slightly more work to connect to a local socket and make playlist change requests, but not a ton more. Maybe the hack would be nice for really rough-and-easy scripting solutions.

(And, of course, you can probably script the CLI to do this sort of thing with the regular slimserver)

revel
2007-09-26, 13:35
thanks for the tips, and so quickly!!

Ultimately, It wcould be nice not have the entire slimserver app installed for my use. However I couldnt get SumnerH's code to work properly.. I started messing with the CLI interface and found this telnet dll that I can send commands to via vbscript very easily. I will mess around some more to see what I can come up with.

Here's the simple code I am using so far to send commands:

Dim oSocket
Set oSocket = CreateObject("Socket.TCP")
oSocket.DoTelnetEmulation = True
oSocket.TelnetEmulation = "TTY"
oSocket.Host = "localhost:9090"
oSocket.Open
oSocket.SendLine "play"
oSocket.Close

The DLL from here:
http://www.dimac.net/Products/FreeProducts/w3Sockets/Reference/Refstart.htm

Thanks for the help!

SumnerH
2007-09-26, 14:22
thanks for the tips, and so quickly!!

Ultimately, It wcould be nice not have the entire slimserver app installed for my use. However I couldnt get SumnerH's code to work properly.

Do you have python 2.5? 2.4 _might_ work but isn't tested; earlier versions almost certainly won't as I use generators (new feature).

If so, what was the error (full stack trace if it threw an exception)? As I said, I've only run it on Linux/x86 so there might be some minor problems on other platforms (Windows) but I tried to write things pretty portably so hopefully they'll be easy to fix if I can see a stack trace (or get a description of what's failing if it's not printing a stack trace).

I'm planning a new, more featureful release soon (tomorrow probably) as well...

revel
2007-09-26, 14:34
Yeah I am using Python 2.5, but I am running Vista Ult. 32bit...

Here is the output when I run it:

C:\Test\A.mp3
HELO, sending vers 10 [['DeviceID', '\x06'], ['Revision', '\x02'], ['MAC', 'cl\x8d\xbf\x7f\xaf'], ['WLanChannelList', '\xc0\x00'], ['BytesRecieved', '']]
Sending ['v', 'e', 'r', 's', '6', '.', '5', '.', '4']
Sending ['s', 't', 'r', 'm', 'q', '0', 'm', '?', '?', '?', '?', '\xff', '\x00', '\x00', '0', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '#', '(', '\x00', '\x00', '\x00', '\x00']
Sending ['g', 'r', 'f', 'b', '\x00', '\x01']
Sending ['v', 'i', 's', 'u', '\x00', '\x00']
Sending ['s', 'e', 't', 'd', '\x00']
Sending ['s', 'e', 't', 'd', '\x04']
Sending ['a', 'u', 'd', 'e', '\x01', '\x01']
Sending ['a', 'u', 'd', 'g', '\x00', '\x00', '\x00', 'g', '\x00', '\x00', '\x00', 'g', '\x01', '\xff', '\x00', '\x00', 'r', '\x00', '\x00', '\x00', 'r', '\x00']
Sending ['s', 't', 'a', 't']
Traceback (most recent call last):
File "C:\test\server.py", line 431, in <module>
a.main()
File "C:\test\server.py", line 407, in main
rv = sock.do_read()
File "C:\test\server.py", line 193, in do_read
read_bytes = self.read(4096)
File "C:\test\server.py", line 143, in read
return self.socket.recv(len)
error: (10035, 'The socket operation could not complete without blocking')

SumnerH
2007-09-26, 15:10
Yeah I am using Python 2.5, but I am running Vista Ult. 32bit...

Here is the output when I run it:

C:\Test\A.mp3
HELO, sending vers 10 [['DeviceID', '\x06'], ['Revision', '\x02'], ['MAC', 'cl\x8d\xbf\x7f\xaf'], ['WLanChannelList', '\xc0\x00'], ['BytesRecieved', '']]
Sending ['v', 'e', 'r', 's', '6', '.', '5', '.', '4']
Sending ['s', 't', 'r', 'm', 'q', '0', 'm', '?', '?', '?', '?', '\xff', '\x00', '\x00', '0', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '#', '(', '\x00', '\x00', '\x00', '\x00']
Sending ['g', 'r', 'f', 'b', '\x00', '\x01']
Sending ['v', 'i', 's', 'u', '\x00', '\x00']
Sending ['s', 'e', 't', 'd', '\x00']
Sending ['s', 'e', 't', 'd', '\x04']
Sending ['a', 'u', 'd', 'e', '\x01', '\x01']
Sending ['a', 'u', 'd', 'g', '\x00', '\x00', '\x00', 'g', '\x00', '\x00', '\x00', 'g', '\x01', '\xff', '\x00', '\x00', 'r', '\x00', '\x00', '\x00', 'r', '\x00']
Sending ['s', 't', 'a', 't']
Traceback (most recent call last):
File "C:\test\server.py", line 431, in <module>
a.main()
File "C:\test\server.py", line 407, in main
rv = sock.do_read()
File "C:\test\server.py", line 193, in do_read
read_bytes = self.read(4096)
File "C:\test\server.py", line 143, in read
return self.socket.recv(len)
error: (10035, 'The socket operation could not complete without blocking')


Nice find, that's a platform-specific mistake on my part. I'll fix it for the release I do tomorrow.

Thanks for the feedback!

EDIT: In the interim, you can try adding "import errno" at the top of the file and replacing the line:
if x[0]==11:

with:
if x[0]==errno.EAGAIN:

(or failing that, 10035 instead of 11 for your platform)

revel
2007-09-26, 18:21
I'll give it a try, Thanks.

I'm going to keep up on this thread hopefully this evolves in to just what I need/want :)

In the meanttime I got it working with the CLI. You can check out what I did here if interested:
http://www.mediamonkey.com/forum/viewtopic.php?t=21124

SumnerH
2007-09-27, 10:11
Here's a new release. This should fix the exception that revel was getting on windows--I'd really appreciate any feedback from Windows users (stack traces) so I can get rid of any other problems and have it working there, as I don't have access to any Windows machines myself.

This should read id3v2 (but not old id3) tags from mp3 files and it'll read Ogg Vorbis tags. It will actually use the display and show scrolling Artist-Album and Title with a visualizer (latin1 only, no unicode support and only the built-in font), and supports several functions on the remote (power button, left/right to go forward/back a track, favorites button switches to SqueezeNetwork, pause/play, brightness). The mode switching (power, etc) is kind of finicky (e.g. power off then play might result in somewhat wonky results), and pause only pauses (play to unpause).

This will almost definitely _not_ work on 16 bit platforms (though it _might_ play music with broken font display). I tried to write it to work on big/little endian 32 and 64 bit machines, but I'd appreciate feedback (especially from big endian and/or 64-bit machines) as I haven't tested on those and there may be some gotchas.

It's slowly getting more featureful...still just under 4MB on my machine.

Untar it (it'll create a "musicserver" directory) and run "python2.5 server.py" to run.

Dan Sully
2007-09-27, 10:21
* SumnerH shaped the electrons to say...

>This should read id3v2 (but not old id3) tags from mp3 files and it'll
>read Ogg Vorbis tags. It will actually use the display and show
>scrolling Artist-Album and Title with a visualizer (latin1 only, no

You should use Mutagen for the tag reading. It's a comprehensive and well
written library:

http://www.sacredchao.net/quodlibet/wiki/Development/Mutagen

-D
--
<dsully> please describe web 2.0 to me in 2 sentences or less.
<jwb> you make all the content. they keep all the revenue.

SumnerH
2007-09-27, 10:43
* SumnerH shaped the electrons to say...

>This should read id3v2 (but not old id3) tags from mp3 files and it'll
>read Ogg Vorbis tags. It will actually use the display and show
>scrolling Artist-Album and Title with a visualizer (latin1 only, no

You should use Mutagen for the tag reading. It's a comprehensive and well
written library:

http://www.sacredchao.net/quodlibet/wiki/Development/Mutagen


Cool, thanks for the link!

It looks featureful, but just importing it and reading the tags from an mp3 and a .ogg file makes my server use more than 50% more memory (largely because it is so featureful and includes a lot more than what's needed just to read the 3-4 tags that a server needs). Given that low memory use is a goal, I'm not sure I want that by default.

I may make it an option in the future (run small if you just have well formed id3v2/ogg/flac tags, run bigger if you have outdated id3v1 tags or more unusual formats and aren't so concerned about memory use).

Dan Sully
2007-09-27, 10:50
* SumnerH shaped the electrons to say...

>It looks featureful, but just importing it and reading the tags from an
>mp3 and a .ogg file makes my server use more than 50% more memory
>(largely because it is so featureful and includes a lot more than
>what's needed just to read the 3-4 tags that a server needs). Given
>that low memory use is a goal, I'm not sure I want that by default.
>
>I may make it an option in the future (run small if you just have well
>formed id3v2/ogg/flac tags, run bigger if you have outdated id3v1 tags
>or more unusual formats and aren't so concerned about memory use).

Yeah, it depends on what your limits are. mutagen reads every tag format
known to (sane) people, and especially all the ID3v2 tags that most programs
don't. RVA2, etc.

-D
--
<dsully> please describe web 2.0 to me in 2 sentences or less.
<jwb> you make all the content. they keep all the revenue.

SumnerH
2007-09-27, 11:27
* SumnerH shaped the electrons to say...

>It looks featureful, but just importing it and reading the tags from an
>mp3 and a .ogg file makes my server use more than 50% more memory
>(largely because it is so featureful and includes a lot more than
>what's needed just to read the 3-4 tags that a server needs). Given
>that low memory use is a goal, I'm not sure I want that by default.
>
>I may make it an option in the future (run small if you just have well
>formed id3v2/ogg/flac tags, run bigger if you have outdated id3v1 tags
>or more unusual formats and aren't so concerned about memory use).

Yeah, it depends on what your limits are. mutagen reads every tag format
known to (sane) people, and especially all the ID3v2 tags that most programs
don't. RVA2, etc.



It's also nice not to have external dependencies, so the more I think about it the more I like keeping the minimal tag parser bundled and having an option to use Mutagen if it's installed. I also went around on using NumPy for the bitmap manipulations but decided it wasn't worth having a dependency when the bitwise-operations-on-integers approach performs reasonably and is trivial to implement.

SumnerH
2007-09-27, 12:30
Also for anyone out there doing something similar, I've added several entries to http://wiki.slimdevices.com/index.cgi?SlimProtoTCPProtocol (for the server->client protocol), including documentation for controlling brightness, drawing on the display, enabling/disabling visualizers, controlling the audio outputs (enable/disable/gain), and switching to other servers or SqueezeNetwork.

EDIT: I've now listed out briefly what all the commands used in 6.5.4 do, but for many of them (non-Squeezebox2 commands, firmware updates, and some other less common stuff) I didn't give a full detailed listing of what the arguments are. If you at least know the name of the command you're looking for, grep'ing the SlimServer/SqueezeCenter source for "sendFrame.*\<command\>" will get you to the details.

SumnerH
2007-10-15, 09:01
Apologies for the slow progress, but I've got another party coming up soon so there will be another release in a week or so. I've got basic playlist management, syncing with a local (to the server) software player, and a few other features done--the syncing will _probably_ work with multiple squeezeboxes but since I have only one that's not tested.

chp
2007-10-20, 08:04
Ok, time to do a little post here... I've been for quite a while been working on a streamserver on my own to service my custom music database. One of the things I didn't like was that I had to run slimserver side by side to support my SqueezeBox. Looking at this thread a while back I realised that I should probably add support for it in my own code instead. I completed the initial implementation last night and thought I should share it.

It's written in C++ and supports driving the display, controlling the visualizer and direct MP3 streaming. It has a HTTP controlling frontend and uses MySQL as a backend for servicing requests and all queries are generated in LUA so that you can tweak it to fit your own database. It also has optional support for transcoding music using ffmpeg and libmp3lame if you need that. I've developed it under linux, and it won't build in a Win32 environment right now, but I'll look into that in a little while. I'll also start working on a menu system since that's half the point with this little jewel.

This thread helped a lot giving me inspiration, and it's just fair that I give something back. :)

Do note that this is not a complete software suite. You do need some kind of frontend to go along with it and I'm currently not giving mine away (it's too ugly and I need to rewrite it).

EDIT:

I knew I missed something... In the 'SlimServer Backend' section I forgot to document how you select which squeezebox to control, this is the bit that's missing:

mac=<aa:bb:cc:dd:ee:ff>
- MAC address to select which SqueezeBox to control. You can find this
address by looking at debug output from this program or by pressing
LEFT on your remote while disconnected, selecting 'Current Settings'
and going down to the menu option 'MAC Address'.

Godskalk
2009-03-06, 09:09
I realize this thread is age-old, but it seems to be the only productive one concerning development of a lightweight slimserver/slimcenter.

User chp of the previous post: I hope you're still around! Have you been working any more on your code?

After a bit of work I got your streamer to compile and run on an NSLU2 NAS-device running uNSLUng. Unfortunately, I'm not quite sure what it is your application does.. so far it just displays a message that it is connected to zero clients. I suppose I'll figure it out more or less in time, right now I'm away from my Slug though, and I can't connect to it remotely as it seems to have crashed :(

Anyway, the reason for my interest is that I, as the other participants in this thread, am interested in development of a lightweight slimserver. You seem to have already implemented the streaming bit and the driving of the squeezebox display, which I assume is the dirty work. So, basically, it should be possible to add a menu system using the IR, and we're pretty much there, right?

So, my questions right now are:
chp, are you available for help and input? And, are there still other people around who are interested in development of a lightweight C++ slimserver?

Thanks, Godskalk.

peterw
2009-03-06, 10:06
So, my questions right now are:
chp, are you available for help and input? And, are there still other people around who are interested in development of a lightweight C++ slimserver

I have zero time for this, but I wish y'all were talking about a Java version rather than C++. I don't know how lightweight that would be (what does Java Micro require now? mustn't be *that* bad if cell phones run it...?), but I think it would be much easier to work on than C++. I only use C++ when I have to. And I'm less interested in a lightweight alternative server than a multi-threaded server. Using a single-threaded model certainly makes some things in SqueezeCenter and SqueezePlay easier, but I think SqueezeCenter could realize some usability and perceived performance gains if it moved to a multi-threaded model. And it seems clear that Logitech is not at all interested in working on multi-threaded code. (I'm not criticizing them on this -- they have perfectly valid fiscal and technical arguments for continuing to use the working single-threaded code.)

Dan Sully
2009-03-06, 10:27
* peterw shaped the electrons to say...

>I have zero time for this, but I wish y'all were talking about a Java
>version rather than C++. I don't know how lightweight that would be
>(what does Java Micro require now? mustn't be *that* bad if cell phones
>run it...?), but I think it would be much easier to work on than C++. I
>only use C++ when I have to. And I'm less interested in a lightweight
>alternative server than a multi-threaded server. Using a
>single-threaded model certainly makes some things in SqueezeCenter and
>SqueezePlay easier, but I think SqueezeCenter could realize some
>usability and perceived performance gains if it moved to a
>multi-threaded model. And it seems clear that Logitech is not at all
>interested in working on multi-threaded code. (I'm not criticizing them
>on this -- they have perfectly valid fiscal and technical arguments for
>continuing to use the working single-threaded code.)

Perl is particularly unsuited to the multi-threaded model. It's also hit and
miss as to which Linux distributions have threading support compiled in.

Though for C++/Java, it'd be worth it to look at an event based server as
well. Many of the fastest webservers are based on libevent or libev.

-D
--
<dsully> please describe web 2.0 to me in 2 sentences or less.
<jwb> you make all the content. they keep all the revenue.

andyg
2009-03-06, 10:42
On Mar 6, 2009, at 12:27 PM, Dan Sully wrote:

> * peterw shaped the electrons to say...
>
>> I have zero time for this, but I wish y'all were talking about a Java
>> version rather than C++. I don't know how lightweight that would be
>> (what does Java Micro require now? mustn't be *that* bad if cell
>> phones
>> run it...?), but I think it would be much easier to work on than C+
>> +. I
>> only use C++ when I have to. And I'm less interested in a lightweight
>> alternative server than a multi-threaded server. Using a
>> single-threaded model certainly makes some things in SqueezeCenter
>> and
>> SqueezePlay easier, but I think SqueezeCenter could realize some
>> usability and perceived performance gains if it moved to a
>> multi-threaded model. And it seems clear that Logitech is not at all
>> interested in working on multi-threaded code. (I'm not criticizing
>> them
>> on this -- they have perfectly valid fiscal and technical arguments
>> for
>> continuing to use the working single-threaded code.)
>
> Perl is particularly unsuited to the multi-threaded model. It's also
> hit and
> miss as to which Linux distributions have threading support compiled
> in.
>
> Though for C++/Java, it'd be worth it to look at an event based
> server as
> well. Many of the fastest webservers are based on libevent or libev.

The only issue with SC being single-threaded is that database calls
block the server. I think it is a mistake to try and re-implement SC
in another language. Let's focus on making the SC we have leaner and
meaner. A lot of work is already going on in this department for
7.4. Also note 7.4 will actually have some multi-threaded bits (pure
C stuff such as OSX file event monitoring and Linux/OSX stat
monitoring for remote filesystems).

One of my big plans is to replace all homegrown select loop, timers,
async DNS, async HTTP, and non-blocking socket code with AnyEvent::*
and EV. This will result in not only better performance but a lot of
code can be removed/cleaned up too. One downside is it will require
plugin authors to make changes to support it, as I don't want to keep
a compat Slim::Utils::Timers layer, for example. But I think it's
worth it.

peterw
2009-03-06, 11:21
The only issue with SC being single-threaded is that database calls
block the server. I think it is a mistake to try and re-implement SC
in another language.

I can't speak for anyone else, but I'm pretty sure that my plugins are NOT thread safe. They assume that when their code is executing, nothing else is going on in the server. For instance, PowerCenter uses external EXEs that require exclusive access to the serial port, but themselves have NO file/serial device locking. Serial port contention is no problem because there's only one SC thread, so I *can't* have concurrent system() calls.

If SC were multi-threaded, then I think a lot of us would need to take a hard look at our code & start adding in some semaphore/synchronized protections. I'd be very surprised (and impressed) if the SC7 core was really ready for multi-threaded use.


One of my big plans is to replace all homegrown select loop, timers,
async DNS, async HTTP, and non-blocking socket code with AnyEvent::*
and EV. This will result in not only better performance but a lot of
code can be removed/cleaned up too. One downside is it will require
plugin authors to make changes to support it, as I don't want to keep
a compat Slim::Utils::Timers layer, for example. But I think it's
worth it.

I don't quite follow you, but you & Dan have an understanding of Perl that's at least an order or two of magnitude greater than mine. :-)

andyg
2009-03-06, 11:28
On Mar 6, 2009, at 1:21 PM, peterw wrote:

>
> andyg;403767 Wrote:
>>
>> The only issue with SC being single-threaded is that database calls
>> block the server. I think it is a mistake to try and re-implement SC
>>
>> in another language.
>
> I can't speak for anyone else, but I'm pretty sure that my plugins are
> NOT thread safe. They assume that when their code is executing,
> nothing
> else is going on in the server. For instance, PowerCenter uses
> external
> EXEs that require exclusive access to the serial port, but themselves
> have NO file/serial device locking. Serial port contention is no
> problem because there's only one SC thread, so I *can't* have
> concurrent system() calls.
>
> If SC were multi-threaded, then I think a lot of us would need to take
> a hard look at our code & start adding in some semaphore/synchronized
> protections. I'd be very surprised (and impressed) if the SC7 core was
> really ready for multi-threaded use.

There are no plans to make SC multi-threaded, it would be easier
(although still very difficult) to add async DBI access via a forked
process (leaving out Windows users though). No plans to do this either.

Godskalk
2009-03-06, 12:05
Okay, this discussion immediately went completely out on a tangent. I was not at all talking about reimplementing today's slimserver/center, rather about making a tiny application that can replace the most basic functionality of the slimserver. This is basically meant to be an alternative to people running SS/SC on tiny NAS-type devices, where the perl SS tends to be way to CPU and memory intensive.

So, C/C++ is the language of choice, because the code is fast and there are compilers for every device. For now, considerations such as multithreading is way way into some hypothetical future for this application.

The first version, as I imagine it, would be as simple as possible: No database support, only browsing of music folders and playback. The most basic version should ideally not depend on any external libraries, so that it can be run on any device. The NSLU2 supports mysql and lua today, so that chp's code can run on the slug as it is, but stuff could easily be even more stripped down.

Edit: And btw, there certainly wouldn't be any web-interface in such an app, only the menu you'd be able to reach through the squeezebox.

peterw
2009-03-06, 12:50
Edit: And btw, there certainly wouldn't be any web-interface in such an app, only the menu you'd be able to reach through the squeezebox.

Sorry for derailing this a bit. But no web UI?? Even mvpmc and apps like Tomato and DD-WRT manage web UIs on low-power, low-memory devices!

:-)

Seriously, though, good luck.

andyg
2009-03-06, 13:11
On Mar 6, 2009, at 2:50 PM, peterw wrote:

>
> Godskalk;403792 Wrote:
>>
>> Edit: And btw, there certainly wouldn't be any web-interface in
>> such an
>> app, only the menu you'd be able to reach through the squeezebox.
>
> Sorry for derailing this a bit. But no web UI?? Even mvpmc and apps
> like Tomato and DD-WRT manage web UIs on low-power, low-memory
> devices!
>
>
> :-)
>
> Seriously, though, good luck.

Hehe and so it begins. I think I mentioned it before, creating an
alternate server would require a thick skin because you'll get endless
feature requests to implement every feature SC has.

erland
2009-03-06, 17:38
There are no plans to make SC multi-threaded, it would be easier
(although still very difficult) to add async DBI access via a forked
process (leaving out Windows users though). No plans to do this either.
I'm not sure if this is possible or not but sometimes it has crossed my mind that it would be good if the streaming part executed in a separate process/thread from the rest of the server.

It doesn't really matter if a user action through the web interface cause delays in the Controller interface but it's very irritating when any operation cause music playback disturbances.

The streaming part would of course need to send notifications to the user interface part but that's already implemented today for the Controller interface. When the user interface performs an action it would only need to communicate with the streaming part of the server when it wants to do something that affects the current playlist or maybe just when it affects the currently playing song.

Would it be possible to do some kind of modularization like this so different parts of the server could run in separate threads or processes ?
Or is the different parts of the code too tightly coupled today so it would be a very complex operation to do a separation like this ?

andyg
2009-03-06, 17:42
On Mar 6, 2009, at 7:38 PM, erland wrote:

>
> andyg;403779 Wrote:
>>
>> There are no plans to make SC multi-threaded, it would be easier
>> (although still very difficult) to add async DBI access via a forked
>> process (leaving out Windows users though). No plans to do this
>> either.
> I'm not sure if this is possible or not but sometimes it has crossed
> my
> mind that it would be good if the streaming part executed in a
> separate
> process/thread from the rest of the server.
>
> It doesn't really matter if a user action through the web interface
> cause delays in the Controller interface but it's very irritating when
> any operation cause music playback disturbances.
>
> The streaming part would of course need to send notifications to the
> user interface part but that's already implemented today for the
> Controller interface. When the user interface performs an action it
> would only need to communicate with the streaming part of the server
> when it wants to do something that affects the current playlist or
> maybe just when it affects the currently playing song.
>
> Would it be possible to do some kind of modularization like this so
> different parts of the server could run in separate threads or
> processes ?
> Or is the different parts of the code too tightly coupled today so it
> would be a very complex operation to do a separation like this ?

There used to be sort-of working support for streaming in a forked
process, but it was buggy and really only helped with slimp3/SB1 so it
wasn't worth the effort of finishing it. It also left out Windows
users, so wasn't very practical.

erland
2009-03-06, 17:46
I have zero time for this, but I wish y'all were talking about a Java version rather than C++. I don't know how lightweight that would be (what does Java Micro require now? mustn't be *that* bad if cell phones run it...?), but I think it would be much easier to work on than C++. I only use C++ when I have to.

You are not alone, but unfortunately my time is limited too.
However, even though I would prefer Java I'm not sure Java is the best choice for the streaming part of a real time application like SqueezeCenter, especially when we are talking about things like synchronized playback with multiple players. For other parts of the server, like the web interface and the control/browsing logic, a Java solution would be great. The question is just how much extra complexity a mixed language server would result in.

There is an early alpha version of a Java server available which a developer worked on two years ago, but I haven't seen anything regarding it after the initial posts:
http://forums.slimdevices.com/showthread.php?t=19843

erland
2009-03-06, 17:55
There used to be sort-of working support for streaming in a forked
process, but it was buggy and really only helped with slimp3/SB1 so it
wasn't worth the effort of finishing it. It also left out Windows
users, so wasn't very practical.

What about a streaming server in a separate process which implements cometd to notify clients and offered some simple JSON commands for modifying the current playlist ?

The web interface and browse menus could execute in a separate process which used the JSON commands offered by the streaming server to issue play/stop commands and modify the current playlist. The different user interfaces could probably run as separate processes which makes it easy to select which parts you like to run on slow hardware like a NAS box. If you don't want the web interface just don't run that user interface process.

Wouldn't separate processes also mean that it could work on all platforms ?

Do you think the communication overhead of a solution like this would be too much to make it work fast enough ? Or is the problem just that the current server code isn't modularized this way ?

andyg
2009-03-06, 18:15
On Mar 6, 2009, at 7:55 PM, erland wrote:

>
> andyg;403897 Wrote:
>>
>> There used to be sort-of working support for streaming in a forked
>> process, but it was buggy and really only helped with slimp3/SB1 so
>> it
>>
>> wasn't worth the effort of finishing it. It also left out Windows
>> users, so wasn't very practical.
>>
> What about a streaming server in a separate process which implements
> cometd to notify clients and offered some simple JSON commands for
> modifying the current playlist ?
>
> The web interface and browse menus could execute in a separate process
> which used the JSON commands offered by the streaming server to issue
> play/stop commands and modify the current playlist. The different user
> interfaces could probably run as separate processes which makes it
> easy
> to select which parts you like to run on slow hardware like a NAS box.
> If you don't want the web interface just don't run that user interface
> process.
>
> Wouldn't separate processes also mean that it could work on all
> platforms ?
>
> Do you think the communication overhead of a solution like this would
> be too much to make it work fast enough ? Or is the problem just that
> the current server code isn't modularized this way ?

Anything's possible, it's just software. :) But I'm not really
interested in going down this path. The amount of work required
doesn't justify the benefits IMO.

Godskalk
2009-03-07, 03:57
Sorry for derailing this a bit. But no web UI?? Even mvpmc and apps like Tomato and DD-WRT manage web UIs on low-power, low-memory devices!

:-)

Seriously, though, good luck.

Yeah, I agree it could be done. But the point here is mainly getting something that works. The fewer features, the better.



You are not alone, but unfortunately my time is
http://forums.slimdevices.com/showthread.php?t=19843

Hey, thanks! That might be quite useful. Does anyone know of other projects like this?

Godskalk
2009-03-07, 08:39
I tried to post here earlier, but it seems that post was lost in the matrix.


Sorry for derailing this a bit. But no web UI?? Even mvpmc and apps like Tomato and DD-WRT manage web UIs on low-power, low-memory devices!

:-)

Seriously, though, good luck.

I agree that it would be possible drive a web UI from pretty much any device, but that's not really the point. I just want something as simple as possible as long as it works - that is, the fewer features, the better. As I said, the main focus would be on browsing directories and playback through the squeezebox.




http://forums.slimdevices.com/showthread.php?t=19843

Thanks, that might be very useful! Does anyone know about other alternative SS/SC projects?

danyal711
2009-03-24, 23:27
I am very interested in this too! I would love to get an API going that allows you to pass a file location to play, change volume, seek, read tags, and basic playlisting. Ideally would like to do this in Python, especially since some work has been done in Python in the past.

pippin
2009-03-25, 02:08
What about a streaming server in a separate process which implements cometd to notify clients and offered some simple JSON commands for modifying the current playlist ?

The web interface and browse menus could execute in a separate process which used the JSON commands offered by the streaming server to issue play/stop commands and modify the current playlist. The different user interfaces could probably run as separate processes which makes it easy to select which parts you like to run on slow hardware like a NAS box. If you don't want the web interface just don't run that user interface process.


Only stumbled over this now.
But from my experience so far I would say this would leave you with something even less performant than it is now.
The cometd interface is made for a high latency environment and it's my experience that some things being done through that interface can require considerably more time than e.g. through the web interface.
This could change, of course, if you exchange the backend yet my impression is that protocol overhead itself adds to it: you have an asynchronous communication channel which needs to be serialized and that in parallel to the streaming process.


I am very interested in this too! I would love to get an API going that allows you to pass a file location to play, change volume, seek, read tags, and basic playlisting. Ideally would like to do this in Python, especially since some work has been done in Python in the past.

Sorry, but: Oh no! Please! Not another scripting language!

erland
2009-03-25, 13:26
Only stumbled over this now.
But from my experience so far I would say this would leave you with something even less performant than it is now.
The cometd interface is made for a high latency environment and it's my experience that some things being done through that interface can require considerably more time than e.g. through the web interface.
This could change, of course, if you exchange the backend yet my impression is that protocol overhead itself adds to it: you have an asynchronous communication channel which needs to be serialized and that in parallel to the streaming process.

My thought was that you would only need to interact with the streaming process if you like to change what's currently played, for example when you stop the music or start to play something.
In other cases like browsing your library everything would happen in a separate process which would make sure that the streaming isn't affected.

The idea was not to improve the performance of the user interface, the idea was to make sure that user interface operations didn't disturb the streaming as it does today if something happens during track changes.

jacobdp
2009-03-25, 14:14
Sorry, but: Oh no! Please! Not another scripting language!

If you ask ten people which language to implement a project in, you'll get eleven answers...

pippin
2009-03-26, 02:08
My thought was that you would only need to interact with the streaming process if you like to change what's currently played, for example when you stop the music or start to play something.
In other cases like browsing your library everything would happen in a separate process which would make sure that the streaming isn't affected.

The idea was not to improve the performance of the user interface, the idea was to make sure that user interface operations didn't disturb the streaming as it does today if something happens during track changes.

OK, that relaxes it a bit.
So where would the current playlist for a player be maintained?
In the UI part? That could still delay things if that one is busy at a track change.
Or in the streaming part? That would then cause quite a bit of communication, especially with Squeezeplay/SBC since these query the status quite frequently and these queries are quite verbose.
Of course you could find a compromise like only queuing up a few tracks to the streaming thread and maintaining the rest of the playlist in the UI thread but that would be a quite dedicated and different communication than what happens today over cometd/JSON/RPC and I don't see why to use that rather verbose and overhead-loaden protocol then.
Same thing for all player states: Managed by whom?


If you ask ten people which language to implement a project in, you'll get eleven answers...

At least!

danyal711
2009-03-26, 21:54
Separating those 2 pieces sound good, though personally I am most interested in improving the user interface. If someone works on the streaming piece and creates and API I can hook into to do song change, volume, seek, playlist change, etc... then I can crank on the UI.

erland
2009-03-27, 12:47
OK, that relaxes it a bit.
So where would the current playlist for a player be maintained?
In the UI part? That could still delay things if that one is busy at a track change.
Or in the streaming part? That would then cause quite a bit of communication, especially with Squeezeplay/SBC since these query the status quite frequently and these queries are quite verbose.
Of course you could find a compromise like only queuing up a few tracks to the streaming thread and maintaining the rest of the playlist in the UI thread but that would be a quite dedicated and different communication than what happens today over cometd/JSON/RPC and I don't see why to use that rather verbose and overhead-loaden protocol then.
Same thing for all player states: Managed by whom?

It should be enough if the streaming part keeps track of the current and the next track. I'm not suggesting that the rest of the server is moved to Squeezeplay/SBC, I was thinking that there would be a UI server that interacted with SBC in the same way as SC does today. The UI server would interact with the streaming server when it needs to get the currently playing track.

You are completely correct that the tricky party to decide is where to handle things like current playlist and player states. If the streaming server handles all logic around these it will need a lot of functionality and we are getting close to the current solution. If the streaming server doesn't handle this kind of information, you will always need something else running besides the streaming server.

I'm not completely convinced that all this is a good idea, but the current solution where browsing your library could cause music disturbances doesn't feel good. Of course, several processes might just create another type of complexity so I'm not totally convinced that it will improve the situation.

However, the main advantage in the end with dividing the server into different modules might be that you can actually pick which modules you need on a low end server.

danyal711
2009-03-31, 10:48
I tried getting the python server written by SumnerH working... no luck though. Probably because it was still written in the days of SqueezeCenter 6.x.x. Anyone else able to get it working?

Thijs
2009-05-03, 07:44
Hi,

It seems that this thread is a bit quiet, let's change that:

At

code.google.com/p/squeezed

you'll find (yet) another alternative server. It's still very simple,
and probably has it share of bugs, but it also does:

- Written in C++, the application is only ~200kb
- 1 external dependency: taglib
- Playlist control via the remote
- (very) basic searching on artist or album
- Supports mp3 and flac files, using taglib
- works under win32, linux and openwrt (for routers)

cajus
2012-11-10, 07:04
Hi,

It seems that this thread is a bit quiet, let's change that:

At

code.google.com/p/squeezed

you'll find (yet) another alternative server. It's still very simple,
and probably has it share of bugs, but it also does:

- Written in C++, the application is only ~200kb
- 1 external dependency: taglib
- Playlist control via the remote
- (very) basic searching on artist or album
- Supports mp3 and flac files, using taglib
- works under win32, linux and openwrt (for routers)

After Logitech does not seem to work on LMS any more, a simple alternative would be great.
I just need something to stream my flac files to my three SB3 and three Boom.
The ability to hear internet radio streams on my devices would also be fine.
I don't use all the Plug-Ins.

squeezed seems to be able to do this, but needs to be updated a little.
On it's google home page there is already a patch, that allows compiling the code under Linux.
But the Web interface did not work very well (on firefox), as the pages are transmitted without a valid header.
This causes firefox to show the code of the page and not the page itself.

Has anybody tried this solution already?