PDA

View Full Version : Three glitches playing decompressed FLACs



Jason Holtzapple
2004-01-04, 13:03
--- "Mark A. Aiken" <mark_aiken (AT) hotmail (DOT) com> wrote:
> I'm a new Squeezebox owner and just got my box up and running. My music
> collection is in FLAC, and I tweaked convert.conf so the FLAC files get
> expanded to WAV and then streamed straight to the Squeezebox (instead of
> getting crunched to MP3 first). The one and only entry in my convert.conf
> that mentions FLAC now looks like this:

Issue #2 is fixed in the nightly builds:

http://www.slimdevices.com/downloads/nightly/latest/

Issue #1 is being looked at, but I'm not sure what
the status is. I don't know about #3. In the nightly
build, you can change the progress display on the
Squeezebox into a display showing the player's
buffer. You might enable that (under Performance)
and see if it is a buffer starvation problem.

--Jason

__________________________________
Do you Yahoo!?
Find out what made the Top Yahoo! Searches of 2003
http://search.yahoo.com/top2003

Mark A. Aiken
2004-01-04, 15:57
Thank you very much for the quick reply, on a Sunday no less!

I am happy to say that the nightly build seems to have fixed both the
popping issue and the time-counting issue, although it seems to have come
with its own glitches, and I have some new data on the droupouts.

The new glitches are:

- Intermittently, the Squeezebox, when starting a new track or resuming
after being paused, will start counting elapsed time, but no sound comes
out. Starting the track over again always seems to kick it into gear.

- The Squeezebox counts elapsed time while paused.

The new data on dropouts is this: I turned on the buffer-fullness
display and tried various things to get the Squeezebox to stutter, and
found, much to my surprise, that each HTTP hit to the Slimserver from my
wireless laptop visibly affects the Squeezebox's buffer. If I refresh the
web interface quickly enough, the Squeezebox's buffer empties and it pauses.
When the Squeezebox gets near the end of a track, the rapid-refresh of the
web interface will sometimes cause the box to stutter all by itself.

This was so surprising that I went to see what was going on on the
server when I hit the web interface. I discovered that hitting the
Slimserver's web interface repeatedly was pegging out the 2GHz Pentium in my
server machine. This seems worth looking into! The Squeezebox seems to fare
fine when my server is heavily loaded by other processes; is the
web-servicing logic not on a separate thread from the data pump? The heavy
CPU load seems to come when rendering the Playlist portion.

As a side issue, how much buffer is in the Squeezebox, anyway? I would
have expected at least a few seconds' worth of uncompressed audio (I guess
that would be between 500K and 1MB), but the delay between the server's CPU
pegging out and the Squeezebox pausing seems very short -- at most a second.

Many thanks for the help,

Mark

----- Original Message -----
From: "Jason Holtzapple" <jasonholtzapple (AT) yahoo (DOT) com>
To: "Slim Devices Discussion" <discuss (AT) lists (DOT) slimdevices.com>
Sent: Sunday, January 04, 2004 12:03 PM
Subject: [slim] Three glitches playing decompressed FLACs


> --- "Mark A. Aiken" <mark_aiken (AT) hotmail (DOT) com> wrote:
> > I'm a new Squeezebox owner and just got my box up and running. My
music
> > collection is in FLAC, and I tweaked convert.conf so the FLAC files get
> > expanded to WAV and then streamed straight to the Squeezebox (instead of
> > getting crunched to MP3 first). The one and only entry in my
convert.conf
> > that mentions FLAC now looks like this:
>
> Issue #2 is fixed in the nightly builds:
>
> http://www.slimdevices.com/downloads/nightly/latest/
>
> Issue #1 is being looked at, but I'm not sure what
> the status is. I don't know about #3. In the nightly
> build, you can change the progress display on the
> Squeezebox into a display showing the player's
> buffer. You might enable that (under Performance)
> and see if it is a buffer starvation problem.
>
> --Jason
>
> __________________________________
> Do you Yahoo!?
> Find out what made the Top Yahoo! Searches of 2003
> http://search.yahoo.com/top2003
>

Dan Sully
2004-01-04, 23:58
* Mark A. Aiken <mark_aiken (AT) hotmail (DOT) com> shaped the electrons to say...

> - Intermittently, the Squeezebox, when starting a new track or resuming
> after being paused, will start counting elapsed time, but no sound comes
> out. Starting the track over again always seems to kick it into gear.

I'm not exactly sure what's happening here, but it might be related to below.

