Bug 12920 - Diagnostics addition: Add option to provide audio feedback when WiFi issues arise
: Diagnostics addition: Add option to provide audio feedback when WiFi issues a...
Status: NEW
Product: SqueezePlay
Classification: Unclassified
Component: --
: unspecified
: PC Other
: -- normal (vote)
: 8.0.0
Assigned To: Unassigned bug - please assign me!
: Support-Important
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-07-17 16:58 UTC by Dan Evans
Modified: 2011-11-06 23:22 UTC (History)
7 users (show)

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dan Evans 2009-07-17 16:58:57 UTC
When dealing with wireless signal issues, it's very difficult to get reliable feedback from the user.  Firstly, they resist the notion that anything is wrong with their network, and secondly, we're dealing with a thing that is not only invisible but it's hard to measure even if you know what you're doing.  

So, I propose the following:

 * Create a new option at the bottom of Diagnostics called "WiFi Audio Feedback"

 * When WiFi Audio Feedback is ON, two things can trigger the playing of an audio cue over the speakers or audio outs.  That sound could either be a generated tone or a canned waveform.  It just needs to be audible, distinct, and non-annoying.  The triggers are:

   1. When the WiFi signal drops below a defined threshold (TBD)
   2. When the devices has lost its internet connection.  (can't ping SN.com?) 

This will allow Support to quickly and easily test and prove what issue a user is facing.  Plus because it's audible it can inform the user specifically when and how frequently these events are happening, so they may correlate it to an event or something in their environment.  (example: everything their phone rings they hear a chirp-chirp sound from their Squeezebox.)

This should be implemented for all SqueezePlay-based devices, and if feasible backported to older players as well.
Comment 1 James Richardson 2009-07-30 10:12:20 UTC
Targeting for next release
Comment 2 Ben Klaas 2009-08-26 07:46:51 UTC
this is an administrative shuffle on priority fields to help make better judgment on the top end of the priority list. P4->P5, P3->P4, and P2->P3.
Comment 3 Chris Owens 2010-05-07 10:28:47 UTC
Richard is no longer available to us.
Comment 4 Alan Young 2011-11-06 23:22:26 UTC
Unassigned bugs cannot have a priority.