tbessie;190236 Wrote:
Untrue - as long as **SqueezeNetwork exists**. I don't want to have to
depend on it existing, or being reachable. Some small, basic, generic
built-in functionality would be a Good Thing(tm). :-)
- Tim
I digress. I like the ability to log in to Squeezenetwork knowing
Michael Herger;190059 Wrote:
flash for some URLs and settings and the ability to play them without
relying on a separate server.
That in itself would be enough to satisfy me.
What's wrong with using SqueezeNetwork? You'll need internet access to
listen to radio streams. And as
wcattey wrote:
I've been doing client / server computing practically since it was
invented. (Anybody remember MIT's Project Athena?) One of the design
principles that I keep seeing people failing to learn year after year,
generation after generation is this:
Impressive credentials!
without the help of SlimServer. I mean, how much intelligence is
required to read a stream from a URL? It would mean, of course, that
there would be two modes of operation, one depending on SlimServer, the
other autonomous, and the autonomous mode would be more limited in what
it could do, but
flash for some URLs and settings and the ability to play them without
relying on a separate server.
That in itself would be enough to satisfy me.
What's wrong with using SqueezeNetwork? You'll need internet access to
listen to radio streams. And as long as you can access the internet, you
I've been doing client / server computing practically since it was
invented. (Anybody remember MIT's Project Athena?) One of the design
principles that I keep seeing people failing to learn year after year,
generation after generation is this:
The end nodes ALWAYS get smarter. Make sure your
Both solutions lack a crucial feature: multi-device synchronized
playback.
You can synchronize Squeezeboxen. I don't know about SB and Roku though.
Because the Slim Devices system, for all its openness and
featurefulness, is FRAGILE! It breaks down MUCH more often than my
Roku.
Hmm...
You're right to point out that Slim Server has a synchronization
feature.
Search is not working in the forums right now, so I can't point to the
thread I participated in where the extreme shortcomings of the feature
were reviewed. Summary: Synchronization works by putting every device
in Pause
wcattey;189932 Wrote:
basic problem manifestations like:
waking up Slimserver...
Blank screen
would be able to be traced quickly and easily, rather than to live on
as Is it your wireless hub? Is it how much memory your Slimserver
host has?.
How would you get any information beyond
I edited out my description of the problem because I didn't want to
clutter up the thread with it. But your info on how the WOL is a
really hard thing to debug is helpful.
--
wcattey
wcattey's Profile:
Nice to see you on the forum, William. Hopefully you do have some time
for developing patches/troubleshooting/new features - I'm sure everyone
would appreciate the contributions of someone from MIT with the sort of
experience you have! :-)
wcattey;189906 Wrote:
The end nodes ALWAYS get
On the subject of syncronisation. Surely to achieve this would require a
multicast network than relying on pausing and unpausing at the same
time?
--
Paul_B
Paul
~
Slimserver 6.5.1 on EPIA VIA EN15000 Mini-ITX running Windows 2003 R2.
Remote
Paul_B;189969 Wrote:
On the subject of syncronisation. Surely to achieve this would require a
multicast network than relying on pausing and unpausing at the same
time?
For the time syncs? Probably, though I could envision other problems
with it (latency with wireless, for example: since
I think Wcattey is correct in pointing out that increasing the
intelligence in SB is a desirable path forward. That is not to say it
should abandon it's roots but technology and competition march on. At
the end it is as much of a cost decision as a design philosophy. The
current SS capability
Pellicle wrote:
I think Wcattey is correct in pointing out that increasing the
intelligence in SB is a desirable path forward.
For you, you may say that. For me, no way.
I want a slim device.
I want one smart server and bunches of cheap devices.
I'd be happier if they were cheaper still.
Going down Multicast route I believe meane ditching wireless as
inadequate. To achieve quality streaming means, in my eyes, hard-wiring
ethernet or ethernet over power cables.
--
Paul_B
Paul
~
Slimserver 6.5.1 on EPIA VIA EN15000 Mini-ITX running
The home server just becomes a non issue.
It would be good if SB4 allowed you to plug-in an iPod and the SB
firmware let you navigate it's music and take an analog signal from the
iPod's docking connector.
--
amcluesent
It would be good if SB4 allowed you to plug-in an iPod and the SB
firmware let you navigate it's music and take an analog signal from the
iPod's docking connector.
Why would you need an MP3 player to play the output of another MP3 player?
There are hundreds of different iPod docking stations
Personally I almost never access my own music collection now that
Rhapsody is available. The home server just becomes a non issue.
Great if your American - otherwise useless and very frustrating to hear
about.
Hopefuly your tie up with LogiTech will mean you can get Rhapsody like
deals in
If Rhapsody was available in the UK my order for a SB or a Transporter
would be in right now.
Terry
--
valeite
valeite's Profile: http://forums.slimdevices.com/member.php?userid=10755
View this thread:
Agreed - Rhapsody sounds like a wonderful service, I would definitely be
subscribed, however little 'ol New Zealand ain't likely to be included
for some time to come...or is it?
--
SumnerBoy
SumnerBoy's Profile:
Pat Farrell;188703 Wrote:
Laz wrote:[color=blue]
That is way overkill. I ran for years on a P3-500 with 386MB, and
currently run on an AMD 2400+ (about 1.5 gHz) with a gig of ram, Wifi
G.
Since ram is nearly free, I don't see any reason to not put in lots,
but
as a minimum, I think
The problem with NAS devices is they just aren't. Conceptually the NAS
boxes such as QNAP were originally specced for serving files to a
network. But more and more has been added to them in the form of bit
torrent, web server, Slimserver, etc. They are no longer true NAS but a
central server. As
sander wrote:
I work in IT so I have to apologize for poor design decisions at
multiple levels everyday, I don't need that at home as well. :)
Jonathan?
- Marc
___
discuss mailing list
discuss@lists.slimdevices.com
sander;188604 Wrote:
I work in IT so I have to apologize for poor design decisions at
multiple levels everyday, I don't need that at home as well. :)
I'm not so sure it's a poor design choice. Since most of its power is
housed in the server, the Squeezebox is the most customizeable,
Pat Farrell;188703 Wrote:
Since ram is nearly free, I don't see any reason to not put in lots...
Please send me your extra free RAM. :-)
--
jonheal
Jon Heal says:
Have a nice day!
http://www.theheals.org/
~~~
SB3 (wired - 6.3.1) | Home-brew PC running XP Pro | DENON DRA-395 | PSB
Stratus
The sceptics on the architecture better take a look around... I think it
makes *total* and utter sense to use *one* PC in the house as a server
for all sorts of things - that's where the most cost effective and
largest concentration of CPU power and storage is always going to
reside - so I want
UI latency is generally caused by slowdowns in SlimServer which have
nothing to do with the hardware interface being on the other end of a
network connection. Trying to fit the capabilities of SlimServer into
an embedded device would be impossible if it were any less capable than
a complete PC.
pablolie;188809 Wrote:
The sceptics on the architecture better take a look around... I think it
makes *total* and utter sense to use *one* PC in the house as a server
for all sorts of things - that's where the most cost effective and
largest concentration of CPU power and storage is always
Mark Lanctot;188768 Wrote:
I'm not so sure it's a poor design choice. Since most of its power is
housed in the server, the Squeezebox is the most customizeable,
flexible, changeable tech device of any sort available today IMHO.
I agree mostly, my only gripe, that's been somewhat
sander wrote:
My understanding the way it is now:
remote volume down pressed-Squeezebox: Volume down
Squeezebox-SlimServer: Is this OK?
SlimServer-Squeezebox: It's OK.
Squeezebox: Volume down
I don't think that's quite right. My understanding is:
remote volume down pressed-Squeezebox:
Quoting sander [EMAIL PROTECTED]:
My understanding the way it is now:
remote volume down pressed-Squeezebox: Volume down
Squeezebox-SlimServer: Is this OK?
SlimServer-Squeezebox: It's OK.
Squeezebox: Volume down
It's more like:
1. Squeezebox-SlimServer: irport received 7689807f
2.
seanadams;188848 Wrote:
Trying to fit the capabilities of SlimServer into an embedded device
would be impossible if it were any less capable than a complete PC.
One could reasonably argue for a Slimmer server, or for software
architecture improvements to reduce response time, but blaming
Sure you could, but it's just a PC and a Squeezebox in the same chassis.
I'm not saying it's a bad idea, just that there's nothing about the
client/server architecture that prevents one from doing that right now.
Many applications use the model even when both logical things are on the
same
MrSinatra;188869 Wrote:
if u had a rack style device, could it not run on linux, host SS, and
map drives to wherever ones music is? (or do http) perhaps it could
even host some music locally via flash storage.
i'd be willing to pay transporter type prices for such a device.You might,
erland;188898 Wrote:
The massmarket users:
- These users don't have a 24/7 server running in their house. They
don't want to pay a lot of money for a music streaming device.
Besides not wanting to leave a computer on, the mass market user is not
too keen on installing software, ripping
seanadams;188907 Wrote:
Besides not wanting to leave a computer on, the mass market user is not
too keen on installing software, ripping CDs, and taking the time to
organize a large collection but with Squeezenetwork you don't need
to do any of that. Personally I almost never access my
kdf;188866 Wrote:
Rearranging the architecture, while not impossible, probably isn't
feasible. Tuning performance and improving the latency of the server
is always a goal, but it is also something that is available to anyone
at any time to match their means/needs.
Wow, thanks
On 19-Mar-07, at 8:29 PM, sander wrote:
Thanks again this helped me understand this much better.
you may want to have a look at the network health plugin; it can give
you messages in the log
flagging any processes that take longer than the timings you set. If
you search on the forum, you'll
erland;188538 Wrote:
I really like the current approach where most logic is in SlimServer,
the main reason is that it make the SqueezeBox behaviour very
customizable. With all the logic in the SqueezeBox we would probably
have a solution with closed source software and none or very few
amcluesent;188539 Wrote:
You can't rely on the computing power of an arbitrary server
Has anyone told Google?
Those aren't _arbitrary_ servers. Google _owns_ them, and has gone to a
lot of trouble over the years figuring out what specs work for them.
--
totoro
squeezebox 3 - mccormack
SuperQ: Thanks for the clarification, I'm not an embedded programmer, or
even a regular programmer, but it seemed simple enough to me. I'm
running 6.5.1 and in general (90+% of the time) the response from the
Squeezebox is almost instantaneous, even artist searches in lazysearch,
but on the rare
Your server and network are not optimized for speed, yet you get
satisfying response 90+% of the time. You're complaining about speed
but you have chosen slower hardware.
Using even a cheap, throwaway PC as the server would likely eliminate
all the problems. A wired ethernet connection can
I sometimes use
Moose as an ersatz remote, but I would gladly sacrifice any volume
control from the server.
That's a very interesting remark: if you can use Moose's volume control,
but not the remote, than you've very probably got a communication problem
between your SB and the server, not
This is an interesting discussion. For Slim to penetrate the mass market
then they are either going to have to create a server solution to run
Slimserver or the SB4 is going to be a fatter client to offload the
server.
From my own experience the SB3 is fantastic and changed the way I
listen to
Well, I'm bringing up this one issue because I see it as something Slim
could possibly address in future releases, or should at least consider
IMHO.
The hardware I'm using has been advertised as compatible, and
acceptable according to both companies in a joint press release and on
both of their
Guys,
I agree with the OP about remote latency, connectivity and buffering.
These are all a pain in the backside for me.
However, they are also own goals, because I'm using an underpowered
server, one of my wireless routers is surrounded by electronics, the
other is surrounded by more
Laz wrote:
As I see it, Logitech/Slim can deal with this issue by simply upping
the minimum required server spec and bandwidth requirements for the
broader release.
Yeah, but they probably don't want to say the real solution: use wired
networking ;-) Or at least, use only one hop of
Pat Farrell wrote:
Laz wrote:
As I see it, Logitech/Slim can deal with this issue by simply upping
the minimum required server spec and bandwidth requirements for the
broader release.
Yeah, but they probably don't want to say the real solution: use wired
networking ;-) Or at
I've had my Squeezebox V3 for about a year now and got a ReadyNAS NV+ a
couple of months ago to complete the set. Now I'm aware of the various
performance issues between the two, but I've made my choice, and I can
live with it most of the time, but one thing infuriates me to no end:
Why does the
This is central to the design philosophy of the device - it is slim,
absolutely all the work is done on the server. Every single button
press on the remote (well, nearly every one...) goes back ot the
server, which decides what to do with it and then sends whatever it
needs to back to the
sander;188499 Wrote:
Now I'm aware of the various performance issues between the two, but
I've made my choice, and I can live with it most of the time...Will
this ever be better in a future firmware release or is this a known
limitation to the server/device?
The NV is underpowered, so
While slim sounds appealing the idea that every signal is sent back to
the server just seems unnecessary and wasteful.
This is a $300 device with the processing power that used to be common
in workstations. It's not an ATM where security is an issue, I can't
think of a scenario where a
sander;188506 Wrote:
While slim sounds appealing the idea that every signal is sent back to
the server just seems unnecessary and wasteful.
This is a $300 device with the processing power that used to be common
in workstations. It's not an ATM where security is an issue, I can't
think of a
sander;188506 Wrote:
It's not an ATM where security is an issue, I can't think of a scenario
where a volume/mute command from the unit should ever require
authorization from the server.
I thought that by using a custom .map on the server, one could pretty
much completely change what the
TimothyB;188524 Wrote:
I thought that by using a custom .map on the server, one could pretty
much completely change what the remote buttons do.
-- Timothy
(Also, I believe that someone has written a plugin that when his wife
turns the volume down, the server gradually cranks it back up
SuperQ;188530 Wrote:
This is a very simple, lightweight, and synchronous design. The only
disadvantage is that if there is latency introduced at any stage in the
pipeline, say the slimserver is busy and does not respond to the
keypress, UI is adversely affected.
Simple is the keyword here.
On 17-Mar-07, at 10:42 PM, JJZolx wrote:
. That's about to end.
got any stock tips?
-kdf
___
discuss mailing list
discuss@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/discuss
JJZolx;188535 Wrote:
The only disadvantage to this approach is that it's one that is not
going to fly in the consumer world. I don't care how you rationalize
it: It's a dead end. You can't rely on the computing power of an
arbitrary server, what that server might be doing, what it might be
You can't rely on the computing power of an arbitrary server
Has anyone told Google?
--
amcluesent
amcluesent's Profile: http://forums.slimdevices.com/member.php?userid=10286
View this thread:
60 matches
Mail list logo
