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-12-14 14:38:10.6498 Got Slimproto frame, op STAT, length 41,
IO::Socket::INET=GLOB(0xb6d5cd8)
2005-12-14 14:38:10.6505 00:04:20:05:d2:7f Squeezebox stream status:
fullness: 1990 (0%)
bytes_received 26964399
2005-12-14 14:38:11.6497 Got Slimproto frame, op STAT, length 41,
IO::Socket::INET=GLOB(0xb6d5cd8)
2005-12-14 14:38:11.6504 00:04:20:05:d2:7f Squeezebox stream status:
fullness: 1990 (0%)
bytes_received 26964399
2005-12-14 14:38:12.6498 Got Slimproto frame, op STAT, length 41,
IO::Socket::INET=GLOB(0xb6d5cd8)
2005-12-14 14:38:12.6505 00:04:20:05:d2:7f Squeezebox stream status:
fullness: 1990 (0%)
bytes_received 26964399
Normally, the buffer fullness should be 0 (0%), and this would cause
the SQB to generate a decoder underrun frame. But the SQB is reporting
that the buffer still contains an orphaned fragment, and never causes
the run of DecoderUnderun in streamproto. The slimserver never recieves
the "d" type STAT frame from the SQB. I am rerunning with debug flags
enabled to get more details on the http and stream status when the
error occurs.
I guess the question is why would the SQB firmware assume there was
some tiny amount of data in the buffer and never clear it out?
Richard
--
RichardG
------------------------------------------------------------------------
RichardG's Profile: http://forums.slimdevices.com/member.php?userid=801
View this thread: http://forums.slimdevices.com/showthread.php?t=19009
_______________________________________________
Discuss mailing list
Discuss@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/discuss
