PDA

View Full Version : problems with symbolic linking



Phil Karn
2005-03-12, 04:15
For some reason, slimserver 5.4 doesn't like to run when
/usr/local/slimserver is a symbolic link to the actual installation
directory.

Let's say /usr/local/slimserver is a symbolic link to
/usr/local/slimserver_5.4. If I then invoke
/usr/local/slimserver/slimserver.pl, it quickly bombs with the cryptic
error message

Can't use an undefined value as an ARRAY reference at
/usr/local/slimserver_5.4/Slim/Player/SqueezeboxG.pm line 123.

But if I eliminate the symbolic link and rename the slimserver_5.4
directory to be simply /usr/local/slimserver, then it works normally.

I'd sure like to be able to use symbolic links to make it easier to
switch between the relatively stable 5.4 and the unstable version 6
releases.

--Phil

kdf
2005-03-12, 04:22
Quoting Phil Karn <karn (AT) ka9q (DOT) net>:

> For some reason, slimserver 5.4 doesn't like to run when
> /usr/local/slimserver is a symbolic link to the actual installation
> directory.
>
> Let's say /usr/local/slimserver is a symbolic link to
> /usr/local/slimserver_5.4. If I then invoke
> /usr/local/slimserver/slimserver.pl, it quickly bombs with the cryptic
> error message
>
> Can't use an undefined value as an ARRAY reference at
> /usr/local/slimserver_5.4/Slim/Player/SqueezeboxG.pm line 123.
>

that's a font crash. are you trying to run slimserver 5.4 with a softsqueeze
session that is still running from 6.0?

SB2 (and softsqueeze 2.0a11) use different fonts, so they will cause earlier
servers to barf.

It may also be that you ran with 6.0 and it had the same MAC addy, so the player
prefs have been updated with SB2 stuff. You may have some better luck if you
play with the softsqueeze settings to have different mac addresses.

-kdf

Phil Karn
2005-03-12, 05:12
kdf wrote:

> that's a font crash. are you trying to run slimserver 5.4 with a softsqueeze
> session that is still running from 6.0?
>
> SB2 (and softsqueeze 2.0a11) use different fonts, so they will cause earlier
> servers to barf.
>
> It may also be that you ran with 6.0 and it had the same MAC addy, so the player
> prefs have been updated with SB2 stuff. You may have some better luck if you
> play with the softsqueeze settings to have different mac addresses.

I just figured that out for myself a few seconds ago. When I killed the
copy of softsqueeze I had been running, slimserver 5.4 came back up.

You know, I hate to say this but it's really been bothering me for some
time and I think I need to say it. The Squeezebox is a *really* nice
piece of hardware. When it works, it's wonderful. The design philosophy
of having the box do just the essential functions and do them well while
moving all the smarts to a much more capable and open server is exactly
the right approach.

But this also means that without its server, the Squeezebox is a totally
useless lump of plastic. So that server has *got* to be reliable.

