PDA

View Full Version : SlimServer 6.0b1 Cannot connect



Bill Moseley
2005-03-09, 00:10
I downloaded 5.4.0 from the slimdevices.com and it installed and ran
without any problem from where I unpacked it.

Here's how I started it:

moseley@bumby:~/SlimServer_v5.4.0$ cat start.sh
#!/bin/sh

CWD=$(pwd)

../slimserver.pl --daemon \
--audiodir $HOME/music \
--cachedir $CWD/cache \
--logfile $CWD/server.log \
--prefsfile $CWD/server.prefs \
--pidfile $CWD/server.pid \
"$@"


Within minutes, slimdevices.com had been updated with slimserver6.0b1
(SlimServer_v2005-03-08)

So I then download that and used the same startup script. Everything
seems ok, except when I select "play" in the web interface xmms just
says "PRE-BUFFERING: 0KB/32KB" and never plays.

Is there something I'm missing in how to start the server?

Should I be posting this on the devel list?


--
Bill Moseley
moseley (AT) hank (DOT) org

Bill Moseley
2005-03-09, 12:25
Anyone have a suggestion about this? It would be nice if I could get
the slimserver software running.

Thanks,

On Tue, Mar 08, 2005 at 11:10:35PM -0800, Bill Moseley wrote:
> I downloaded 5.4.0 from the slimdevices.com and it installed and ran
> without any problem from where I unpacked it.
>
> Here's how I started it:
>
> moseley@bumby:~/SlimServer_v5.4.0$ cat start.sh
> #!/bin/sh
>
> CWD=$(pwd)
>
> ./slimserver.pl --daemon \
> --audiodir $HOME/music \
> --cachedir $CWD/cache \
> --logfile $CWD/server.log \
> --prefsfile $CWD/server.prefs \
> --pidfile $CWD/server.pid \
> "$@"
>
>
> Within minutes, slimdevices.com had been updated with slimserver6.0b1
> (SlimServer_v2005-03-08)
>
> So I then download that and used the same startup script. Everything
> seems ok, except when I select "play" in the web interface xmms just
> says "PRE-BUFFERING: 0KB/32KB" and never plays.
>
> Is there something I'm missing in how to start the server?
>
> Should I be posting this on the devel list?
>
>

--
Bill Moseley
moseley (AT) hank (DOT) org

kdf
2005-03-09, 12:28
Quoting Bill Moseley <moseley (AT) hank (DOT) org>:

> Anyone have a suggestion about this? It would be nice if I could get
> the slimserver software running.
>
try log output for:
--d_http --d_source

are you able to get playback using softsqueeze?

-kdf

Bill Moseley
2005-03-09, 12:44
On Wed, Mar 09, 2005 at 11:28:56AM -0800, kdf wrote:
> Quoting Bill Moseley <moseley (AT) hank (DOT) org>:
>
> > Anyone have a suggestion about this? It would be nice if I could get
> > the slimserver software running.
> >
> try log output for:
> --d_http --d_source

Once I hit play and then xmms says "pre-buffering" I see this
repeated over and over: .3 is this laptop.

2005-03-09 11:39:03.0827 Nothing to stream, let's wait for 0.05 seconds...
2005-03-09 11:39:03.0836 Got nothing for streaming data to 192.168.1.3
2005-03-09 11:39:03.1349 sendstreaming response begun...
2005-03-09 11:39:03.1359 We need to send 0 seconds of silence...
2005-03-09 11:39:03.1366 sending 0 bytes of silence
2005-03-09 11:39:03.1369 192.168.1.3: No filehandle to read from, returning no chunk.

Same thing with mpg321.


> are you able to get playback using softsqueeze?

Don't have it installed (don't have java on this laptop). But xmms
and mpg321 have worked without any problems before on other versions.

Thanks for helping!

--
Bill Moseley
moseley (AT) hank (DOT) org

kdf
2005-03-09, 13:07
Quoting Bill Moseley <moseley (AT) hank (DOT) org>:

