PDA

View Full Version : Current errors



Beesley, S
2004-09-11, 11:27
I thought I would list all the errors I am now seeing. I have the latest build and firmware with a brand new SB (and latest graphic screen). I am using wireless mode. I have streaming limit set to 128K

1/ SB crashes if AP set to "both" authentication mode. Only works if set to Shared.
2/ On initial setup screen if displaying setup, wireless signal strength screen is blank
3/ When booted and connected there is a ? instead of a % on wireless signal screen
4/ Random and frequent dropouts. I have noticed that my buffer level is always between 99 and 100% when it drops out, after 1-2 seconds, it then continues playing and is immediately at 100%. If the signal had dropped, surely it should have kept playing until the buffer reached 0%. It seems that SB pauses even at 100% buffer if perhaps the network signal drops (or is there another reason)? Is the buffer actually working.
5/ When playing WMA (it's the only type I have), if the SB reboots (which it does frequently), the SB will try to resume where it left off playing. However, whilst the display is on the right song and the outstanding minutes/seconds position is correct, there is never any sound. I always have to forward or reverse and then it starts playing. Is this due to using LAME?
6/ Frequent reboots at random places (often playing or pressing to stop playing)
7/ Got stuck in a loop when searched for a song, the SB displayed a quick message to say that SB signal lost and then it said that song was not found. At this point it showed "a no songs of this name" type message and no key strokes would get me free. After a reboot, I was stuck at the same place. After several reboots, it freed up.
8/ DRM protected files wont play. I know this is a limitation. But can the SB display a message that the file is DRM protected and perhaps skip it or something?
9/ There is one more, but I can't think of it at the moment....

Sorry for the big list....

dean
2004-09-14, 14:13
Hi,

Thanks for the detailed feedback.

On Sep 11, 2004, at 11:27 AM, Beesley, S wrote:
> I thought I would list all the errors I am now seeing. I have the
> latest build and firmware with a brand new SB (and latest graphic
> screen). I am using wireless mode. I have streaming limit set to 128K
>
> 1/ SB crashes if AP set to "both" authentication mode. Only works
> if set to Shared.
What brand/model access point are you using?

> 2/ On initial setup screen if displaying setup, wireless signal
> strength screen is blank
That's a known bug in the current firmware. Sean's got a fix, but it
won't be updated until he's back next week.

> 3/ When booted and connected there is a ? instead of a % on
> wireless signal screen
Do you mean the Settings -> Information -> Player Settings screen? If
so, I don't see this.

> 4/ Random and frequent dropouts. I have noticed that my buffer
> level is always between 99 and 100% when it drops out, after 1-2
> seconds, it then continues playing and is immediately at 100%. If the
> signal had dropped, surely it should have kept playing until the
> buffer reached 0%. It seems that SB pauses even at 100% buffer if
> perhaps the network signal drops (or is there another reason)? Is the
> buffer actually working.
The buffer should be working, but there may be throughput issues on
your wireless network. If you temporarily connect via ethernet, is the
behavior better?

> 5/ When playing WMA (it's the only type I have), if the SB reboots
> (which it does frequently), the SB will try to resume where it left
> off playing. However, whilst the display is on the right song and the
> outstanding minutes/seconds position is correct, there is never any
> sound. I always have to forward or reverse and then it starts playing.
> Is this due to using LAME?
No, this is due to the fact that the player restarts and the server
doesn't try to restart the song after the player reconnects. The next
nightly build will have a fix that will cause the song to restart if
the player reboots.

> 6/ Frequent reboots at random places (often playing or pressing to
> stop playing)
Which version of SlimServer are you using? The frequent rebooting
issues should be largely resolved with the latest "nightly" build with
firmware version 37.

> 7/ Got stuck in a loop when searched for a song, the SB displayed a
> quick message to say that SB signal lost and then it said that song
> was not found. At this point it showed "a no songs of this name" type
> message and no key strokes would get me free. After a reboot, I was
> stuck at the same place. After several reboots, it freed up.
May be the same issue as above.

> 8/ DRM protected files wont play. I know this is a limitation. But
> can the SB display a message that the file is DRM protected and
> perhaps skip it or something?
Ah, this is a new one. I've filed a bug against this: 552.

> 9/ If I reboot my PC the SB happiliy reconnects OK. However, I turn
> my PC off at night for at least 8 hours. In the morning, my SB is
> complaingin that it has lost the connection to the SlimServer and it
> will not try to reconnect. A soft reboot and it reconnets. It seems to
> give up after a xx period of time. Could it be set to retyr or at
> least have a "press -> to retry" option on the display?
This is another known bug where sometimes if the player disconnects it
has trouble reconnecting. We're working on this.

Thanks for your patience,

dean

Beesley, S
2004-09-15, 14:34
>> 1/ SB crashes if AP set to "both" authentication mode. Only works if set
>> to Shared.
> What brand/model access point are you using?
USR 2249 (however, Sean thinks that the SB might be faulty.....)
>
>
>> 3/ When booted and connected there is a ? instead of a % on wireless
>> signal screen
> Do you mean the Settings -> Information -> Player Settings screen? If
> so, I don't see this.
yes - and this is what I see..

>
>> 4/ Random and frequent dropouts. I have noticed that my buffer level is
>> always between 99 and 100% when it drops out, after 1-2 seconds, it then
>> continues playing and is immediately at 100%. If the signal had dropped,
>> surely it should have kept playing until the buffer reached 0%. It seems
>> that SB pauses even at 100% buffer if perhaps the network signal drops
>> (or is there another reason)? Is the buffer actually working.
> The buffer should be working, but there may be throughput issues on your
> wireless network. If you temporarily connect via ethernet, is the
> behavior better?
Haven't been able to test. However, I dont understand your reply. A buffer
of 99% should be more than a few seconds of music, so even a throuput issue
should depleate the buffer rather than causing a dropout?

>> 6/ Frequent reboots at random places (often playing or pressing to stop
>> playing)
> Which version of SlimServer are you using? The frequent rebooting issues
> should be largely resolved with the latest "nightly" build with firmware
> version 37.
Latest everything... Will try more tests again this weekend

>
>> 7/ Got stuck in a loop when searched for a song, the SB displayed a quick
>> message to say that SB signal lost and then it said that song was not
>> found. At this point it showed "a no songs of this name" type message and
>> no key strokes would get me free. After a reboot, I was stuck at the same
>> place. After several reboots, it freed up.
> May be the same issue as above.
OK

Thanks

Stuart

jacobdp
2004-09-15, 14:40
On Wed, 15 Sep 2004 22:34:30 +0100, Beesley, S <sbeesley (AT) dsl (DOT) pipex.com> wrote:
> Haven't been able to test. However, I dont understand your reply. A buffer
> of 99% should be more than a few seconds of music, so even a throuput issue
> should depleate the buffer rather than causing a dropout?

IIRC, the buffer status is rendered on the server. In the event of a
connection problem long enough to cause dropout, the server won't be
able to update the status display. You'd see the buffer indicator
"freeze" at 100% for a few seconds until the music stopped.

- Jacob

Beesley, S
2004-09-16, 11:09
Thanks. OK, so where is the buffering - on the SB or on the server? I would
suggest that the buffer should be on the SB?


> On Wed, 15 Sep 2004 22:34:30 +0100, Beesley, S <sbeesley (AT) dsl (DOT) pipex.com>
> wrote:
>> Haven't been able to test. However, I dont understand your reply. A
>> buffer
>> of 99% should be more than a few seconds of music, so even a throuput
>> issue
>> should depleate the buffer rather than causing a dropout?
>
> IIRC, the buffer status is rendered on the server. In the event of a
> connection problem long enough to cause dropout, the server won't be
> able to update the status display. You'd see the buffer indicator
> "freeze" at 100% for a few seconds until the music stopped.
>
> - Jacob

kdf
2004-09-16, 11:20
Quoting "Beesley, S" <sbeesley (AT) dsl (DOT) pipex.com>:

> Thanks. OK, so where is the buffering - on the SB or on the server? I would
> suggest that the buffer should be on the SB?

There is an audio buffer on the SB of 1M, I believe.

That has nothing to do with the actual display of this buffer information. A
completely lost connection means the server cannot update the display to tell
you the buffer is draining. If you want to test this out, try killing the
server mid-play. You get several seconds of continued playback before the
audio stops. The display, however, is gone almost immediately.

-kdf

> > On Wed, 15 Sep 2004 22:34:30 +0100, Beesley, S <sbeesley (AT) dsl (DOT) pipex.com>
> > wrote:
> >> Haven't been able to test. However, I dont understand your reply. A
> >> buffer
> >> of 99% should be more than a few seconds of music, so even a throuput
> >> issue
> >> should depleate the buffer rather than causing a dropout?
> >
> > IIRC, the buffer status is rendered on the server. In the event of a
> > connection problem long enough to cause dropout, the server won't be
> > able to update the status display. You'd see the buffer indicator
> > "freeze" at 100% for a few seconds until the music stopped.
> >
> > - Jacob
>
>

Beesley, S
2004-09-17, 12:38
Should the display buffer not be managed by the SB rather than the Server?

----- Original Message -----
From: "kdf" <slim-mail (AT) deane-freeman (DOT) com>
To: "Slim Devices Discussion" <discuss (AT) lists (DOT) slimdevices.com>
Sent: Thursday, September 16, 2004 7:20 PM
Subject: [slim] Current errors


> Quoting "Beesley, S" <sbeesley (AT) dsl (DOT) pipex.com>:
>
>> Thanks. OK, so where is the buffering - on the SB or on the server? I
>> would
>> suggest that the buffer should be on the SB?
>
> There is an audio buffer on the SB of 1M, I believe.

seanadams
2004-09-19, 08:57
Client-side buffer usage display wasn't really possible with the
character display, because we didn't have an easy way to overlay or
insert the buffer usage information while the server was driving the
information on the screen.

However, I do have a simple hack in firmware (for graphic display only)
which shows the buffer usage as a single-pixel bar along the bottom of
the screen. It is currently only a compile-time thing, but I'll see
about adding a command to let the server switch it on/off at run-time.



On Sep 17, 2004, at 12:38 PM, Beesley, S wrote:

> Should the display buffer not be managed by the SB rather than the
> Server?
>
> ----- Original Message ----- From: "kdf" <slim-mail (AT) deane-freeman (DOT) com>
> To: "Slim Devices Discussion" <discuss (AT) lists (DOT) slimdevices.com>
> Sent: Thursday, September 16, 2004 7:20 PM
> Subject: [slim] Current errors
>
>
>> Quoting "Beesley, S" <sbeesley (AT) dsl (DOT) pipex.com>:
>>
>>> Thanks. OK, so where is the buffering - on the SB or on the server?
>>> I would
>>> suggest that the buffer should be on the SB?
>>
>> There is an audio buffer on the SB of 1M, I believe.
>
>

Daryle A. Tilroe
2004-09-19, 10:33
Sean Adams wrote:

> However, I do have a simple hack in firmware (for graphic display only)
> which shows the buffer usage as a single-pixel bar along the bottom of
> the screen. It is currently only a compile-time thing, but I'll see
> about adding a command to let the server switch it on/off at run-time.

This would be a great little diagnostic tool for those debugging
wireless problems. I just hope it doesn't break five other things
;-).

--
Daryle A. Tilroe