> - The Squeezebox counts elapsed time while paused.
>
> The new data on dropouts is this: I turned on the buffer-fullness
> display and tried various things to get the Squeezebox to stutter, and
> found, much to my surprise, that each HTTP hit to the Slimserver from my
> wireless laptop visibly affects the Squeezebox's buffer. If I refresh the
> web interface quickly enough, the Squeezebox's buffer empties and it pauses.
> When the Squeezebox gets near the end of a track, the rapid-refresh of the
> web interface will sometimes cause the box to stutter all by itself.
>
> This was so surprising that I went to see what was going on on the
> server when I hit the web interface. I discovered that hitting the
> Slimserver's web interface repeatedly was pegging out the 2GHz Pentium in my
> server machine. This seems worth looking into! The Squeezebox seems to fare
> fine when my server is heavily loaded by other processes; is the
> web-servicing logic not on a separate thread from the data pump? The heavy
> CPU load seems to come when rendering the Playlist portion.

All of the above will be fixed in tonight's nightly build.

-D
--
Cracking toast Gromit!

Mark A. Aiken
2004-01-05, 12:28
I installed the 1/5 nightly (which included a firmware update) and I
find that hitting the web interface still pegs my CPU. The excessive
processing definitely seems related to rendering the playlist; all portions
of the web interface except for the playlist will render immediately, and if
the playlist is long, the CPU will peg for a short while; when it drops off,
the playlist gets rendered. I'm hosting on Windows.

I also find that the elapsed-time display is corrupt: it always displays
an enormous number.

Mark

----- Original Message -----
From: "Dan Sully" <daniel (AT) electricrain (DOT) com>
To: "Slim Devices Discussion" <discuss (AT) lists (DOT) slimdevices.com>
Sent: Sunday, January 04, 2004 10:58 PM
Subject: [slim] Three glitches playing decompressed FLACs


> * Mark A. Aiken <mark_aiken (AT) hotmail (DOT) com> shaped the electrons to say...
>
> > - Intermittently, the Squeezebox, when starting a new track or
resuming
> > after being paused, will start counting elapsed time, but no sound comes
> > out. Starting the track over again always seems to kick it into gear.
>
> I'm not exactly sure what's happening here, but it might be related to
below.
>
> > - The Squeezebox counts elapsed time while paused.
> >
> > The new data on dropouts is this: I turned on the buffer-fullness
> > display and tried various things to get the Squeezebox to stutter, and
> > found, much to my surprise, that each HTTP hit to the Slimserver from my
> > wireless laptop visibly affects the Squeezebox's buffer. If I refresh
the
> > web interface quickly enough, the Squeezebox's buffer empties and it
pauses.
> > When the Squeezebox gets near the end of a track, the rapid-refresh of
the
> > web interface will sometimes cause the box to stutter all by itself.
> >
> > This was so surprising that I went to see what was going on on the
> > server when I hit the web interface. I discovered that hitting the
> > Slimserver's web interface repeatedly was pegging out the 2GHz Pentium
in my
> > server machine. This seems worth looking into! The Squeezebox seems to
fare
> > fine when my server is heavily loaded by other processes; is the
> > web-servicing logic not on a separate thread from the data pump? The
heavy
> > CPU load seems to come when rendering the Playlist portion.
>
> All of the above will be fixed in tonight's nightly build.
>
> -D
> --
> Cracking toast Gromit!
>

dean
2004-01-05, 12:36
Hi Mark:

Some questions...

On Jan 5, 2004, at 11:28 AM, Mark A. Aiken wrote:

> I installed the 1/5 nightly (which included a firmware update) and
> I
> find that hitting the web interface still pegs my CPU. The excessive
> processing definitely seems related to rendering the playlist; all
> portions
> of the web interface except for the playlist will render immediately,
> and if
> the playlist is long, the CPU will peg for a short while; when it
> drops off,
> the playlist gets rendered. I'm hosting on Windows.
What skin are you using? How big is your library? How big is the
playlist you are trying to render? What are the specs of the machine
are you using? What version of Windows?

>
> I also find that the elapsed-time display is corrupt: it always
> displays
> an enormous number.
Is this for every song or just some songs? What formats are the songs
in?

-dean

> ----- Original Message -----
> From: "Dan Sully" <daniel (AT) electricrain (DOT) com>
> To: "Slim Devices Discussion" <discuss (AT) lists (DOT) slimdevices.com>
> Sent: Sunday, January 04, 2004 10:58 PM
> Subject: [slim] Three glitches playing decompressed FLACs
>
>
>> * Mark A. Aiken <mark_aiken (AT) hotmail (DOT) com> shaped the electrons to
>> say...
>>
>>> - Intermittently, the Squeezebox, when starting a new track or
> resuming
>>> after being paused, will start counting elapsed time, but no sound
>>> comes
>>> out. Starting the track over again always seems to kick it into gear.
>>
>> I'm not exactly sure what's happening here, but it might be related to
> below.
>>
>>> - The Squeezebox counts elapsed time while paused.
>>>
>>> The new data on dropouts is this: I turned on the buffer-fullness
>>> display and tried various things to get the Squeezebox to stutter,
>>> and
>>> found, much to my surprise, that each HTTP hit to the Slimserver
>>> from my
>>> wireless laptop visibly affects the Squeezebox's buffer. If I refresh
> the
>>> web interface quickly enough, the Squeezebox's buffer empties and it
> pauses.
>>> When the Squeezebox gets near the end of a track, the rapid-refresh
>>> of
> the
>>> web interface will sometimes cause the box to stutter all by itself.
>>>
>>> This was so surprising that I went to see what was going on on
>>> the
>>> server when I hit the web interface. I discovered that hitting the
>>> Slimserver's web interface repeatedly was pegging out the 2GHz
>>> Pentium
> in my
>>> server machine. This seems worth looking into! The Squeezebox seems
>>> to
> fare
>>> fine when my server is heavily loaded by other processes; is the
>>> web-servicing logic not on a separate thread from the data pump? The
> heavy
>>> CPU load seems to come when rendering the Playlist portion.
>>
>> All of the above will be fixed in tonight's nightly build.
>>
>> -D
>> --
>> Cracking toast Gromit!
>>

