radish;256818 Wrote: > 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! -- moschous ------------------------------------------------------------------------ moschous's Profile: http://forums.slimdevices.com/member.php?userid=14892 View this thread: http://forums.slimdevices.com/showthread.php?t=41937 _______________________________________________ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
