PDA

View Full Version : Web interface problem



John Gorst
2004-04-20, 09:48
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
2004-04-20, 10:19
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
2004-04-20, 12:05
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
2004-04-20, 12:33
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
2004-04-20, 12:49
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.h tml"
if ($stash->get('volume') < '1') {
$output .= "<b>";
}

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

# 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.h tml"
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.h tml"

# 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.h tml"
if ($stash->get('volume') > '0') {
$output .= "<b>";
}

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

# 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.h tml"
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.h tml"

# 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
2004-04-20, 13:20
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
2004-04-20, 14:11
>>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
2004-04-20, 14:18
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
2004-04-20, 14:56
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
2004-04-21, 12:04
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

kdf
2004-04-21, 12:28
what file types are you using?
do you use iTunes/moodlogic?
If you have the MP3 Tag Cache enabled, can you click on Wipe Cache and let is
rescan. Then, try to play a file from browsing. Avoid saved playlists, just in
case.

-kdf

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

>
> 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
>
>

John Gorst
2004-04-21, 15:38
kdf wrote:
> what file types are you using?

MP3, playing by adding a whole album to the playlist

> do you use iTunes/moodlogic?

iTunes

> If you have the MP3 Tag Cache enabled, can you click on Wipe Cache and let is
> rescan. Then, try to play a file from browsing. Avoid saved playlists, just in
> case.

Mp3 Tag Database is set to 'don't cache', but this doesnt matter if I am
using itunes?

Should I try to recreate the fault without using iTunes database?

Seems very odd that this bug only surfaces when transcoding. I have just
noticed that the bug also occurs when transcoding to both http clients
and squeezebox clients (using the limit bandwidth option in player
settings) - so it must be a transcoding bug rather than a http server bug?

Cheers

> -kdf
>
> Quoting John Gorst <john_gorst (AT) hotmail (DOT) com>:
>
>
>>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
>>
>>

kdf
2004-04-21, 15:54
Quoting John Gorst <john_gorst (AT) hotmail (DOT) com>:


> > If you have the MP3 Tag Cache enabled, can you click on Wipe Cache and let
> is
> > rescan. Then, try to play a file from browsing. Avoid saved playlists,
> just in
> > case.
>
> Mp3 Tag Database is set to 'don't cache', but this doesnt matter if I am
> using itunes?
>
That's correct.

> Should I try to recreate the fault without using iTunes database?

Its worth trying with iTunes off, just to be sure if its an iTunes issue or not.

> Seems very odd that this bug only surfaces when transcoding. I have just
> noticed that the bug also occurs when transcoding to both http clients
> and squeezebox clients (using the limit bandwidth option in player
> settings) - so it must be a transcoding bug rather than a http server bug?

is odd, yes, and I can't reproduce it myself, so I can't say what must be wrong.
I am using some code that is very recently patched to cvs so it may be that its
fixed already.

-kdf

John Gorst
2004-04-22, 10:50
kdf wrote:
>>Should I try to recreate the fault without using iTunes database?

> Its worth trying with iTunes off, just to be sure if its an iTunes issue or not.

Still happens just the same without iTunes.
Only happens when transcoding is switched on, either for http streaming
or for hardware clients. Seems like every other request to the
slimserver stalls (sometimes it is the web page, sometimes it is just
the album art).

Do you get the following in your server debug when transcoding is on and
you change tunes?
Error writing mp3 output
ID3v2 found. Be aware that the ID3 tag is currently lost when transcoding.
Input file is freeformat.

The web page problem is 100% reproduceable on handheld skin on my
system, but happens infrequently on other skins liek default.

(upgraded to latest lame.exe version and ensured it is in server/bin/
directory)

Cheers

kdf
2004-04-22, 17:48
IO have managed to see the same thing, but so far only with SoftSqueeze. Winamp
doesn't show the problem, and I am not near a Squeezebox right now.

-kdf

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

> kdf wrote:
> >>Should I try to recreate the fault without using iTunes database?
>
> > Its worth trying with iTunes off, just to be sure if its an iTunes issue or
> not.
>
> Still happens just the same without iTunes.
> Only happens when transcoding is switched on, either for http streaming
> or for hardware clients. Seems like every other request to the
> slimserver stalls (sometimes it is the web page, sometimes it is just
> the album art).
>
> Do you get the following in your server debug when transcoding is on and
> you change tunes?
> Error writing mp3 output
> ID3v2 found. Be aware that the ID3 tag is currently lost when transcoding.
> Input file is freeformat.
>
> The web page problem is 100% reproduceable on handheld skin on my
> system, but happens infrequently on other skins liek default.
>
> (upgraded to latest lame.exe version and ensured it is in server/bin/
> directory)
>
> Cheers
>
>

John Gorst
2004-04-23, 01:50
kdf wrote:
> IO have managed to see the same thing, but so far only with SoftSqueeze. Winamp
> doesn't show the problem, and I am not near a Squeezebox right now.
>
> -kdf

Should I file a bug report about this? Haven't done so far as I wasn't
completely sure it wasnt just my configuration.

Cheers

kdf
2004-04-23, 03:53
go for it.
-kdf
Quoting John Gorst <john_gorst (AT) hotmail (DOT) com>:

> kdf wrote:
> > IO have managed to see the same thing, but so far only with SoftSqueeze.
> Winamp
> > doesn't show the problem, and I am not near a Squeezebox right now.
> >
> > -kdf
>
> Should I file a bug report about this? Haven't done so far as I wasn't
> completely sure it wasnt just my configuration.
>
> Cheers
>
>