PDA

View Full Version : Squeezebox options to stream



moschous
2008-01-08, 10:39
Hi list,

I just bought a Squeezebox and it looks really nice! :-)

i am very new on the Squeezebox Community and i would like to ask you some basic things.

Which are the available options for delivering/streaming audio files (on-demand) on Squeezebox?

It is obvious that there are two options:

a. There is a software called slimserver which also includes some predefined internet stations (shoutcasts, url to playlists, etc) that Squeezebox is able to connect to.

b. There is the SqueezeNetwork where users are able to buy content, listen famous radio stations, etc...


Now, there are two questions:

is there any other option that enable a user to set-up a server/mp3 library (any other alternative software server) to deliver mp3's on demand?
(e.g. can i force the squeezebox to connect directly to a url-playlist? and not through the slimserver software?)

can i use darwin streaming server playlists for mp3 streaming?

if not, does the slimserver have tested on heavy traffic? how many squeezeboxes are able to connect to concurrently?

I guess that the restrictions will come first from the bandwidth-side.

is there any way to setup load-balancing while delivering mp3's on big number of squeezeboxes?

Sorry for asking so many things!

Thank you very much.

radish
2008-01-08, 11:15
a. There is a software called slimserver which also includes some predefined internet stations (shoutcasts, url to playlists, etc) that Squeezebox is able to connect to.

Yes, but it also serves as a media server for local files amongst other things.



b. There is the SqueezeNetwork where users are able to buy content, listen famous radio stations, etc...

I don't believe there's any way to specifically buy content through SN, although you can use various pay services such as Rhapsody and Pandora. All of these options are also available with a local server (or will be when 7.0 is released).



is there any other option that enable a user to set-up a server/mp3 library (any other alternative software server) to deliver mp3's on demand?
(e.g. can i force the squeezebox to connect directly to a url-playlist? and not through the slimserver software?)

Slimserver is designed for this, it's best to use it. You could setup a stream using shoutcast and then connect to that via your slimserver but I don't see much point in that.



can i use darwin streaming server playlists for mp3 streaming?

I don't know what darwin streaming server is, but if it uses regular .pls playlists slimserver should read them fine.



if not, does the slimserver have tested on heavy traffic? how many squeezeboxes are able to connect to concurrently?

How long is a piece of string? It depends on the server hardware, bandwidth, etc. Using a decent spec machine and wired ethernet I wouldn't expect any problems with up to say 10 players, probably more.



I guess that the restrictions will come first from the bandwidth-side.

Probably.



is there any way to setup load-balancing while delivering mp3's on big number of squeezeboxes?

You can run multiple servers on the same network and have sets of players connecting to each - it's a manual setup though. How many is a "big number"?

SuperQ
2008-01-08, 13:13
I guess that the restrictions will come first from the bandwidth-side.

is there any way to setup load-balancing while delivering mp3's on big number of squeezeboxes?

That depends on a lot of factors.

Wireless: You have 10-15 mbps of bandwidth (as long as your server is on wired ethernet) with 11g networking. If you stream CD quality FLAC files you will need 1mbps. If you stream mp3, you will need .25mbps.. That would give you 10-15 squeezeboxes for FLAC (lossless) or 40-60 squeezeboxes for mp3.

Wired ethernet: If you have gige on the slimserver, and all squeezeboxes are wired, you should be able to get 300mbps out of the server, that would mean you could have 300 squeezeboxes on one server. Streaming native content isn't really CPU intensive, but I don't know if anyone's tried doing 300 at one time. :)

moschous
2008-01-09, 05:56
Hi,

first of all i would like to thank you for your response on this thread. Besides on this, i think that this is a good
opportunity to start a thread related to performance / scalability / reliability / stability of slim server while
talking for providing a service (mp3 library service or playlists/ internet radio service) where many squeezeboxes
will be able to connect to.

As far as i understood (please correct if i am doing wrong) delivering content on squezeeboxes is only possible trough
the slim server. The squeezebox can connect only to a slim server and get local mp3 files, other playlists
(where content may located on remote servers), or get live internet radio stations where are relayed by the slim server.
So, even if the real content is not hosted on the slim server, it is delivered/realyed through the slim server.