Mark A. Aiken
2004-01-05, 13:32
Answers:

- Playing around some more, I have discovered that the CPU-pegging
effect occurs even if the playlist is *empty*. But it always seems to
coincide with rendering the playlist portion of the display.

- I am using the default skin
- My library is small -- the top-level menu reports "75 albums with 1046
songs by 109 artists".
- My machine is a Dell Dimension 4550. That's a 2GHz P4. It has 640MB of
RAM and my songs are on a Maxtor 160GB drive driven by an add-on Ultra-ATA
controller.
- I'm running WinXP, Home Edition, "Version 2002" (whatever that means).
I think I have both SP1 and SP2 installed.
- I'm running the SlimServer as a service. slimsvc.exe is the process
that consumes all the CPU when I refresh the web interface.

- The huge-number elapsed-time display happens for all FLAC files I have
tried. It doesn't seem to happen for MP3s. After restarting the SlimServer,
I was just getting zero for the elapsed time for a little while. I'm not
sure what caused the swichover, but once I start seeing the huge number for
FLAC elapsed-time, it doesn't go away.

I'm also still seeing the issue where the SB won't play a track. In
fact, it's gotten worse; a few times, the SB has gotten into a state where
it won't play any track correctly. I haven't been able to figure out what
makes it start working again; after trying several different tracks, it will
fall back into line again.

Mark

----- Original Message -----
From: "dean blackketter" <dean (AT) slimdevices (DOT) com>
To: "Slim Devices Discussion" <discuss (AT) lists (DOT) slimdevices.com>
Sent: Monday, January 05, 2004 11:36 AM
Subject: [slim] Three glitches playing decompressed FLACs


> Hi Mark:
>
> Some questions...
>
> On Jan 5, 2004, at 11:28 AM, Mark A. Aiken wrote:
>
> > I installed the 1/5 nightly (which included a firmware update) and
> > I
> > find that hitting the web interface still pegs my CPU. The excessive
> > processing definitely seems related to rendering the playlist; all
> > portions
> > of the web interface except for the playlist will render immediately,
> > and if
> > the playlist is long, the CPU will peg for a short while; when it
> > drops off,
> > the playlist gets rendered. I'm hosting on Windows.
> What skin are you using? How big is your library? How big is the
> playlist you are trying to render? What are the specs of the machine
> are you using? What version of Windows?
>
> >
> > I also find that the elapsed-time display is corrupt: it always
> > displays
> > an enormous number.
> Is this for every song or just some songs? What formats are the songs
> in?
>
> -dean
>
> > ----- Original Message -----
> > From: "Dan Sully" <daniel (AT) electricrain (DOT) com>
> > To: "Slim Devices Discussion" <discuss (AT) lists (DOT) slimdevices.com>
> > Sent: Sunday, January 04, 2004 10:58 PM
> > Subject: [slim] Three glitches playing decompressed FLACs
> >
> >
> >> * Mark A. Aiken <mark_aiken (AT) hotmail (DOT) com> shaped the electrons to
> >> say...
> >>
> >>> - Intermittently, the Squeezebox, when starting a new track or
> > resuming
> >>> after being paused, will start counting elapsed time, but no sound
> >>> comes
> >>> out. Starting the track over again always seems to kick it into gear.
> >>
> >> I'm not exactly sure what's happening here, but it might be related to
> > below.
> >>
> >>> - The Squeezebox counts elapsed time while paused.
> >>>
> >>> The new data on dropouts is this: I turned on the buffer-fullness
> >>> display and tried various things to get the Squeezebox to stutter,
> >>> and
> >>> found, much to my surprise, that each HTTP hit to the Slimserver
> >>> from my
> >>> wireless laptop visibly affects the Squeezebox's buffer. If I refresh
> > the
> >>> web interface quickly enough, the Squeezebox's buffer empties and it
> > pauses.
> >>> When the Squeezebox gets near the end of a track, the rapid-refresh
> >>> of
> > the
> >>> web interface will sometimes cause the box to stutter all by itself.
> >>>
> >>> This was so surprising that I went to see what was going on on
> >>> the
> >>> server when I hit the web interface. I discovered that hitting the
> >>> Slimserver's web interface repeatedly was pegging out the 2GHz
> >>> Pentium
> > in my
> >>> server machine. This seems worth looking into! The Squeezebox seems
> >>> to
> > fare
> >>> fine when my server is heavily loaded by other processes; is the
> >>> web-servicing logic not on a separate thread from the data pump? The
> > heavy
> >>> CPU load seems to come when rendering the Playlist portion.
> >>
> >> All of the above will be fixed in tonight's nightly build.
> >>
> >> -D
> >> --
> >> Cracking toast Gromit!
> >>

