here's the bug:
http://bugs.slimdevices.com/show_bug.cgi?id=2745
--
RichardG
RichardG's Profile: http://forums.slimdevices.com/member.php?userid=801
View this thread: http://forums.slimdevices.com/showthread.php?t=19009
In the mean time I learned that the bug report already existed and was
fixed for 6.5.x. Lately, the fix was merged into the 6.2.x branch.
Resume now works for me, there are just some glitches with the time
remaining displayed.
See here:
http://forums.slimdevices.com/showthread.php?t=19322
--
0x
Almost ready to file a bug report here..
First off, playing the same song that caused the SQB to enter the
"endless playing state" at various positions in the playlist had no
impact. flac -t on the file showed 100% correct.
I tried the "pause" test as suggested in the previous post. I tested on
Hm, just happened again.
I paused inside a title. When I restarted after half an hour or so, the
SB continued, but at the end of the song it did't skip to the next song,
but played silence (time remaining 00:00 and so on).
I use a static IP now for the SB so this is definitely no DHCP issue.
--
Beef
I suspect you're on to something with using Pause over an extended
period of time. I experienced my only true issue with the device
about 2 weeks ago. The device stopped playing, the screen on the
device was pixellated and I couldn't reconnect to the network. It
appeared that my MAC was
dean Wrote:
> Richard,
>
> I wonder if there's a specific song that causes the player to get
> into this state. Do you have way to reproduce the situation?
>
>
>
>
I have not been able to verify that it is a single file or some other
kind of problem. I know which track was playing at the
Richard,
I wonder if there's a specific song that causes the player to get
into this state. Do you have way to reproduce the situation?
On Dec 14, 2005, at 5:02 PM, RichardG wrote:
Well, I have another situation that is resulting in the
slimserver / SQB
ending up in a "playing" state w
Tbis thread is not about the SB freezing/crashing/hanging in a deadlock
that can't be fixed with remote or web interface.
Indeed the "endless playing" state can be easily left by either remote
or web interface. It's just that I would favor the SB not entering this
state at all.
--
0xdeadbeef
--
0xdeadbeef Wrote:
> I don't see how this will eliminate user intervention !?It's just like
> Western medicine. It cures you by treating the symptoms.
The SB3 will often get into a dysfunctional state. Remote rebooting the
SB3 is the only way to make it come back to working properly. I remote
re
RichardG Wrote:
> Well, I have another situation that is resulting in the slimserver / SQB
> ending up in a "playing" state with no actual music being produced, and
> being stuck on the same song until some user intervention. I was
> *unable* to catch the condition with debug flags enabled. A pos
Well, I have another situation that is resulting in the slimserver / SQB
ending up in a "playing" state with no actual music being produced, and
being stuck on the same song until some user intervention. I was
*unable* to catch the condition with debug flags enabled. A post mortem
reveals:
2005-1
Sorry.. got kind of caught up in my own problems. I did not mean to
imply that your problem was for sure a DHCP problem. You might be
having a situation where DHCP is causing some issues for you, but there
could be something else going on. In my case, DHCP renegotiation was
resulting in a new IP a
Hm, interesting...
It just happened again to me by the way.
Indeed the Squeezebox was paused in the first song of an album, but it
was displaying the date/time during this period of inactivity, so I
don't get why it should get a DHCP timeout.
When resuming playback, it showed "00:00" (minutes/se
phew.. ok I think I got it. I am testing now.
The problem is that DHCP is getting a renewal of the IP address, and
this is killing the connection between the SQB and the server. And it
does not come back without user intervention.
Here's the analysis. At exactly 2005-12-12 16:54:48.9615, the SQB
After source and slimproto debugs.. there is no Decoder underrun beging
generated. Everything else seems to occur the same as other tracks..
but a message like this one: "Decoder underrun while this mode:
playout-play" never appears and the stream subsystem stops.
Anyone have a faster way to get
Oh no.. I am seeing similiar problems accross a wide range of platforms
with 6.2.1 code base. Seems that after playing continuously for a
number of hours or days, the timers get screwed up and SQB fails to
recognize that the song has ended. It will stay in the "play" state for
many, many hours aft
16 matches
Mail list logo