If this is true then this kind of service (which is based on slim server) doesnt scale (it only scales when you drive different
squeezeboxes to connect to different instances of slim servers - but this "manually" solution is not viable).

Please correct me if i am doing wrong.

So, is it possible to provide a service where the squeezebox will connect to on a different software server?
(e.g. QuickTime Streaming server, windows media services, etc.. ? ) does anybody has any experience on this?

jeffmeh
2008-01-09, 06:05
Hi,

first of all i would like to thank you for your response on this thread. Besides on this, i think that this is a good
opportunity to start a thread related to performance / scalability / reliability / stability of slim server while
talking for providing a service (mp3 library service or playlists/ internet radio service) where many squeezeboxes
will be able to connect to.

As far as i understood (please correct if i am doing wrong) delivering content on squezeeboxes is only possible trough
the slim server. The squeezebox can connect only to a slim server and get local mp3 files, other playlists
(where content may located on remote servers), or get live internet radio stations where are relayed by the slim server.
So, even if the real content is not hosted on the slim server, it is delivered/realyed through the slim server.

If this is true then this kind of service (which is based on slim server) doesnt scale (it only scales when you drive different
squeezeboxes to connect to different instances of slim servers - but this "manually" solution is not viable).

Please correct me if i am doing wrong.

So, is it possible to provide a service where the squeezebox will connect to on a different software server?
(e.g. QuickTime Streaming server, windows media services, etc.. ? ) does anybody has any experience on this?

Interesting question. I would think that the gist of it would be, "On one server computer, how much CPU and memory can you throw at it before the SlimServer software cannot make any more use of the incremental horsepower?" If the constraint is really the hardware rather than the software, then one could scale as much as current hardware capabilities allow under a given budget. Of course, multiple networks might be required to provide the necessary bandwidth.

Perhaps one of the developers could chime in on this.

bpa
2008-01-09, 06:31
if the internet radio can deliver native formats such as WMA and MP3 then the SB communicates directly with the source and Slimserver is not used except for screen text. Similarly for podcasts.

This is the basis for Squeezenetwork (which is essentially a set of public slimservers with no local files) which can handle many SB users. Logitech may be able to say current peak usage of Squeezenetwork.

moschous
2008-01-09, 09:12
if the internet radio can deliver native formats such as WMA and MP3 then the SB communicates directly with the source and Slimserver is not used except for screen text. Similarly for podcasts.

This is the basis for Squeezenetwork (which is essentially a set of public slimservers with no local files) which can handle many SB users. Logitech may be able to say current peak usage of Squeezenetwork.

I guess that this is also applies for a plyalist where the files (inside the list) are hosted on a remote web server, right?

BTW, has anybody was ever able to connect SB to any other streaming platform ?

andyg
2008-01-09, 09:24
The SC code is very scalable, SqueezeNetwork serves many thousands of concurrent players.

bpa
2008-01-09, 09:25
BTW, has anybody was ever able to connect SB to any other streaming platform ?

The SB is a thin client - which in this case it has a basic functionality to fetch audio but all the display control has to come from a server. SB has a proprietary control protocol - called slimproto.

The main server is Slimserver/SqueezeCenter. Servers such as Itunes or WMP use different protocol standard (e.g. DAAP and uPNP) and so to use these you would have to write an interface applications.

Over the years a few users felt that Slimserver/SqueezeCenter has got too big and have implemented lightweight less functional alternative servers which implement slimproto. Search the firum and you will find them.

moschous
2008-01-10, 08:31
The SB is a thin client - which in this case it has a basic functionality to fetch audio but all the display control has to come from a server. SB has a proprietary control protocol - called slimproto.

The main server is Slimserver/SqueezeCenter. Servers such as Itunes or WMP use different protocol standard (e.g. DAAP and uPNP) and so to use these you would have to write an interface applications.

Over the years a few users felt that Slimserver/SqueezeCenter has got too big and have implemented lightweight less functional alternative servers which implement slimproto. Search the firum and you will find them.

Dear bpa,

thank you very much for your answer. I need to say that the solution that better suits me is to develop a new lightweight server-application (like you are noting above) which handle the SB player (e.g. force it to connect to playlists, radio stations, etc..)

