mhilbush wrote: > I built a few more older versions and ran some tests. Not sure if this > is on the right track or not. > > This commit looks like it's working correctly. > https://github.com/ralph-irving/squeezelite/commit/b79ac7c8bc288e78b58ac789c70dd02f12c21c10 > > But then the commit immediately following the above commit seems to > introduce the behavior I was seeing in 1.8. > https://github.com/ralph-irving/squeezelite/commit/a4dfd1e54ed19632e9f0473a10d426939b4239e3 > > Is it possible that there's an edge case or timing issue that's not > being handled correctly?
I'll preface this by saying that I don't know the code at all... But, just a guess. Since it's such a small mp3 file (about 17k) that fits into a single buffer, could it be that the stream is being disconnected (stream_state == DISCONNECT) more quickly than with a larger file, causing the decoder never to be put into the DECODE_RUNNING state (i.e. stream_state is never STREAMING_FILE or STREAMING_HTTP)? ------------------------------------------------------------------------ mhilbush's Profile: http://forums.slimdevices.com/member.php?userid=16832 View this thread: http://forums.slimdevices.com/showthread.php?t=97046 _______________________________________________ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
