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
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
--
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
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
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
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?
snip
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
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
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
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
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:
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 post
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
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
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
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
16 matches
Mail list logo