> On Wed, Mar 09, 2005 at 11:28:56AM -0800, kdf wrote:
> > Quoting Bill Moseley <moseley (AT) hank (DOT) org>:
> >
> > > Anyone have a suggestion about this? It would be nice if I could get
> > > the slimserver software running.
> > >
> > try log output for:
> > --d_http --d_source
>
> Once I hit play and then xmms says "pre-buffering" I see this
> repeated over and over: .3 is this laptop.
>
> 2005-03-09 11:39:03.0827 Nothing to stream, let's wait for 0.05 seconds...
> 2005-03-09 11:39:03.0836 Got nothing for streaming data to 192.168.1.3
> 2005-03-09 11:39:03.1349 sendstreaming response begun...
> 2005-03-09 11:39:03.1359 We need to send 0 seconds of silence...
> 2005-03-09 11:39:03.1366 sending 0 bytes of silence
> 2005-03-09 11:39:03.1369 192.168.1.3: No filehandle to read from, returning
> no chunk.
>

looks like something is hanging in the playback. can you find where the log
shows the song starting playback? This would be where it tried to construct
the playback command, searching for format options, etc. output from d_source.

-kdf

Bill Moseley
2005-03-09, 13:55
On Wed, Mar 09, 2005 at 12:07:50PM -0800, kdf wrote:
> looks like something is hanging in the playback. can you find where the log
> shows the song starting playback? This would be where it tried to construct
> the playback command, searching for format options, etc. output from d_source.

I think I understand -- slimpserver 6 thinks it's connecting to
squeezebox2 which can play wav/flac, etc directly. I had .ogg queued
up and that gets mapped to wav with 6.0. .ogg played fine with xmms
with 5.4.0. With 6.0b1 I'm only able to play .mp3.

Makes sense. Guess I need to figure out how to setup convert.conf to
set encoding based on the player. Hum, maybe that's not the right
place. How does the server determine what the client is (xmms, sb1,
sb2) and what conversion to use?

--
Bill Moseley
moseley (AT) hank (DOT) org

kdf
2005-03-09, 14:09
Quoting Bill Moseley <moseley (AT) hank (DOT) org>:

> On Wed, Mar 09, 2005 at 12:07:50PM -0800, kdf wrote:
> > looks like something is hanging in the playback. can you find where the
> log
> > shows the song starting playback? This would be where it tried to
> construct
> > the playback command, searching for format options, etc. output from
> d_source.
>
> I think I understand -- slimpserver 6 thinks it's connecting to
> squeezebox2 which can play wav/flac, etc directly. I had .ogg queued
> up and that gets mapped to wav with 6.0. .ogg played fine with xmms
> with 5.4.0. With 6.0b1 I'm only able to play .mp3.
>
> Makes sense. Guess I need to figure out how to setup convert.conf to
> set encoding based on the player. Hum, maybe that's not the right
> place. How does the server determine what the client is (xmms, sb1,
> sb2) and what conversion to use?
>
any player that connects to http://serverIP:9000/stream.mp3 should be getting
detected as player type 'http', which is given a 320kbps bitrate limit and
'mp3' format only support. clearly, this detection is broken.

otherwise, the server uses the reponse from a slimproto query. Odd, still, that
yoru player could stil be detected as sb2 if clearly xmms can't possible have
responded with a deviceid.

-kdf

-kdf

rtitmuss
2005-03-09, 14:25
kdf wrote:

>any player that connects to http://serverIP:9000/stream.mp3 should be getting
>detected as player type 'http', which is given a 320kbps bitrate limit and
>'mp3' format only support. clearly, this detection is broken.
>
>otherwise, the server uses the reponse from a slimproto query. Odd, still, that
>yoru player could stil be detected as sb2 if clearly xmms can't possible have
>responded with a deviceid.
>
>
>
Bill, have you connected using Softsqueeze from the same PC? This will
break the player detection and make the slimserver think an http player
is a squeezebox2. If you restart the slimserver then it will be ok again.

kdf, we did discuss this a few months back, but never worked out a
suitable fix.

Richard

kdf
2005-03-09, 14:34
Quoting Richard Titmuss <richard.titmuss (AT) gmail (DOT) com>:

> kdf wrote:
>
> >any player that connects to http://serverIP:9000/stream.mp3 should be
> getting
> >detected as player type 'http', which is given a 320kbps bitrate limit and
> >'mp3' format only support. clearly, this detection is broken.
> >
> >otherwise, the server uses the reponse from a slimproto query. Odd, still,
> that
> >yoru player could stil be detected as sb2 if clearly xmms can't possible
> have
> >responded with a deviceid.
> >
> >
> >
> Bill, have you connected using Softsqueeze from the same PC? This will
> break the player detection and make the slimserver think an http player
> is a squeezebox2. If you restart the slimserver then it will be ok again.
>
> kdf, we did discuss this a few months back, but never worked out a
> suitable fix.