seanadams
2004-01-05, 13:54
>
>
> I'm also still seeing the issue where the SB won't play a track. In
> fact, it's gotten worse; a few times, the SB has gotten into a state
> where
> it won't play any track correctly. I haven't been able to figure out
> what
> makes it start working again; after trying several different tracks,
> it will
> fall back into line again.

Let me know if you still get this with the new firmware. I'm not sure
if it's specific to FLAC. If you still get it in a state where it won't
play a PCM track, try playing an MP3 track and then another PCM track.

Mark A. Aiken
2004-01-05, 14:00
Well, note that I sent my email after I experimented with the new
firmware, so I have definitely seen this problem with the new firmware.

I'll try to get the SB back into this state, and then play an MP3 to see
if that helps.

Mark

----- Original Message -----
From: "Sean Adams" <sadams (AT) slimdevices (DOT) com>
To: "Slim Devices Discussion" <discuss (AT) lists (DOT) slimdevices.com>
Sent: Monday, January 05, 2004 12:54 PM
Subject: [slim] Three glitches playing decompressed FLACs


> >
> >
> > I'm also still seeing the issue where the SB won't play a track. In
> > fact, it's gotten worse; a few times, the SB has gotten into a state
> > where
> > it won't play any track correctly. I haven't been able to figure out
> > what
> > makes it start working again; after trying several different tracks,
> > it will
> > fall back into line again.
>
> Let me know if you still get this with the new firmware. I'm not sure
> if it's specific to FLAC. If you still get it in a state where it won't
> play a PCM track, try playing an MP3 track and then another PCM track.
>
>

seanadams
2004-01-07, 09:01
At the time I sent my email, there was one change that was in CVS but
not yet in the nightly build.


On Jan 5, 2004, at 1:00 PM, Mark A. Aiken wrote:

> Well, note that I sent my email after I experimented with the new
> firmware, so I have definitely seen this problem with the new firmware.
>
> I'll try to get the SB back into this state, and then play an MP3
> to see
> if that helps.
>
> Mark
>
> ----- Original Message -----
> From: "Sean Adams" <sadams (AT) slimdevices (DOT) com>
> To: "Slim Devices Discussion" <discuss (AT) lists (DOT) slimdevices.com>
> Sent: Monday, January 05, 2004 12:54 PM
> Subject: [slim] Three glitches playing decompressed FLACs
>
>
>>>
>>>
>>> I'm also still seeing the issue where the SB won't play a track.
>>> In
>>> fact, it's gotten worse; a few times, the SB has gotten into a state
>>> where
>>> it won't play any track correctly. I haven't been able to figure out
>>> what
>>> makes it start working again; after trying several different tracks,
>>> it will
>>> fall back into line again.
>>
>> Let me know if you still get this with the new firmware. I'm not sure
>> if it's specific to FLAC. If you still get it in a state where it
>> won't
>> play a PCM track, try playing an MP3 track and then another PCM track.
>>
>>

Mark A. Aiken
2004-01-07, 09:16
http://www.slimdevices.com/downloads/nightly/latest/

doesn't seem to currently offer a Win32 .exe installer, as I have found
there in the past. There is still a UNIX tarball, though. Recent change?
Build failure last night? How should I install for Win32?

Mark

----- Original Message -----
From: "Sean Adams" <sadams (AT) slimdevices (DOT) com>
To: "Slim Devices Discussion" <discuss (AT) lists (DOT) slimdevices.com>
Sent: Wednesday, January 07, 2004 8:01 AM
Subject: [slim] Three glitches playing decompressed FLACs