In that case my lightweight server will not transfer/relay any real data (meaning local mp3 files, playlists) but it will handle only the basic communication though the slimproto protocol. (e.g. myserver --(get and start playing a specific playlist)--> SB )

Now, the question that rises to me is:

Which are the available options that SB has in order to get the real data (mp3 files on demand which are located on remote servers or mp3's through playlists which are also located on remote servers) ?

Let me to make it more clear.

Lets say that myserver or even the slimserver force the SB to get a playlist and start playing it. One option is that the playlist will look like :

e.g: Home / SHOUTcast Internet Radio / Top 500 / 977 The Hitz Channel :
http://www.shoutcast.com/sbin/tunein-station.pls?id=1025&filename=playlist.pls

#file 1
http://<remote_web_server>/mp3s/1.mp3
#file2
http://<remote_web_server>/mp3s/2.mp3

That option utilizes a web server for delivering the real mp3's. The SB after the slim-negotiation with my lightweight server or even the slimserver connects to the remote web server (doing http get) in order to get the real mp3 files.

I need to note here that this option sucks :-) The SB rebuffers all the time. Lets say that plays 10-20" and then rebuffers again, then again, again...

The question i have is: what are the available options for the SB to get the real data for audio-on-demand or via playlists (after the negotiation via slimproto).

Thank you very much.

andyg
2008-01-10, 08:34
Heh everyone wants to write their own server... have fun, it's a lot of work!

radish
2008-01-10, 08:44
moschous

I think you'd get better answers faster if you described the actual problem you're trying to solve rather than talking about possible solutions. What's your server hardware? How many players? What's the network topology? What file types? Usage scenarios? It may be that there's already a good solution, or it may be that we can suggest one.

moschous
2008-01-10, 10:49
moschous

I think you'd get better answers faster if you described the actual problem you're trying to solve rather than talking about possible solutions. What's your server hardware? How many players? What's the network topology? What file types? Usage scenarios? It may be that there's already a good solution, or it may be that we can suggest one.


ok, let me describe you what do my friends and i want to do and what are the problems we need to solve.

Our aim is to develop a music-service where slimdevices will be able to connect to. We intend to release the service in Greece and provide Greek music on clients (slim devices).

The service will come up with a web-portal where users will be able to buy content, create their own profiles, create playlists, share playlists, chat for music, etc..

The service will offer both mp3 files on-demand and playlists (targeting multiple mp3 files at once). We dont intend to broadcast any live streaming station, but we will offer lets say virtual radio stations (e.g. playlists targeting many different categories rok, R&B, etc..).

Now, which are the problems i can see:

1. We need somehow to integrate our web application (where users browse on a big mp3-library, buy content, create private or public playlists, etc) with the slim server or any slimproto-based server we eventually use.
We need to have different users, to access different playlists and different audio libraries.

What do i understand is that we need a custom slimproto-based
to communicate with our client's squeezeboxes.
For example, lets see a possible usage-scenario: The owner of a specific SB will browse on web portal, buy content and create its own playlist. We need somehow to force its own squeeze box to start playing (tune in) on that specific playlist. We need to do that through our web portal and not through slim server's web interface.

2. We need somehow to identify the different devices everytime they connect to the service. Is that possible? I saw that while SB connects to Squeezenetwork it sends a pin code. Is that available on slim server?

3. And the most difficult problem is the issue "scalability".

But before going on this i want to make sth clear. There are two different steps/levels while SB gets music.

a. The first one is the communication level (slimproto protocol) where a slimproto - based server tells SB what to play, where to connect, etc

b. The second step/level is the delivery of real data (e.g. mp3 files). In case where we deliver local files/playlists on slim server the slim server serves those files. In case where we choose something that is remotely hosted then the slim server just notify the SB(via slimproto) which in turns connects to the remote area to get the content.

is that right?

