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 the last song has completed. When in this state, starting the next song via the web browser causes the song to play, finish and to never move to the following song. But the player mode still indicates "play". I tried some debug things.. here is a sample of timers while in the odd state:
2005-12-12 08:48:05.0401 settimer Normal: CODE(0x9738ed4), now: 1134395285.04007, time: 1134395286.03228 2005-12-12 08:48:05.0465 select_time: 0.132722616195679 2005-12-12 08:48:05.1820 firing high timer 0.00277447700500488 late. 2005-12-12 08:48:05.1851 settimer High: CODE(0x9fbde60), now: 1134395285.18502, time: 1134395285.32919 2005-12-12 08:48:05.1881 select_time: 0.141104698181152 2005-12-12 08:48:05.3320 firing high timer 0.00277447700500488 late. 2005-12-12 08:48:05.3350 settimer High: CODE(0x9fbde60), now: 1134395285.33495, time: 1134395288.92919 2005-12-12 08:48:05.3379 select_time: 0.627464056015015 2005-12-12 08:48:05.9680 firing timer 0.00260186195373535 late. 2005-12-12 08:48:05.9706 screenSaver idle display 43777.5302000046(mode:playlist) 2005-12-12 08:48:05.9739 settimer Normal: CODE(0x9a47ad4), now: 1134395285.97384, time: 1134395286.9704 2005-12-12 08:48:05.9770 select_time: 0.0553300380706787 2005-12-12 08:48:06.0350 firing timer 0.00267910957336426 late. 2005-12-12 08:48:06.0376 settimer Normal: CODE(0x9738ed4), now: 1134395286.03751, time: 1134395287.03228 2005-12-12 08:48:06.0440 select_time: 0.680253982543945 2005-12-12 08:48:06.7270 firing timer 0.00277996063232422 late. Here is a sample of select: 2005-12-12 08:50:51.4068 select returns (0.0155661106109619): 2005-12-12 08:50:51.4092 errors: 0 of 3 2005-12-12 08:50:51.4120 reads: 0 of 6 2005-12-12 08:50:51.4146 writes: 0 of 0 2005-12-12 08:50:51.5288 select returns (0.110943078994751): 2005-12-12 08:50:51.5312 errors: 0 of 3 2005-12-12 08:50:51.5340 reads: 0 of 6 2005-12-12 08:50:51.5368 writes: 0 of 0 2005-12-12 08:50:51.6798 select returns (0.139132261276245): 2005-12-12 08:50:51.6822 errors: 0 of 3 2005-12-12 08:50:51.6849 reads: 0 of 6 2005-12-12 08:50:51.6876 writes: 0 of 0 2005-12-12 08:50:51.8298 select returns (0.138278245925903): 2005-12-12 08:50:51.8322 errors: 0 of 3 2005-12-12 08:50:51.8350 reads: 0 of 6 2005-12-12 08:50:51.8378 writes: 0 of 0 2005-12-12 08:50:51.9798 select returns (0.138145446777344): 2005-12-12 08:50:51.9822 errors: 0 of 3 2005-12-12 08:50:51.9849 reads: 0 of 6 2005-12-12 08:50:51.9876 writes: 0 of 0 2005-12-12 08:50:52.0328 select returns (0.0413010120391846): 2005-12-12 08:50:52.0352 errors: 0 of 3 2005-12-12 08:50:52.0380 reads: 0 of 6 2005-12-12 08:50:52.0408 writes: 0 of 0 2005-12-12 08:50:52.0773 select returns (0.0820064544677734): 2005-12-12 08:50:52.0798 errors: 0 of 3 2005-12-12 08:50:52.0825 reads: 1 of 6 All the other debug options seemed to report no information while in this state. I notice that it seems related to deletetracks and addtracks in Slim::Control::command.. could it be removemultipletracks? Wish I could get ahold of the log before this happens or during it, but the system can run for days until the problem happens. 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