>
> At the time I sent my email, there was one change that was in CVS but
> not yet in the nightly build.
>
>
> On Jan 5, 2004, at 1:00 PM, Mark A. Aiken wrote:
>
> > Well, note that I sent my email after I experimented with the new
> > firmware, so I have definitely seen this problem with the new firmware.
> >
> > I'll try to get the SB back into this state, and then play an MP3
> > to see
> > if that helps.
> >
> > Mark
> >
> > ----- Original Message -----
> > From: "Sean Adams" <sadams (AT) slimdevices (DOT) com>
> > To: "Slim Devices Discussion" <discuss (AT) lists (DOT) slimdevices.com>
> > Sent: Monday, January 05, 2004 12:54 PM
> > Subject: [slim] Three glitches playing decompressed FLACs
> >
> >
> >>>
> >>>
> >>> I'm also still seeing the issue where the SB won't play a track.
> >>> In
> >>> fact, it's gotten worse; a few times, the SB has gotten into a state
> >>> where
> >>> it won't play any track correctly. I haven't been able to figure out
> >>> what
> >>> makes it start working again; after trying several different tracks,
> >>> it will
> >>> fall back into line again.
> >>
> >> Let me know if you still get this with the new firmware. I'm not sure
> >> if it's specific to FLAC. If you still get it in a state where it
> >> won't
> >> play a PCM track, try playing an MP3 track and then another PCM track.
> >>
> >>

kdf
2004-01-08, 05:39
Quoting "Mark A. Aiken" <mark_aiken (AT) hotmail (DOT) com>:

> http://www.slimdevices.com/downloads/nightly/latest/
>
> doesn't seem to currently offer a Win32 .exe installer, as I have found
> there in the past. There is still a UNIX tarball, though. Recent change?
> Build failure last night? How should I install for Win32?
>
> Mark
the build is sometimes delayed. go up into nightly, then pick a date. start
with yesterday and work back.

-kdf

dean
2004-01-08, 08:49
Sorry, we've all been at MacWorld, including one of our build servers!
I'm running the nightlys now, expect them up in a few minutes.

-dean

On Jan 7, 2004, at 8:16 AM, Mark A. Aiken wrote:

> http://www.slimdevices.com/downloads/nightly/latest/
>
> doesn't seem to currently offer a Win32 .exe installer, as I have
> found
> there in the past. There is still a UNIX tarball, though. Recent
> change?
> Build failure last night? How should I install for Win32?
>
> Mark
>
> ----- Original Message -----
> From: "Sean Adams" <sadams (AT) slimdevices (DOT) com>
> To: "Slim Devices Discussion" <discuss (AT) lists (DOT) slimdevices.com>
> Sent: Wednesday, January 07, 2004 8:01 AM
> Subject: [slim] Three glitches playing decompressed FLACs
>
>
>>
>> At the time I sent my email, there was one change that was in CVS but
>> not yet in the nightly build.
>>
>>
>> On Jan 5, 2004, at 1:00 PM, Mark A. Aiken wrote:
>>
>>> Well, note that I sent my email after I experimented with the new
>>> firmware, so I have definitely seen this problem with the new
>>> firmware.
>>>
>>> I'll try to get the SB back into this state, and then play an MP3
>>> to see
>>> if that helps.
>>>
>>> Mark
>>>
>>> ----- Original Message -----
>>> From: "Sean Adams" <sadams (AT) slimdevices (DOT) com>
>>> To: "Slim Devices Discussion" <discuss (AT) lists (DOT) slimdevices.com>
>>> Sent: Monday, January 05, 2004 12:54 PM
>>> Subject: [slim] Three glitches playing decompressed FLACs
>>>
>>>
>>>>>
>>>>>
>>>>> I'm also still seeing the issue where the SB won't play a
>>>>> track.
>>>>> In
>>>>> fact, it's gotten worse; a few times, the SB has gotten into a
>>>>> state
>>>>> where
>>>>> it won't play any track correctly. I haven't been able to figure
>>>>> out
>>>>> what
>>>>> makes it start working again; after trying several different
>>>>> tracks,
>>>>> it will
>>>>> fall back into line again.
>>>>
>>>> Let me know if you still get this with the new firmware. I'm not
>>>> sure
>>>> if it's specific to FLAC. If you still get it in a state where it
>>>> won't
>>>> play a PCM track, try playing an MP3 track and then another PCM
>>>> track.
>>>>
>>>>

Mark A. Aiken
2004-01-08, 22:49
I just stepped up to the 1/8 nightly build, and refreshing the web
interface still pegs out my CPU for a couple seconds.

Again, this definitely seems related to rendering the playlist portion
of the web interface; occasionally, that pane won't load at all, and IE will
show a "Could not load this page" message there, whereas the rest of the
page is fine.

This happens even with an empty playlist. I'm using the default skin. I
can't imagine this would be too hard to repro on a Windows box; let me know
if I can help. The fact that the CPU pegs out causes the SB to skip, as
described below.

Mark

----- Original Message -----
From: "Dan Sully" <daniel (AT) electricrain (DOT) com>
To: "Slim Devices Discussion" <discuss (AT) lists (DOT) slimdevices.com>
Sent: Sunday, January 04, 2004 10:58 PM
Subject: [slim] Three glitches playing decompressed FLACs


