te36 wrote: > From experience in the past days, it does get the job done in > prohibiting reboots, but unfortunately not uninterrupted connectivity - > but i am listening to radio, so maybe not so much buffering possible . > Not yet tried music from server. Right. You could try "tuning" the software using command line options to shorten the dropout detection time, and whatever (I don't know) settings are available in the radio and server for increasing the buffering to make dropouts less frequent or shorter. The problem becomes worse with synchronized radios, as an interruption in one causes an interruption in all.
> Trigger frequency is highly variable. Some days i think none at all, > some days every 30 minutes. > I almost bet it is _A_ particular neighbor access point or device, but > not enough time trying to isolate. Try using the logging and reporting features mentioned earlier to isolate an "offender," and display dropout events and statistics.You could augment that using a notebook with wireless adapter to provide a more sensitive and complete network scan. > I was wondering if it could help to force the radio to not scan channels > by only ever attempt to use one specific channel and make it different > from the usual channels 1,6,11. Alas, i couldn't figure out how to > configure that. My suspicion is that the radio is disrupted during these frequent scans. These settings are in the wireless driver stack and opaque firmware. I remember there was a patch to the stock driver to make scanning more frequent, which perhaps could be adjusted in the other direction. ------------------------------------------------------------------------ POMdev's Profile: http://forums.slimdevices.com/member.php?userid=70558 View this thread: http://forums.slimdevices.com/showthread.php?t=113479 _______________________________________________ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