yes, I recall. I didn't mention becuase I think its been mentioned in this
thread that java isn't installed, so SS isn't an option. Still, good to at
least know why it isn't connecting. A good way to work around this would be to
forget player first...or if you dont much care about your current server
settings, erase them or move the away temporarily.

-kdf

Bill Moseley
2005-03-09, 16:15
On Wed, Mar 09, 2005 at 01:09:09PM -0800, kdf wrote:
> any player that connects to http://serverIP:9000/stream.mp3 should be getting
> detected as player type 'http', which is given a 320kbps bitrate limit and
> 'mp3' format only support. clearly, this detection is broken.

Ah I found it. Notice that the command is:

-q $QUALITY$ -b ...

but the actual command is

-q -b 320

So $QUALITY$ is not getting substituted. (Lame is printing out Could not find "320").
Hence the warning on line 1468 of Source.pm. Good reason to pay
attention to those warnings. There's a default for "lameQuality" in
$defaultPrefs, so not clear why it's not being used.

In Slim::Utils::Prefs.pm:

# get($pref)
sub get {+
return $prefs{$_[0]}+
};

Seems like one would want to test for undefined/exists in the $prefs
hash to at least catch typos. Anyway, seems like lameQuality is not
getting stored in the hash key: 192.168.1.3-lameQuality. It's only
just "lameQuality". Confusion about server vs. client settings, I
suppose. Humm, a single-level config hash.

Anyway, I see initClientPrefs() is not being called for that
client. I wonder why.