> * Mark A. Aiken <mark_aiken (AT) hotmail (DOT) com> shaped the electrons to say...
>
> > - Intermittently, the Squeezebox, when starting a new track or
resuming
> > after being paused, will start counting elapsed time, but no sound comes
> > out. Starting the track over again always seems to kick it into gear.
>
> I'm not exactly sure what's happening here, but it might be related to
below.
>
> > - The Squeezebox counts elapsed time while paused.
> >
> > The new data on dropouts is this: I turned on the buffer-fullness
> > display and tried various things to get the Squeezebox to stutter, and
> > found, much to my surprise, that each HTTP hit to the Slimserver from my
> > wireless laptop visibly affects the Squeezebox's buffer. If I refresh
the
> > web interface quickly enough, the Squeezebox's buffer empties and it
pauses.
> > When the Squeezebox gets near the end of a track, the rapid-refresh of
the
> > web interface will sometimes cause the box to stutter all by itself.
> >
> > This was so surprising that I went to see what was going on on the
> > server when I hit the web interface. I discovered that hitting the
> > Slimserver's web interface repeatedly was pegging out the 2GHz Pentium
in my
> > server machine. This seems worth looking into! The Squeezebox seems to
fare
> > fine when my server is heavily loaded by other processes; is the
> > web-servicing logic not on a separate thread from the data pump? The
heavy
> > CPU load seems to come when rendering the Playlist portion.
>
> All of the above will be fixed in tonight's nightly build.
>
> -D
> --
> Cracking toast Gromit!
>

Dan Sully
2004-01-08, 22:51
* Mark A. Aiken <mark_aiken (AT) hotmail (DOT) com> shaped the electrons to say...

> I just stepped up to the 1/8 nightly build, and refreshing the web
> interface still pegs out my CPU for a couple seconds.
>
> Again, this definitely seems related to rendering the playlist portion
> of the web interface; occasionally, that pane won't load at all, and IE will
> show a "Could not load this page" message there, whereas the rest of the
> page is fine.
>
> This happens even with an empty playlist. I'm using the default skin. I
> can't imagine this would be too hard to repro on a Windows box; let me know
> if I can help. The fact that the CPU pegs out causes the SB to skip, as
> described below.

Mark - what does the output of slimserver with --d_source show?

-D
--
God, root, what is difference?

Mark A. Aiken
2004-01-08, 23:43
This set of three lines shows up each time I refresh:

Use of uninitialized value in concatenation (.) or string at
/PerlApp/Slim/Player/Source.pm line 182.
Use of uninitialized value in concatenation (.) or string at
/PerlApp/Slim/Player/Source.pm line 182.
2004-01-08 22:37:55.8782 songTime: [0] = (1249328930(realpos) / 0(size) *
(duration) * 1(rate)) + (time offset of started stream)

However, they show up immediately, then my CPU pegs, and no further
output seems to correspond to the CPU dropping off again after a second or
two.

Should I try something else?

Mark

----- Original Message -----
From: "Dan Sully" <daniel (AT) electricrain (DOT) com>
To: "Mark A. Aiken" <mark_aiken (AT) hotmail (DOT) com>
Cc: "Slim Devices Discussion" <discuss (AT) lists (DOT) slimdevices.com>
Sent: Thursday, January 08, 2004 9:51 PM
Subject: [slim] Three glitches playing decompressed FLACs


> * Mark A. Aiken <mark_aiken (AT) hotmail (DOT) com> shaped the electrons to say...
>
> > I just stepped up to the 1/8 nightly build, and refreshing the web
> > interface still pegs out my CPU for a couple seconds.
> >
> > Again, this definitely seems related to rendering the playlist
portion
> > of the web interface; occasionally, that pane won't load at all, and IE
will
> > show a "Could not load this page" message there, whereas the rest of the
> > page is fine.
> >
> > This happens even with an empty playlist. I'm using the default
skin. I
> > can't imagine this would be too hard to repro on a Windows box; let me
know
> > if I can help. The fact that the CPU pegs out causes the SB to skip, as
> > described below.
>
> Mark - what does the output of slimserver with --d_source show?
>
> -D
> --
> God, root, what is difference?
>

Dan Sully
2004-01-08, 23:51
* Mark A. Aiken <mark_aiken (AT) hotmail (DOT) com> shaped the electrons to say...

> This set of three lines shows up each time I refresh:
>
> Use of uninitialized value in concatenation (.) or string at
> /PerlApp/Slim/Player/Source.pm line 182.
> Use of uninitialized value in concatenation (.) or string at
> /PerlApp/Slim/Player/Source.pm line 182.
> 2004-01-08 22:37:55.8782 songTime: [0] = (1249328930(realpos) / 0(size) *
> (duration) * 1(rate)) + (time offset of started stream)
>
> However, they show up immediately, then my CPU pegs, and no further
> output seems to correspond to the CPU dropping off again after a second or
> two.
>
> Should I try something else?

Ok - there is no offset being calculated for this file. What type of file is it?

