ralphy wrote: > ... > Yes, I did remove the test versions and have adding new r1323 32/64 > windows binaries. > ...
I tested with v1.9.8.1323/64. Sometimes a title runs through till the end, but in most cases still dropouts after 3 minutes. Symptom is again 100% cpu time on one core. Testing with "-b256 -d all=sdebug" I see lines like [16:20:37.944] stream_thread:428 streambuf read 3756 bytes before the onset of 100% cpu time but not thereafter. The streambuffer runs empty, then the ouput buffer, then the dropout. [16:20:38.044] decode_thread:75 streambuf bytes: 262143 outputbuf space: 241055 ... [16:20:48.468] decode_thread:75 streambuf bytes: 1913 outputbuf space: 180431 [16:20:48.538] sendSTAT:166 ms_played: 173186 (frames_played: 7637537 device_frames: 0) [16:20:48.538] sendSTAT:195 STAT: STMt [16:20:48.538] sendSTAT:200 received bytesL: 4469675 streambuf: 1913 outputbuf: 3339376 calc elapsed: 173186 real elapsed: 173203 (diff: -17) device: 0 delay: 0 ... [16:20:58.487] decode_thread:75 streambuf bytes: 1913 outputbuf space: 3527999 [16:20:58.517] sendSTAT:166 ms_played: 182621 (frames_played: 8055983 device_frames: 3072) [16:20:58.517] sendSTAT:195 STAT: STMt [16:20:58.517] sendSTAT:200 received bytesL: 4469675 streambuf: 1913 outputbuf: 0 calc elapsed: 182621 real elapsed: 183172 (diff: -551) device: 69 delay: 16 [16:20:58.517] sendSTAT:166 ms_played: 182621 (frames_played: 8055983 device_frames: 3072) The 100% cpu time is from one thread. Using ProcessExplorer this thread's start address is squeezelite-x64.exe+0x88790 This thread usually is way below 1% cpu time. Attaching Visual Studio Debugger and halting squeezelite while in 100% cpu mode shows alternate locations squeezelite-x64.exe!00007ff7f06d8a31 mswsock.dll!00007ffa4e96c5fe This seems to point to a continued polling originating from a squeezelite thread. So much towards the symptoms I see. Reasoning over it: Whatever the problem is, squeezelite should not be producing 100% cpu time, most of which is in kernel mode, since that in itself could lead to all sorts of strange problems from as of yet unknown race conditions. These race conditions could originate from code one has no control over. My strategy would be: - find the source/reason fo the continued polling - insert a sleep with randomized duration (e.g. 5..50ms) This could already solve the problem in case there is a hidden race condition that is only triggered when cpu time is tight. In case one cannot recover - abort the polling after some time (e.g. 5 seconds) - reset the connection - start the stream anew and skip to the current point in the streambuffer (that I guess would be a major change) In any case thanks for your time doing this for all of us for free. It is much appreciated. ------------------------------------------------------------------------ fpo's Profile: http://forums.slimdevices.com/member.php?userid=71212 View this thread: http://forums.slimdevices.com/showthread.php?t=113554 _______________________________________________ plugins mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/plugins