So, even if we are going to use the slimserver for the front part (the slimproto-communication) we need to find a way to scale the second level/step which is the delivery of audio files. Of course the second level will be the most heavy in terms of traffic, etc... (think about for more than 500 SB's)

So, based on the matters i noted above what is the best choice i have?


Thank you very much for your help!

erland
2008-01-10, 12:09
If thinking about writing your own server, this thread may be of interest, it contains two alternative simple servers:
http://forums.slimdevices.com/showthread.php?t=38173

moschous
2008-01-11, 02:31
If thinking about writing your own server, this thread may be of interest, it contains two alternative simple servers:
http://forums.slimdevices.com/showthread.php?t=38173

erland thank you very much,

Of course, i am not thinking on developing a new server from scratch. It is obvious that there is too much work to do such a thing.

Does anybody know any sample server written in JAVA ? I have found one which is called slimpy. Any experience on this?

Also,

i need you to approve that everything i am writing above is right. I mean for the two steps/levels (a. slimproto communication and b. delivery of real data)

And finally, what are the available options to deliver remotely hosted mp3 files (on-demand or via playlists) on slim devices?
The one option is of course by utilizing a web server to deliver the mp3 files on slim devices.
Any other option?

Thank you very much.

bpa
2008-01-11, 02:53
Minimal s/w development approach - you could consider the following:

1. Take the current SqueezeCenter sourceand disable all user menu options you don't want to provide to your users. I'm sure some advice will be given how to scale to 500 users.

2. If MP3 files are on the same server as SqueezeCenter there is no need for any more server s/w.

3. If MP3 files are on remote servers then you just use standard network file shares or could try UPNP server which comes bundled with many NAS or Windows. I haven't tested UPNP server with Suqeezecenter but I believe it works.

4. Broadcast type servers - try something like icecast.

moschous
2008-01-12, 07:55
Minimal s/w development approach - you could consider the following:

1. Take the current SqueezeCenter sourceand disable all user menu options you don't want to provide to your users. I'm sure some advice will be given how to scale to 500 users.

2. If MP3 files are on the same server as SqueezeCenter there is no need for any more server s/w.

3. If MP3 files are on remote servers then you just use standard network file shares or could try UPNP server which comes bundled with many NAS or Windows. I haven't tested UPNP server with Suqeezecenter but I believe it works.


Dear bpa,

thank you for your answer. I want to make some notes on your recommendations.

If i use a single squeezeCenter (meaning a single slim server on a single hardware server even with shared hard drives, huge storage, etc..) like you are recommending above (on 1. 2. 3. ) then my service will be restricted by the Ethernet bandwith that my server connects to (usually 100Mbit, which means something like 50-100 concurrent SB clients)

I am afraid that the solution you recommend doesnt scale.

for me the best is to seperate the communication level and the delivery level.

Think about the architecture below:

[Set of Storage Hard drives (shared)]
|||||
|||||
|||||
12345 .......

where (1), (2), (3), (4), (5), ... will be different hardware servers doing the delivery of mp3's (maybe icecast servers, web servers, slim servers or any other recommendation ??)

The architecture will also include (for the communication level) a slimproto-based server in the front which will make something like load-balancing.

I dont know what software should i use for both levels.



4. Broadcast type servers - try something like icecast.
To be honest, i have



Here i need to make a comment. I think that the SB doesnt work properly (meaning playback) with any server different than slimserver (meaning for the delivery part).

For example, up to now i have tested SB by using icecast with ices/ices2 (deliver a playlist including mp3 files or ogg files for the ices2) and a simple web server to deliver a playlist (including some mp3 files).

For both cases the quality playback was very poor, because the SB was doing rebuffering all the time. Maybe there are other issues i need to take into account but i think that delivering mp3 files on SB by using other software than Slim server is a mess.

Any comment on this?

bpa
2008-01-12, 08:13
Just some initial comments.

1. I didn't say only one hardware server. I can't see any reason why you can't have multiple servers - you just need some load sharing to manage the incoming conections. AFAICT this is the basis for Squeezenetwork which handles 100's of concurrent users in more than one datacentre.

2. If you are using native formats - then load on slimserver is low as all it has to do is update screen displays and handle remote keypresses - it does not stream the audio data if you have server broadcasting.

With respect to a broadcast server - that needs research but as Slimserver works with many internet sites delivering streamed, on demand and podcast audio - I think there are many working solutions - it's a case of identifying the underlying s/w.

For a sale of 500 SBs - I think you should talk to Logitech direct ( JimC possibly) and see if they can offer advice - perhaps even a hookup with MP3Tunes.