Can you run with --d_info as well?

You said you were using the latest nightly?

-D
--
They're techno trousers, ex-NASA, fantastic for walkies!

kdf
2004-01-09, 00:25
Quoting Dan Sully <daniel (AT) electricrain (DOT) com>:

> * Mark A. Aiken <mark_aiken (AT) hotmail (DOT) com> shaped the electrons to say...
>
> > This set of three lines shows up each time I refresh:
> >
> > Use of uninitialized value in concatenation (.) or string at
> > /PerlApp/Slim/Player/Source.pm line 182.
> > Use of uninitialized value in concatenation (.) or string at
> > /PerlApp/Slim/Player/Source.pm line 182.
> > 2004-01-08 22:37:55.8782 songTime: [0] = (1249328930(realpos) / 0(size) *
> > (duration) * 1(rate)) + (time offset of started stream)
> >
> > However, they show up immediately, then my CPU pegs, and no further
> > output seems to correspond to the CPU dropping off again after a second or
> > two.
> >
> > Should I try something else?
>
> Ok - there is no offset being calculated for this file. What type of file is
> it?

no $duration either. I see the same thing with the latest nightly, although my
browser refresh is fine. I think this is only happening because there is no
currentSong. Once a song is played and stopped, those messages stop.

-kdf

Mark A. Aiken
2004-01-09, 10:58
Indeed, I get that line when there is no current song in the playlist.
When I run with --d_info and --d_source, the first thing I notice is that
the SlimServer is rescanning my entire music collection when it starts up.
There was a separate question about this, too, from another user -- what is
the fix for Windows?

After that nonsense, I get the previously mentioned output for an empty
playlist, and the following output for a playlist consisting of only one
track:

2004-01-09 09:55:27.3932 Cover Art (thumb) for: E:\music\Various\Blues
Summit\11 - I Gotta Move Out Of This Neighborhood.flac
2004-01-09 09:55:27.3932 Updating image for E:\music\Various\Blues
Summit\11 - I Gotta Move Out Of This Neighborhood.flac
2004-01-09 09:55:27 32004-01-09 09:55:27.3932 Looking for image files
2004-01-09 09:55:27.3932 Couldn't open image E:\music\Various\Blues
Summit\thumb.jpg
2004-01-09 09:55:27.3932 Couldn't open image E:\music\Various\Blues
Summit\albumartsmall.jpg
2004-01-09 09:55:27.3932 Couldn't open image E:\music\Various\Blues
Summit\cover.jpg
2004-01-09 09:55:27.4088 Couldn't open image E:\music\Various\Blues
Summit\folder.jpg
2004-01-09 09:55:27.4088 Couldn't open image E:\music\Various\Blues
Summit\album.jpg
2004-01-09 09:55:27.4088 merging E:\music\Various\Blues Summit\11 - I Gotta
Move Out Of This Neighborhood.flac
2004-01-09 09:55:27.4088 updating E:\music\Various\Blues Summit\11 - I Gotta
Move Out Of This Neighborhood.flac with flc for CT
2004-01-09 09:55:27.4088 updating E:\music\Various\Blues Summit\11 - I Gotta
Move Out Of This Neighborhood.flac with I Gotta Move Out Of This
Neighborhood for T
ITLE
2004-01-09 09:55:27.4088 updating E:\music\Various\Blues Summit\11 - I Gotta
Move Out Of This Neighborhood.flac with 1073282748 for AGE
2004-01-09 09:55:27.4088 updating E:\music\Various\Blues Summit\11 - I Gotta
Move Out Of This Neighborhood.flac with Blues for GENRE
2004-01-09 09:55:27.4088 updating E:\music\Various\Blues Summit\11 - I Gotta
Move Out Of This Neighborhood.flac with 11 for TRACKNUM
2004-01-09 09:55:27.4088 updating E:\music\Various\Blues Summit\11 - I Gotta
Move Out Of This Neighborhood.flac with 55755669 for FS
2004-01-09 09:55:27.4088 updating E:\music\Various\Blues Summit\11 - I Gotta
Move Out Of This Neighborhood.flac with 55755669 for SIZE
2004-01-09 09:55:27.4088 updating E:\music\Various\Blues Summit\11 - I Gotta
Move Out Of This Neighborhood.flac with 5278 for OFFSET
2004-01-09 09:55:27.4088 updating E:\music\Various\Blues Summit\11 - I Gotta
Move Out Of This Neighborhood.flac with B.B King for ARTIST
2004-01-09 09:55:27.4088 updating E:\music\Various\Blues Summit\11 - I Gotta
Move Out Of This Neighborhood.flac with Blues Summit for ALBUM
2004-01-09 09:55:27.4088 updating E:\music\Various\Blues Summit\11 - I Gotta
Move Out Of This Neighborhood.flac with 1993 for YEAR
2004-01-09 09:55:27.4088 updating E:\music\Various\Blues Summit\11 - I Gotta
Move Out Of This Neighborhood.flac with 537.666666666667 for SECS
2004-01-09 09:55:27.4088 updating E:\music\Various\Blues Summit\11 - I Gotta
Move Out Of This Neighborhood.flac with 829.516047117173 for BITRATE
2004-01-09 09:55:27.4088 updating E:\music\Various\Blues Summit\11 - I Gotta
Move Out Of This Neighborhood.flac with 1 for TAG
2004-01-09 09:55:27.4088 updating E:\music\Various\Blues Summit\11 - I Gotta
Move Out Of This Neighborhood.flac with 44100 for RATE
2004-01-09 09:55:27.4088 updating E:\music\Various\Blues Summit\11 - I Gotta
Move Out Of This Neighborhood.flac with 2 for CHANNELS