Since I got my first Squeezebox, I've been more than a little surprised
at the overall brittleness of the server software, at least on Linux (I
haven't tried any of the other OS versions). It seems to abruptly exit
at the slightest provocation, such as this little mixup on fonts.
Various cryptic Perl error messages appear from time to time in the log;
whether they're cause for concern, I haven't a clue. Seemingly simple
web operations, like walking down a directory tree, often take undue
amounts of time. Sometimes I'll see it gobbling all available CPU time
for no apparent reason; aborting and restarting seems to make it behave
again for a while. Clicking "rescan" after adding music rarely seems to
work right; I almost always have to blow away the cache and restart. And
so on.

That's with the 5.4 version. The 6.0 versions have been even worse; I
haven't gotten one to play yet without crashing within the first minute
or two with another flurry of cryptic Perl error messages.

This is not quite what I expected from a consumer product seeking a mass
market. It is just not reasonable to expect every user of a device like
this to be a skilled Perl hacker, able to know that a cryptic message like

Can't use an undefined value as an ARRAY reference at
/usr/local/slimserver_5.4/Slim/Player/SqueezeboxG.pm line 123.

followed by an abrupt server crash means that you're running an
incompatible version of the client somewhere on your network. Not only
should the error message be a little more informative, but the user just
might be forgiven for foolishly expecting that software written as a
multi-user network server should be just a little more robust against
unexpected input in general.

I don't know why it should be so difficult to make a simple and robust
server for this thing. Perhaps the other users consider a rich selection
of 17 web "skins" and the various plugins and news ticker crawls more
important than basic functionality and robustness; I don't know. But I
do know that, as nice as the Squeezebox is, I just can't recommend it
yet to my less technical friends until it comes with a *far* more robust
and foolproof server. When it does, I'll recommend it wholeheartedly.

--Phil

Dan Sully
2005-03-12, 10:40
* Phil Karn shaped the electrons to say...

>That's with the 5.4 version. The 6.0 versions have been even worse; I
>haven't gotten one to play yet without crashing within the first minute
>or two with another flurry of cryptic Perl error messages.
>
>This is not quite what I expected from a consumer product seeking a mass
>market. It is just not reasonable to expect every user of a device like
>this to be a skilled Perl hacker, able to know that a cryptic message like

I agree completely Phil - we're focused right now on making 6.0 stable. There
was a big jump in functionality, speed and stability in changing out the
entire backend between 5.4 and 6.0. However, as you well know, bugs are
introduced along the way.

If you could send along the 6.0 error messages you've received and/or create
bugs reports for them, it will help us bring the server up to a stable piece
of software for everyone.

>Can't use an undefined value as an ARRAY reference at
>/usr/local/slimserver_5.4/Slim/Player/SqueezeboxG.pm line 123.
>
>followed by an abrupt server crash means that you're running an
>incompatible version of the client somewhere on your network. Not only
>should the error message be a little more informative, but the user just
>might be forgiven for foolishly expecting that software written as a
>multi-user network server should be just a little more robust against
>unexpected input in general.

I'll get in a work around for this. It should be documented that SoftSqueeze2
and SB2 don't work with 5.4, but it certainly shouldn't crash.

>I don't know why it should be so difficult to make a simple and robust
>server for this thing. Perhaps the other users consider a rich selection
>of 17 web "skins" and the various plugins and news ticker crawls more

Features are a selling point of the server. I personally have no use for a
lot of the server features, but I can see how they are useful and an
incentive for a lot of people. Difficulty also comes in being cross platform.
You have no idea how much I dislike Win32 on a day to day basis. Granted,
this might be easier in Java, but then you'd be getting a cryptic JVM
backtrace instead. ;)

-D
--
<dr.pox> do they call it 'gq' because it makes your text fashionable?

Phil Karn
2005-03-13, 01:48
Dan Sully wrote:

> I agree completely Phil - we're focused right now on making 6.0 stable.
> There
> was a big jump in functionality, speed and stability in changing out the
> entire backend between 5.4 and 6.0. However, as you well know, bugs are
> introduced along the way.

I think this is exactly where the problem is. I shouldn't be forced to
choose between an old version with lots of bugs, and a new,
bleeding-edge version that fixes (most of) the older bugs, but also
introduces many new bugs associated with lots of new features that are
largely useless to me.

There really should be two, separately maintained code bases: a "stable"
version where stability and robustness are paramount, and an
experimental version with the latest new features that may not be
particularly stable.

This *doesn't* mean that you never update the "stable" version. You
update it as often as you have to to fix a bug or security hole. Even
daily, if you have to. But new features, even seemingly simple ones, are
*prohibited*. Those go only into the experimental tree.

I think the Debian Linux project does it exactly right. Debian has three
flavors: "stable", which is regularly updated *only* with security
fixes; "unstable", with all the latest, bleeding edge features; and
"testing", which is something like stable, but periodically updated with
features that have proven themselves for a while in the "unstable"
version. Once in a while, you rev the "stable" version, including only
those new features that have already withstood the test of time. It
works pretty well for me.

Phil