Web interface problem

[John Gorst]

Version 5.1.4, Windows XP

When I start up the server the following errors occur in the debug window:
SlimServer has started!
Use of uninitialized value in transliteration (tr///) at
/PerlApp/File/Spec/Win32.pm line 99.
Use of uninitialized value in pattern match (m//) at
/PerlApp/File/Spec/Win32.pm line 101.
[repeated many times!]

Also, I get the following error in the debug window when I click 'next'
track on the web interface status page:
Argument "" isn't numeric in numeric lt (<) at
C:/PROGRA~1/SLIMSE~1/server/Cache/C/PROGRA~1/SLIMSE~1/server/HTML/Handheld/status.html
line 1107.
Argument "" isn't numeric in numeric lt (<) at
C:/PROGRA~1/SLIMSE~1/server/Cache/C/PROGRA~1/SLIMSE~1/server/HTML/Handheld/status.html
line 1125.
Argument "" isn't numeric in numeric gt (>) at
C:/PROGRA~1/SLIMSE~1/server/Cache/C/PROGRA~1/SLIMSE~1/server/HTML/Handheld/status.html
line 1145.
Argument "" isn't numeric in numeric gt (>) at
C:/PROGRA~1/SLIMSE~1/server/Cache/C/PROGRA~1/SLIMSE~1/server/HTML/Handheld/status.html
line 1163.

When looking at the status page of a softsqueeze player none of these
errors occur, which is very odd - even if a http stream is also playing.

When using 'default' skin it says file not found.

I have tried uninstalling the server, deleting all files, then
reinstalling with no difference - so it is not any stupid settings I
have changed!

When I hardcode transcoding to upsample http streams to 320kbps in
convert.conf I have further problems. Intermittently parts of the status
page fail to load when I click 'next'(e.g. the album art) and even the
page fails to load at all and I need to press the link again. No error
occurs in the browser (Firefox) it just says connecting to 127.0.0.1....
(this is the reason why I started to look into the debug file!)

Hope someone can help!
Cheers

[kdf]

Quoting John Gorst <john_gorst (AT) hotmail (DOT) com>:

> Version 5.1.4, Windows XP
>
> When I start up the server the following errors occur in the debug window:
> SlimServer has started!
> Use of uninitialized value in transliteration (tr///) at
> /PerlApp/File/Spec/Win32.pm line 99.
> Use of uninitialized value in pattern match (m//) at
> /PerlApp/File/Spec/Win32.pm line 101.
> [repeated many times!]
>

the above is due to the Artwork filename setting no being used in your system.
Its just a warning, nothing to worry about, and is fixed in the nightly.

The rest, I dont know about. Somethign not quite right in the conversion of the
Handheld skin for Template Toolkit, I assume

-kdf

[John Gorst]

Just upgraded to latest nightly, errors refferring to line 99 and 101 gone!

However the other problem is still persisting, and has changed slightly
in this release. It is not symptomatic if I do not have transcoding
turned on, it now jsut gives the following lines in the debug log when i
click 'next' in the status page:
Use of uninitialized value in string eq at /PerlApp/Slim/Web/HTTP.pm
line 967. [5 more times]
Argument "" isn't numeric in numeric lt (<) at
C:/PROGRA~1/SLIMSE~1/server/Cache/C/PROGRA~1/SLIMSE~1/server/HTML/Handheld/status.html
line 1107.
Argument "" isn't numeric in numeric lt (<) at
C:/PROGRA~1/SLIMSE~1/server/Cache/C/PROGRA~1/SLIMSE~1/server/HTML/Handheld/status.html
line 1125.
Argument "" isn't numeric in numeric gt (>) at
C:/PROGRA~1/SLIMSE~1/server/Cache/C/PROGRA~1/SLIMSE~1/server/HTML/Handheld/status.html
line 1145.
Argument "" isn't numeric in numeric gt (>) at
C:/PROGRA~1/SLIMSE~1/server/Cache/C/PROGRA~1/SLIMSE~1/server/HTML/Handheld/status.html
line 1163.

If I have transcoding switched on (see relevent section of convert.conf
later in post) I get the following debug log and intermittent (every
other click) failure of clicking on 'next' actually loading up the next
page: (note the mp3 stream is playing perfectly in winamp at this time)
Error writing mp3 output
Argument "" isn't numeric in numeric lt (<) at
C:/PROGRA~1/SLIMSE~1/server/Cache/C/PROGRA~1/SLIMSE~1/server/HTML/Handheld/status.html
line 1107.
Argument "" isn't numeric in numeric lt (<) at
C:/PROGRA~1/SLIMSE~1/server/Cache/C/PROGRA~1/SLIMSE~1/server/HTML/Handheld/status.html
line 1125.
Argument "" isn't numeric in numeric gt (>) at
C:/PROGRA~1/SLIMSE~1/server/Cache/C/PROGRA~1/SLIMSE~1/server/HTML/Handheld/status.html
line 1145.
Argument "" isn't numeric in numeric gt (>) at
C:/PROGRA~1/SLIMSE~1/server/Cache/C/PROGRA~1/SLIMSE~1/server/HTML/Handheld/status.html
line 1163.
ID3v2 found. Be aware that the ID3 tag is currently lost when transcoding.


part of convert.conf file I have edited
# Special for the webserver
mp3 mp3 http *
-

mp3 mp3 http 192.168.2.2
[lame] --resample 44100 --silent -b 320 $FILE$ -


# special case for smart bitrates on mp3 input
mp3 mp3 downsample *
[lame] --resample 44100 --silent -b $BITRATE$ $FILE$ -

Hope someone can help

John Gorst wrote:

> Version 5.1.4, Windows XP
>
> When I start up the server the following errors occur in the debug window:
> SlimServer has started!
> Use of uninitialized value in transliteration (tr///) at
> /PerlApp/File/Spec/Win32.pm line 99.
> Use of uninitialized value in pattern match (m//) at
> /PerlApp/File/Spec/Win32.pm line 101.
> [repeated many times!]
>
> Also, I get the following error in the debug window when I click 'next'
> track on the web interface status page:
> Argument "" isn't numeric in numeric lt (<) at
> C:/PROGRA~1/SLIMSE~1/server/Cache/C/PROGRA~1/SLIMSE~1/server/HTML/Handheld/status.html
> line 1107.
> Argument "" isn't numeric in numeric lt (<) at
> C:/PROGRA~1/SLIMSE~1/server/Cache/C/PROGRA~1/SLIMSE~1/server/HTML/Handheld/status.html
> line 1125.
> Argument "" isn't numeric in numeric gt (>) at
> C:/PROGRA~1/SLIMSE~1/server/Cache/C/PROGRA~1/SLIMSE~1/server/HTML/Handheld/status.html
> line 1145.
> Argument "" isn't numeric in numeric gt (>) at
> C:/PROGRA~1/SLIMSE~1/server/Cache/C/PROGRA~1/SLIMSE~1/server/HTML/Handheld/status.html
> line 1163.
>
> When looking at the status page of a softsqueeze player none of these
> errors occur, which is very odd - even if a http stream is also playing.
>
> When using 'default' skin it says file not found.
>
> I have tried uninstalling the server, deleting all files, then
> reinstalling with no difference - so it is not any stupid settings I
> have changed!
>
> When I hardcode transcoding to upsample http streams to 320kbps in
> convert.conf I have further problems. Intermittently parts of the status
> page fail to load when I click 'next'(e.g. the album art) and even the
> page fails to load at all and I need to press the link again. No error
> occurs in the browser (Firefox) it just says connecting to 127.0.0.1....
> (this is the reason why I started to look into the debug file!)
>
> Hope someone can help!
> Cheers

[kdf]

Quoting John Gorst <john_gorst (AT) hotmail (DOT) com>:

> part of convert.conf file I have edited
> # Special for the webserver
> mp3 mp3 http *
> -
>
> mp3 mp3 http 192.168.2.2
> [lame] --resample 44100 --silent -b 320 $FILE$ -
>
>
> # special case for smart bitrates on mp3 input
> mp3 mp3 downsample *
> [lame] --resample 44100 --silent -b $BITRATE$ $FILE$ -
>
> Hope someone can help
>

Why are you forcing 320kbps output for one player? With the latest build, you
can set the max bitrate for each player from the player settings. This way,
mp3's encoded at rates lower than the setting play normally, and ones that are
higher will be recoded at your max bitrate. Causing them all to be recoded to
320 is adding a process and I doubt you get any better audio by upconverting an
mp3 already coded at a lower rate.

The messages from you Handheld skin re hard to debug, since those are related to
your locally cached version and not to the templates themselves. You would have
to find the file indicated, and paste the lines in question:
C:/PROGRA~1/SLIMSE~1/server/Cache/C/PROGRA~1/SLIMSE~1/server/HTML/Handheld/status.html
Lines 1100-1170

HTTP.pm line 967 is related to clearing the client buffers. I'm not sure what
exactly this is trying to do that causes the error. I am wondering if perhaps
this part of the code is being called before your server has discovered the
clients, or perhaps there are somehow clients detected that are no longer present.

-kdf

[John Gorst]

kdf wrote:

> Why are you forcing 320kbps output for one player? With the latest
build, you
> can set the max bitrate for each player from the player settings. This way,
> mp3's encoded at rates lower than the setting play normally, and ones that are
> higher will be recoded at your max bitrate. Causing them all to be recoded to
> 320 is adding a process and I doubt you get any better audio by upconverting an
> mp3 already coded at a lower rate.

Recoding up to 320kbps means that the slimserver buffer and winamp
buffer make as little impact as possible to the latency of the stream.
(reduces latency from 8 seconds for 192kbps to 5 seconds for 320kbps)

> The messages from you Handheld skin re hard to debug, since those are related to
> your locally cached version and not to the templates themselves. You would have
> to find the file indicated, and paste the lines in question:
> C:/PROGRA~1/SLIMSE~1/server/Cache/C/PROGRA~1/SLIMSE~1/server/HTML/Handheld/status.html
> Lines 1100-1170

status.html in the cahce is quite large (45k), more than I would expect?
Anyway here are lines 1100-1170

Line 1100 $output .= $stash->get('player');

&$filter($output);
};

$output .= "&start=1\"><font size=\"-2\">";
#line 73 "C:\PROGRA~1\SLIMSE~1\server\HTML\Handheld\status. html"
if ($stash->get('volume') < '1') {
$output .= "<b>";
}

#line 73 "C:\PROGRA~1\SLIMSE~1\server\HTML\Handheld\status. html"

# FILTER
$output .= do {
my $output = '';
my $filter = $context->filter('string')
|| $context->throw($context->error);

$output .= 'MCON';

&$filter($output);
};

#line 73 "C:\PROGRA~1\SLIMSE~1\server\HTML\Handheld\status. html"
if ($stash->get('volume') < '1') {
$output .= "</b>";
}

$output .= "</font></a>&nbsp;<a
href=\"status.html?p0=button&p1=muting&player=";
#line 73 "C:\PROGRA~1\SLIMSE~1\server\HTML\Handheld\status. html"

# FILTER
$output .= do {
my $output = '';
my $filter = $context->filter('uri')
|| $context->throw($context->error);

$output .= $stash->get('player');

&$filter($output);
};

$output .= "&start=0\"><font size=\"-2\">";
#line 73 "C:\PROGRA~1\SLIMSE~1\server\HTML\Handheld\status. html"
if ($stash->get('volume') > '0') {
$output .= "<b>";
}

#line 73 "C:\PROGRA~1\SLIMSE~1\server\HTML\Handheld\status. html"

# FILTER
$output .= do {
my $output = '';
my $filter = $context->filter('string')
|| $context->throw($context->error);

$output .= 'MCOFF';

&$filter($output);
};

#line 73 "C:\PROGRA~1\SLIMSE~1\server\HTML\Handheld\status. html"
if ($stash->get('volume') > '0') {
$output .= "</b>";
}

$output .= "</font></a></td>\n</tr>\n<tr>\n <td><font
size=\"-2\">";
#line 76 "C:\PROGRA~1\SLIMSE~1\server\HTML\Handheld\status. html"

# FILTER

> HTTP.pm line 967 is related to clearing the client buffers. I'm not sure what
> exactly this is trying to do that causes the error. I am wondering if perhaps
> this part of the code is being called before your server has discovered the
> clients, or perhaps there are somehow clients detected that are no longer present.

Very odd that this error only occurs when it is not transcoding. Is this
somethins to do with the new feature introduced in 5.1.3?
--
Streaming to MP3 Players
* Trying to reduce latency in the HTTP streaming. Clearing the
buffer if the song stops or changes.
--

Hope someone can help!

[kdf]

Quoting John Gorst <john_gorst (AT) hotmail (DOT) com>:

> kdf wrote:
>
> > Why are you forcing 320kbps output for one player? With the latest
> build, you
> > can set the max bitrate for each player from the player settings. This
> way,
> > mp3's encoded at rates lower than the setting play normally, and ones that
> are
> > higher will be recoded at your max bitrate. Causing them all to be recoded
> to
> > 320 is adding a process and I doubt you get any better audio by
> upconverting an
> > mp3 already coded at a lower rate.
>
> Recoding up to 320kbps means that the slimserver buffer and winamp
> buffer make as little impact as possible to the latency of the stream.
> (reduces latency from 8 seconds for 192kbps to 5 seconds for 320kbps)

ah ok. Well, personally I'm not so fussed about 3 seconds
I dont think that's relaly the problem anyway.

> > The messages from you Handheld skin re hard to debug, since those are
> related to
> > your locally cached version and not to the templates themselves. You would
> have
> > to find the file indicated, and paste the lines in question:
> >
>
C:/PROGRA~1/SLIMSE~1/server/Cache/C/PROGRA~1/SLIMSE~1/server/HTML/Handheld/status.html
> > Lines 1100-1170
>
> status.html in the cahce is quite large (45k), more than I would expect?
> Anyway here are lines 1100-1170
>
It is the full expansion of the page, which would include the playlist items
expanded to full html.

All the errors are due to this line, or others that are like it:
> if ($stash->get('volume') < '1') {
Streaming to winamp, there is NO volume control. Other skins, like Default and
Fishbone remove the volume controls (including mute) from the web UI if the
client isn't a known hardware player, or an emulator of a hardware player).
This could be the source of it. Have you tried other skins? I can see fron the
code for the handheld template that it would be querying the volume to determine
the state of the mute button. This would cause this warning if there was no
volume control available. I've attached a patch, which I can get into tonights
nightly build if you aren't up for patching it yourself


> Very odd that this error only occurs when it is not transcoding. Is this
> somethins to do with the new feature introduced in 5.1.3?

If the server is crealing buffers, it probably only has to do this when it has
direct control over the streaming. While transcoding, the stream is handed over
to LAME. That would explain the difference, though admittedly, I'm not certain
that is exactly what is happening.

-kdf

[John Gorst]

>>Recoding up to 320kbps means that the slimserver buffer and winamp
>>buffer make as little impact as possible to the latency of the stream.
>>(reduces latency from 8 seconds for 192kbps to 5 seconds for 320kbps)
>
>
> ah ok. Well, personally I'm not so fussed about 3 seconds
> I dont think that's relaly the problem anyway.

Think of it as a 37% reduction in latency which sounds good! Some of my
mp3's are in 128kbps so the latency is even greater for those songs.

> All the errors are due to this line, or others that are like it:
>
>> if ($stash->get('volume') < '1') {
>
> Streaming to winamp, there is NO volume control. Other skins, like Default and
> Fishbone remove the volume controls (including mute) from the web UI if the
> client isn't a known hardware player, or an emulator of a hardware player).
> This could be the source of it. Have you tried other skins? I can see fron the
> code for the handheld template that it would be querying the volume to determine
> the state of the mute button. This would cause this warning if there was no
> volume control available. I've attached a patch, which I can get into tonights
> nightly build if you aren't up for patching it yourself

You guessed correctly - I wouldnt have a clue how to patch it myself!
Other skins come up with the following error when I try and skip to the
next song:
Error writing mp3 output
file error - 1: not found
ID3v2 found. Be aware that the ID3 tag is currently lost when transcoding.
file error - 1: not found
file error - 1: not found
file error - 1: not found
file error - 1: not found
file error - 1: not found

>
>>Very odd that this error only occurs when it is not transcoding. Is this
>>somethins to do with the new feature introduced in 5.1.3?
>
> If the server is crealing buffers, it probably only has to do this when it has
> direct control over the streaming. While transcoding, the stream is handed over
> to LAME. That would explain the difference, though admittedly, I'm not certain
> that is exactly what is happening.

I can't see how this would stop SlimServer from sending the status page
though! I will see what happens with this new patch.

Cheers
John

[kdf]

Quoting John Gorst <john_gorst (AT) hotmail (DOT) com>:

>
> >>Recoding up to 320kbps means that the slimserver buffer and winamp
> >>buffer make as little impact as possible to the latency of the stream.
> >>(reduces latency from 8 seconds for 192kbps to 5 seconds for 320kbps)
> >
> >
> > ah ok. Well, personally I'm not so fussed about 3 seconds
> > I dont think that's relaly the problem anyway.
>
> Think of it as a 37% reduction in latency which sounds good! Some of my
> mp3's are in 128kbps so the latency is even greater for those songs.

yeah, I understand that part. For me, when I'm streaming remotely, I just load
a playlist and let it run. The only lag is the initial startup. I dont mind if
the display on winamp doesn't update the song title at the very same instant the
beat changes from one to another. It's just background music for me. When I
want to be picky, I'm at home sitting near the squeezebox with the remote
somewhere within reach

>
> > All the errors are due to this line, or others that are like it:
> >
> >> if ($stash->get('volume') < '1') {
> >
> > Streaming to winamp, there is NO volume control. Other skins, like Default
> and
> > Fishbone remove the volume controls (including mute) from the web UI if
> the
> > client isn't a known hardware player, or an emulator of a hardware player).
>
> > This could be the source of it. Have you tried other skins? I can see
> fron the
> > code for the handheld template that it would be querying the volume to
> determine
> > the state of the mute button. This would cause this warning if there was
> no
> > volume control available. I've attached a patch, which I can get into
> tonights
> > nightly build if you aren't up for patching it yourself
>
> You guessed correctly - I wouldnt have a clue how to patch it myself!

s'ok. I can submit a patch properly when I am at home tonight.

> Other skins come up with the following error when I try and skip to the
> next song:
> Error writing mp3 output
> file error - 1: not found
> ID3v2 found. Be aware that the ID3 tag is currently lost when transcoding.
> file error - 1: not found
> file error - 1: not found
> file error - 1: not found
> file error - 1: not found
> file error - 1: not found

that looks like a whole different animal. Hard to see who that would be a skin
related error, to be honest.

[John Gorst]

John Gorst wrote:

> When I hardcode transcoding to upsample http streams to 320kbps in
> convert.conf I have further problems. Intermittently parts of the status
> page fail to load when I click 'next'(e.g. the album art) and even the
> page fails to load at all and I need to press the link again. No error
> occurs in the browser (Firefox) it just says connecting to 127.0.0.1....
> (this is the reason why I started to look into the debug file!)

Same behaviour on a virgin install of 5.1.4 streaming using the
stream.mp3?bitrate=128 command. Seems that transcoding does something to
stop it from operating intermittently. Other skins seem to be less
reliable with this option also.

[John Gorst]

Good news is that latest nightly has fixed all problems when not
transcoding.

When I am transcoding (using stream.mp3?bitrate=128 for testing
purposes, same behaviour if hardcoded in convert.conf) I get the
following errors is the debug log when loading up pages on the web
interface:
file error - 1: not found
Error writing mp3 output
ID3v2 found. Be aware that the ID3 tag is currently lost when transcoding.

I expect the transcoding warning is normal, but the first two are a bit
worrying. It is causing intermittent problems browsing through different
skins as I have described in previous posts (need to click twice on any
link, album art not loading).

I have also had the intermittent problem of drop down selection boxes
not loading up at all (e.g. skin selection drop down box), happens on
all browsers and requires a restart of slimserver (handheld). At the
same time non of the server settings or player settings appear (default,
fishbone). However at the same time the 'light' server settings and drop
down boxes work perfectly. The only thing in the debug log is:
file error - 1: not found