...but again, since I get the major CPU usage even when the playlist is
empty, my guess is that the work that gets done on each song in the playlist
is not the culprit here...

In other news, the elapsed-time display on my SB is now no longer a huge
number when playing FLAC files, but instead, after a brief period of
appearing to be correct, it is now smallish negative numbers. :-(

Mark

----- Original Message -----
From: "kdf" <slim-mail (AT) deane-freeman (DOT) com>
To: "Slim Devices Discussion" <discuss (AT) lists (DOT) slimdevices.com>
Sent: Thursday, January 08, 2004 11:25 PM
Subject: [slim] Three glitches playing decompressed FLACs


> Quoting Dan Sully <daniel (AT) electricrain (DOT) com>:
>
> > * Mark A. Aiken <mark_aiken (AT) hotmail (DOT) com> shaped the electrons to say...
> >
> > > This set of three lines shows up each time I refresh:
> > >
> > > Use of uninitialized value in concatenation (.) or string at
> > > /PerlApp/Slim/Player/Source.pm line 182.
> > > Use of uninitialized value in concatenation (.) or string at
> > > /PerlApp/Slim/Player/Source.pm line 182.
> > > 2004-01-08 22:37:55.8782 songTime: [0] = (1249328930(realpos) /
0(size) *
> > > (duration) * 1(rate)) + (time offset of started stream)
> > >
> > > However, they show up immediately, then my CPU pegs, and no
further
> > > output seems to correspond to the CPU dropping off again after a
second or
> > > two.
> > >
> > > Should I try something else?
> >
> > Ok - there is no offset being calculated for this file. What type of
file is
> > it?
>
> no $duration either. I see the same thing with the latest nightly,
although my
> browser refresh is fine. I think this is only happening because there is
no
> currentSong. Once a song is played and stopped, those messages stop.
>
> -kdf
>

kdf
2004-01-09, 11:22
Quoting "Mark A. Aiken" <mark_aiken (AT) hotmail (DOT) com>:


> After that nonsense, I get the previously mentioned output for an empty
> playlist, and the following output for a playlist consisting of only one
> track:

One possibility came to my attention last night. Do you have cover art for your
songs? I recently found a bug where if the cover art is not found, the value
being stored in the cache to indicate no cover art ('0') is being dropped. Thus
the server thinks the file is new and it updates the cache. This should not be
overloading your cpu as much as you are getting, but it will certainly cause
unnecessary work.

-kdf

Mark A. Aiken
2004-01-09, 11:36
Hmm; I don't have any cover art; when did this bugfix go into source
control?

Mark

----- Original Message -----
From: "kdf" <slim-mail (AT) deane-freeman (DOT) com>
To: "Slim Devices Discussion" <discuss (AT) lists (DOT) slimdevices.com>
Sent: Friday, January 09, 2004 10:22 AM
Subject: [slim] Three glitches playing decompressed FLACs


> Quoting "Mark A. Aiken" <mark_aiken (AT) hotmail (DOT) com>:
>
>
> > After that nonsense, I get the previously mentioned output for an
empty
> > playlist, and the following output for a playlist consisting of only one
> > track:
>
> One possibility came to my attention last night. Do you have cover art
for your
> songs? I recently found a bug where if the cover art is not found, the
value
> being stored in the cache to indicate no cover art ('0') is being dropped.
Thus
> the server thinks the file is new and it updates the cache. This should
not be
> overloading your cpu as much as you are getting, but it will certainly
cause
> unnecessary work.
>
> -kdf
>

kdf
2004-01-09, 11:52
Quoting "Mark A. Aiken" <mark_aiken (AT) hotmail (DOT) com>:

> Hmm; I don't have any cover art; when did this bugfix go into source
> control?
>
no fix yet, I just entered it in the bug list this morning. There is an easy
fix (ie not using '0' and simply checking for the no-art value that we choose to
use). However, I want to figure out why '0' specifically gets dropped. Using
any other value or string works fine.

I have to have this fixed for the Browse-By-Cover feature, so it wont be long.

-kdf