Bugzilla – Bug 4004
Optional stream Vorbis without transcoding on ReadyNAS NV
Last modified: 2009-09-08 09:25:55 UTC
There is a bug that is really easy to fix in the SlimServer. I recently bought the Infrant ReadyNAS NV and two squeezeboxes. Then I found out the Ready NAS does not have the processing muscle to transcode OGG Vorbis to MP3. Since most of my collection is in OGG Voribs format this causes a major issue when I want to stream from my Ready NAS. There is an EXTREMLY simple fix to this problem. Change the stream address from http://ip.address/stream.mp3 to http://ip.address/stream.m3u This way the CLIENT side does the decoding of the file not the Server side. This saves a ton of processing power and makes it possible to stream ANYTHING as long as the client has the right codec. No Transcoding required. This is how my Andromeda (Turnstyle) music server works.
Please do not pre-set targets. Resetting severity as this is a change to the design, not something that fails to comply with the current design. loosely related to bug 131, which includes a patch based on a very old server version to stream other formats.
Dean I thought you might be interested in seeing this idea.
I'm not sure that .m3u is the right format here, don't you want: http://ip.address/stream.ogg to do an ogg stream instead?
This is most definitly *NOT* what I want... because then I would have to change the stream URL every time I choose a different file format. ===== BAD IDEA ======= http://ip.address/stream.ogg ====================== ===== GOOD IDEA ====== http://ip.address/stream.m3u ====================== ======Alternative but much less compatible =========== http://ip.address/stream.pls ================================================= By using the M3U or PLS it doesn't matter what the source file format is. As long as the codec is available on the client side. You can try this out at http://www.turnstyle.com/andromeda/ What the M3U format does is send a playlist. This can be mixed MP3, OGG, FLAC, WMV, whatever... it just sends a list of links to the files. The player does all the decoding. This method of streaming works in Quintessential Player, Windows Media Player, RealPlayer, Quicktime. Here are some instructions on how to implement it. http://www.samisite.com/test-csb2nf/audio.htm http://www.spartanicus.utvinternet.ie/streaming.htm
Subject: Re: Optional stream Vorbis without transcoding on ReadyNAS NV Ah, thanks for the clarification. To be clear it's not a BAD IDEA to create an Ogg stream, it's just that nobody's asked for it yet. What you want is not a stream, but a playlist for streaming individual files. The good news is that we're nearly already doing this. http://ip.address/status.m3u is a playlist like you describe, but it uses the path to the files on the local machine rather than http URLs. Generating that M3U response is easy. But given the way slimserver works, the problem's a lot harder. The reason stream.mp3 works is that the user connects to that stream then SlimServer creates a virtual "player" which gets a stream of silence. Then the user can create a playlist and queue it up for the player and the silence gets replaced by song data. Now, if we use the stream.m3u format instead, the user would connect and the server would create a virtual player with no songs and return an empty playlist, which would end immediately. Then the user would have to visit the web interface, create a playlist for the new virtual player, then would have to reconnect to get the new M3U file. Then that playlist would play and the user would not be able to modify or update the playlist on the fly, requiring the user to manually stop and restart playback to make any changes or add any songs, since the M3U file would already be downloaded. Are these limitations still acceptable to you? Or would it be better to use an ogg stream to get dynamic playback since your music is in ogg format?
I guess I never looked at the issue this way before. I didn't realize that a m3u would stop each time. An OGG stream would be a nice to have, if it's easy enough to implement.
*** This bug has been marked as a duplicate of bug 3217 ***