$ find -name \*.pm | xargs fgrep initClientPrefs
../Slim/Utils/Prefs.pm:sub initClientPrefs {
../Slim/Player/Player.pm: Slim::Utils::Prefs::initClientPrefs($client, $defaultPrefs);
../Slim/Player/Squeezebox2.pm: Slim::Utils::Prefs::initClientPrefs($client,$defau ltPrefs);
../Slim/Player/Client.pm: Slim::Utils::Prefs::initClientPrefs($client,$defau ltPrefs);
../Slim/Player/SqueezeboxG.pm: Slim::Utils::Prefs::initClientPrefs($client,$defau ltPrefs);

Oh. Now I'm starting to want to rewrite some code. ;)




2005-03-09 12:43:02.7904 file type: ogg format: mp3 inrate: 128 maxRate: 320
2005-03-09 12:43:02.7906 command: [oggdec] -Q -o - -R $FILE$ | [lame] --resample 44100 --silent -q $QUALITY$ -b $BITRATE$ -r -x - -
Use of uninitialized value in substitution (s///) at /home/moseley/SlimServer_v2005-03-08/Slim/Player/Source.pm line 1468.
2005-03-09 12:43:02.7916 Using command for conversion: "/home/moseley/SlimServer_v2005-03-08/Bin/i386-linux-thread-multi/oggdec" -Q -o - -R "/home/moseley/music/Reggae/various_artists/first_family_of_reggae/various_artists - first_family_of_reggae - 15 - ras_michael__marriage_in_canaan.ogg" | "/usr/bin/lame" --resample 44100 --silent -q -b 320 -r -x - - & |
2005-03-09 12:43:02.8223 Streaming with format: mp3
Could not find "320".
Error writing to file: Broken pipe
2005-03-09 12:43:02.9051 192.168.1.3 New play mode: play
2005-03-09 12:43:02.9061 192.168.1.3: Current playmode: play
2005-03-09 12:43:02.9070 Generating response for (htm, text/html) status_header.html
2005-03-09 12:43:02.9073 generating from include.html
Use of uninitialized value in numeric eq (==) at /home/moseley/SlimServer_v2005-03-08/Slim/Web/Pages.p:m line 961.
Use of uninitialized value in numeric eq (==) at /home/moseley/SlimServer_v2005-03-08/Slim/Web/Pages.pm line 961.
2005-03-09 12:43:02.9250 generating from status_header.html
2005-03-09 12:43:02.9314 End request: keepAlive: [8] - waiting for next request on connection = keep-alive

2005-03-09 12:43:02.9329 No more messages to send to 192.168.1.3
2005-03-09 12:43:02.9337 sendstreaming response begun...
2005-03-09 12:43:02.9348 We need to send 0 seconds of silence...
2005-03-09 12:43:02.9352 sending 0 bytes of silence
2005-03-09 12:43:02.9359 Read to end of file or pipe



>
> otherwise, the server uses the reponse from a slimproto query. Odd, still, that
> yoru player could stil be detected as sb2 if clearly xmms can't possible have
> responded with a deviceid.
>
> -kdf
>
> -kdf
>

Bill Moseley
2005-03-09, 23:06
Not sure if anyone with cvs access is listening, but the problem is
that the client init code (which loads the default variable) is not
being called. It's not very clear what is suppose to happen. Here's
what is happening, though:

In Slim::Web::HTTP::processURL() there's this:

if ($paddr) {
$client = Slim::Player::HTTP->new($address, $paddr, $httpClient);
$client->init();
}

The question is which init() is that suppose to be??

So, in Slim::Player::HTTP::new() $client is created like this:

my $client = Slim::Player::Client->new($id, $paddr);

And indeed in Slim::Player::Client there's an init() *function* that
sets the default variables. Note that this is not a method call, and
it's also never being called. Here's that init function:

sub init {
my $client = shift;
# make sure any preferences unique to this client may not have set are set to the default
Slim::Utils::Prefs::initClientPrefs($client,$defau ltPrefs);
}


So, at this point calling $client->init would initialize the
default client variables (if it was a method call).

But, if you look back at Slim::Player::HTTP::new()
$client is re-blessed. It's blessed into the Slim::Player::HTTP
class from the Slim::Player::Client class.


sub new {
my ($class, $id, $paddr, $tcpsock) = @_;

my $client = Slim::Player::Client->new($id, $paddr);

$client->streamingsocket($tcpsock);

bless $client, $class; # re-bless $client.

return $client;
}

So when $client->init() is called (up there in processURL) it's
not running the init() method that would initialize the client
variables.

I cannot guess what the programmer intended. Perhaps
Slim::Player::HTTP::init() should be modified like:

sub init {
my $client = shift;
$client->SUPER::init(); # add this line
$client->startup();
}

and then Slim::Player::Client::init() should be made into a method call.
Or, maybe the programmer intended to just call init($client) in
Slim::Player::Client::new(). That I cannot guess.

And that doesn't even fix it, because the missing parameter
"lameQuality" is not defined in $Slim::Player::Client::defaultPrefs.

Was "lameQuality" intended to be a client parameter or a global param?
Looks like a client variable.

Slim/Player/Source.pm:
my $quality = Slim::Utils::Prefs::clientGet($client,'lameQuality ');

So I'll just assume that it was left out of $Slim::Player::Client::defaultPrefs
by mistake.


Someday...

I think it would help to have a configuration base class with all
defaults, and override methods for specific client classes.
Something like:

# Add "config" method with this clients prefs
$client->init_prefs( $defaultPrefs );

Then later:

$quality = $client->config->lameQuality;

Which would clean things up quite a bit, and catch typos, too.


--
Bill Moseley
moseley (AT) hank (DOT) org

kdf
2005-03-09, 23:22
Quoting Bill Moseley <moseley (AT) hank (DOT) org>:

> Not sure if anyone with cvs access is listening, but the problem is
> that the client init code (which loads the default variable) is not
> being called. It's not very clear what is suppose to happen. Here's
> what is happening, though:
>
> In Slim::Web::HTTP::processURL() there's this:
>
> if ($paddr) {
> $client = Slim::Player::HTTP->new($address, $paddr, $httpClient);
> $client->init();
> }
>
> The question is which init() is that suppose to be??

It can be anything you like. However, if you want to get developer input on
your musings, you are generally better off joining the devlopers list and
posting there. diff -upB patches are most welcome on any suggestions :)

it is entirely possible that the default pref has been overlooked.

-kdf

kdf
2005-03-09, 23:35
Quoting Bill Moseley <moseley (AT) hank (DOT) org>:

> Not sure if anyone with cvs access is listening, but the problem is
> that the client init code (which loads the default variable) is not
> being called. It's not very clear what is suppose to happen. Here's
> what is happening, though:

oh, and yes...I think that the init was missed too :)

I'll try this out...
-kdf