Home of the Squeezebox™ & Transporter® network music players.
Page 11 of 18 FirstFirst ... 910111213 ... LastLast
Results 101 to 110 of 179
  1. #101
    Senior Member Tony T's Avatar
    Join Date
    Nov 2009
    Posts
    1,146
    Quote Originally Posted by frankd View Post

    ...the LEDs are very annoying...
    Yes. Can’t tape over the case as it’s the vent...
    ....but, the case is press fit. Easy to pop open and place a small piece of electrical tape directly over the LED.
    Tony
     SBTouch ♪ SBRadio ♬

  2. #102
    Senior Member
    Join Date
    Jan 2012
    Posts
    178
    Quote Originally Posted by POMdev View Post
    Thank's for digging into this. What happened after the failure, did you have to reboot? How long was the music interruption? On what service? We sometimes notice a couple of second interruptions here, but have experienced that for many years.

    Edit: Why hard-code the gateway? The idea was to test the wifi by pinging the nearest device (i.e., the gateway) (e.g., in case the LMS server is down), and netstat is supposed to return that IP address correctly.

    A user PMd me (last month) and noted that there were two (v 0.6.3) bugs on lines 515 & 584 when using -x (no TCPLOG). I replied:

    A new version 0.6.4 (not finished) has these fixed in two places. You should fix yours (to 0.6.3.1), it might improve your results significantly if using -x. Actually, everyone should do this.

    Before uploading a new version, I am wondering if I should add new command line switches to assign values to variables which would replace the three constants you mentioned: 'Seconds between Tests', 'Failure Limit', and 'Restart Wait Seconds', or something else. I would like your and others opinions before continuing. Keep in mind any change might add yet new bugs.
    I am using the script with the two bug-fixes now. I hard-coded the gateway just to be sure to reduce the number of potential sources of failure, non-hardcoded is of course ways more elegant in future.
    The good news: In most cases the two affected radios did restart the wifi without me requiring a reboot. Within one week I had to reboot one radio once - it was without network and rebooting was the only way to get it back again... Thus overall I have to intervene a lot less.

    Since the radios are located furthest away from my office at home, the only way to monitor failures for me means synchronizing the entire apartment. My observations:
    if the WIFI of one of the affected radios fails, the synchronization group is interrupted (maybe 5 second interruption , plays for 5 seconds, then is interrupted for another second). My interpretation: First interruption after a certain time of wifi failure, the group continues without the affected radio and gets interrupted again when the affected radio joins the affected group again (using Philippe's Sync-Group Plugin).

    For me it seems as if the time from detecting the problem first to restarting the network takes a long time, causing these interruptions. One example with time stamps below. That was the reason why I wanted to use only 3 loops with 1 second delay each...

    2021-02-26T16:48:36+0100 Schlafzimmer.65_063 192.168.192.1 ping failed eth1 AR6000 802.11g ESSID:"Franky2" Mode:Managed Frequency:2.472 GHz Access Point: 00:18:E74:214 Bit Rate=6 Mb/s Tx-Power=15 dBm Sensitivity=0/3 Retryn Encryption keyff Link Quality:26/94 Signal level:-69 dBm Noise level:-96 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:34 Invalid misc:0 Missed beacon:1
    2021-02-26T16:48:37+0100 Schlafzimmer.65_063 Link Statistics
    2021-02-26T16:48:21+0100: Bit Rate=36 Mb/s Tx-Power=15 dBm Sensitivity=0/3 Link Quality:26/94 Signal level:-69 dBm Noise level:-96 dBm Tx excessive retries:29 Invalid misc:0 Missed beacon:1 time=5.444 00:18:e7:e4:dc:b1 2412 201 [WPA2-PSK-CCMP] Franky24 e0:63:da:ba:6e:f5 2437 183 [WPA2-PSK-CCMP] UFO 00:18:e7:d4:21:d4 2472 183 [WPA2-PSK-CCMP] Franky2 d4:63:fe:5c:b2:44 2412 181 [WPA-PSK-TKIP+CCMP][WPA2-PSK-TKIP+CCMP][WPS] tle-53241 02:18:e7:d4:21:d4 2472 181 [WPA2-PSK-CCMP] FrankyGast e0:63:da:ba:6c:db 2437 177 [WPA2-PSK-CCMP] UFO e0:3f:49:0a:37:38 2437 176 [WPA2-PSK-CCMP][WPS] ASUS 60:d2:48:b2:9e:a2 2437 171 [WPA2-PSK-CCMP][WPS] BREITBAND-3E0E 2c:99:24:66:a5:31 2462 169 [WPA2-PSK-CCMP][WPS] BREITBAND-A533 94:e9:ee:84:40:bc 2432 165 [WPA2-PSK-CCMP][WPS] HUAWEI_H122_40BC
    2021-02-26T16:48:23+0100: Bit Rate=54 Mb/s Tx-Power=15 dBm Sensitivity=0/3 Link Quality:26/94 Signal level:-69 dBm Noise level:-96 dBm Tx excessive retries:30 Invalid misc:0 Missed beacon:1 time=13.399 00:18:e7:e4:dc:b1 2412 201 [WPA2-PSK-CCMP] Franky24 e0:63:da:ba:6e:f5 2437 183 [WPA2-PSK-CCMP] UFO 00:18:e7:d4:21:d4 2472 183 [WPA2-PSK-CCMP] Franky2 d4:63:fe:5c:b2:44 2412 181 [WPA-PSK-TKIP+CCMP][WPA2-PSK-TKIP+CCMP][WPS] tle-53241 02:18:e7:d4:21:d4 2472 181 [WPA2-PSK-CCMP] FrankyGast e0:63:da:ba:6c:db 2437 177 [WPA2-PSK-CCMP] UFO e0:3f:49:0a:37:38 2437 176 [WPA2-PSK-CCMP][WPS] ASUS 60:d2:48:b2:9e:a2 2437 171 [WPA2-PSK-CCMP][WPS] BREITBAND-3E0E 2c:99:24:66:a5:31 2462 169 [WPA2-PSK-CCMP][WPS] BREITBAND-A533 94:e9:ee:84:40:bc 2432 165 [WPA2-PSK-CCMP][WPS] HUAWEI_H122_40BC
    2021-02-26T16:48:25+0100: Bit Rate=48 Mb/s Tx-Power=15 dBm Sensitivity=0/3 Link Quality:26/94 Signal level:-69 dBm Noise level:-96 dBm Tx excessive retries:30 Invalid misc:0 Missed beacon:1 time=29.844 00:18:e7:e4:dc:b1 2412 201 [WPA2-PSK-CCMP] Franky24 e0:63:da:ba:6e:f5 2437 183 [WPA2-PSK-CCMP] UFO 00:18:e7:d4:21:d4 2472 183 [WPA2-PSK-CCMP] Franky2 d4:63:fe:5c:b2:44 2412 181 [WPA-PSK-TKIP+CCMP][WPA2-PSK-TKIP+CCMP][WPS] tle-53241 02:18:e7:d4:21:d4 2472 181 [WPA2-PSK-CCMP] FrankyGast e0:63:da:ba:6c:db 2437 177 [WPA2-PSK-CCMP] UFO e0:3f:49:0a:37:38 2437 176 [WPA2-PSK-CCMP][WPS] ASUS 60:d2:48:b2:9e:a2 2437 171 [WPA2-PSK-CCMP][WPS] BREITBAND-3E0E 2c:99:24:66:a5:31 2462 169 [WPA2-PSK-CCMP][WPS] BREITBAND-A533 94:e9:ee:84:40:bc 2432 165 [WPA2-PSK-CCMP][WPS] HUAWEI_H122_40BC
    2021-02-26T16:48:26+0100: Bit Rate=36 Mb/s Tx-Power=15 dBm Sensitivity=0/3 Link Quality:27/94 Signal level:-68 dBm Noise level:-96 dBm Tx excessive retries:30 Invalid misc:0 Missed beacon:1 time=3.126 00:18:e7:e4:dc:b1 2412 201 [WPA2-PSK-CCMP] Franky24 e0:63:da:ba:6e:f5 2437 183 [WPA2-PSK-CCMP] UFO 00:18:e7:d4:21:d4 2472 183 [WPA2-PSK-CCMP] Franky2 d4:63:fe:5c:b2:44 2412 181 [WPA-PSK-TKIP+CCMP][WPA2-PSK-TKIP+CCMP][WPS] tle-53241 02:18:e7:d4:21:d4 2472 181 [WPA2-PSK-CCMP] FrankyGast e0:63:da:ba:6c:db 2437 177 [WPA2-PSK-CCMP] UFO e0:3f:49:0a:37:38 2437 176 [WPA2-PSK-CCMP][WPS] ASUS 60:d2:48:b2:9e:a2 2437 171 [WPA2-PSK-CCMP][WPS] BREITBAND-3E0E 2c:99:24:66:a5:31 2462 169 [WPA2-PSK-CCMP][WPS] BREITBAND-A533 94:e9:ee:84:40:bc 2432 165 [WPA2-PSK-CCMP][WPS] HUAWEI_H122_40BC
    2021-02-26T16:48:28+0100: Bit Rate=48 Mb/s Tx-Power=15 dBm Sensitivity=0/3 Link Quality:26/94 Signal level:-69 dBm Noise level:-96 dBm Tx excessive retries:30 Invalid misc:0 Missed beacon:1 time=13.090 00:18:e7:e4:dc:b1 2412 201 [WPA2-PSK-CCMP] Franky24 e0:63:da:ba:6e:f5 2437 183 [WPA2-PSK-CCMP] UFO 00:18:e7:d4:21:d4 2472 183 [WPA2-PSK-CCMP] Franky2 d4:63:fe:5c:b2:44 2412 181 [WPA-PSK-TKIP+CCMP][WPA2-PSK-TKIP+CCMP][WPS] tle-53241 02:18:e7:d4:21:d4 2472 181 [WPA2-PSK-CCMP] FrankyGast e0:63:da:ba:6c:db 2437 177 [WPA2-PSK-CCMP] UFO e0:3f:49:0a:37:38 2437 176 [WPA2-PSK-CCMP][WPS] ASUS 60:d2:48:b2:9e:a2 2437 171 [WPA2-PSK-CCMP][WPS] BREITBAND-3E0E 2c:99:24:66:a5:31 2462 169 [WPA2-PSK-CCMP][WPS] BREITBAND-A533 94:e9:ee:84:40:bc 2432 165 [WPA2-PSK-CCMP][WPS] HUAWEI_H122_40BC
    2021-02-26T16:48:31+0100: Bit Rate=36 Mb/s Tx-Power=15 dBm Sensitivity=0/3 Link Quality:27/94 Signal level:-68 dBm Noise level:-96 dBm Tx excessive retries:30 Invalid misc:0 Missed beacon:1 time=13.340 00:18:e7:e4:dc:b1 2412 201 [WPA2-PSK-CCMP] Franky24 e0:63:da:ba:6e:f5 2437 183 [WPA2-PSK-CCMP] UFO 00:18:e7:d4:21:d4 2472 183 [WPA2-PSK-CCMP] Franky2 d4:63:fe:5c:b2:44 2412 181 [WPA-PSK-TKIP+CCMP][WPA2-PSK-TKIP+CCMP][WPS] tle-53241 02:18:e7:d4:21:d4 2472 181 [WPA2-PSK-CCMP] FrankyGast e0:63:da:ba:6c:db 2437 177 [WPA2-PSK-CCMP] UFO e0:3f:49:0a:37:38 2437 176 [WPA2-PSK-CCMP][WPS] ASUS 60:d2:48:b2:9e:a2 2437 171 [WPA2-PSK-CCMP][WPS] BREITBAND-3E0E 2c:99:24:66:a5:31 2462 169 [WPA2-PSK-CCMP][WPS] BREITBAND-A533 94:e9:ee:84:40:bc 2432 165 [WPA2-PSK-CCMP][WPS] HUAWEI_H122_40BC
    2021-02-26T16:48:33+0100: Bit Rate=54 Mb/s Tx-Power=15 dBm Sensitivity=0/3 Link Quality:27/94 Signal level:-68 dBm Noise level:-96 dBm Tx excessive retries:30 Invalid misc:0 Missed beacon:1 time=15.156 00:18:e7:e4:dc:b1 2412 201 [WPA2-PSK-CCMP] Franky24 e0:63:da:ba:6e:f5 2437 183 [WPA2-PSK-CCMP] UFO 00:18:e7:d4:21:d4 2472 183 [WPA2-PSK-CCMP] Franky2 d4:63:fe:5c:b2:44 2412 181 [WPA-PSK-TKIP+CCMP][WPA2-PSK-TKIP+CCMP][WPS] tle-53241 02:18:e7:d4:21:d4 2472 181 [WPA2-PSK-CCMP] FrankyGast e0:63:da:ba:6c:db 2437 177 [WPA2-PSK-CCMP] UFO e0:3f:49:0a:37:38 2437 176 [WPA2-PSK-CCMP][WPS] ASUS 60:d2:48:b2:9e:a2 2437 171 [WPA2-PSK-CCMP][WPS] BREITBAND-3E0E 2c:99:24:66:a5:31 2462 169 [WPA2-PSK-CCMP][WPS] BREITBAND-A533 94:e9:ee:84:40:bc 2432 165 [WPA2-PSK-CCMP][WPS] HUAWEI_H122_40BC
    2021-02-26T16:48:36+0100: Bit Rate=6 Mb/s Tx-Power=15 dBm Sensitivity=0/3 Link Quality:26/94 Signal level:-69 dBm Noise level:-96 dBm Tx excessive retries:34 Invalid misc:0 Missed beacon:1 00:18:e7:e4:dc:b1 2412 201 [WPA2-PSK-CCMP] Franky24 e0:63:da:ba:6e:f5 2437 183 [WPA2-PSK-CCMP] UFO 00:18:e7:d4:21:d4 2472 183 [WPA2-PSK-CCMP] Franky2 d4:63:fe:5c:b2:44 2412 181 [WPA-PSK-TKIP+CCMP][WPA2-PSK-TKIP+CCMP][WPS] tle-53241 02:18:e7:d4:21:d4 2472 181 [WPA2-PSK-CCMP] FrankyGast e0:63:da:ba:6c:db 2437 177 [WPA2-PSK-CCMP] UFO e0:3f:49:0a:37:38 2437 176 [WPA2-PSK-CCMP][WPS] ASUS 60:d2:48:b2:9e:a2 2437 171 [WPA2-PSK-CCMP][WPS] BREITBAND-3E0E 2c:99:24:66:a5:31 2462 169 [WPA2-PSK-CCMP][WPS] BREITBAND-A533 94:e9:ee:84:40:bc 2432 165 [WPA2-PSK-CCMP][WPS] HUAWEI_H122_40BC
    2021-02-26T16:49:13+0100 Schlafzimmer.65_063 failed 2021-02-26T16:48:36+0100 reset 2021-02-26T16:48:43+0100 up 2021-02-26T16:49:11+0100 eth1 AR6000 802.11g ESSID:"Franky2" Mode:Managed Frequency:2.472 GHz Access Point: 00:18:E74:214 Bit Rate=54 Mb/s Tx-Power=15 dBm Sensitivity=0/3 Retryn Encryption keyff Link Quality:28/94 Signal level:-67 dBm Noise level:-96 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 PING 192.168.192.1 (192.168.192.1): 56 data bytes 64 bytes from 192.168.192.1: seq=0 ttl=64 time=45.989 ms --- 192.168.192.1 ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max = 45.989/45.989/45.989 ms

  3. #103
    Quote Originally Posted by frankd View Post
    I am using the script with the two bug-fixes now. I hard-coded the gateway just to be sure to reduce the number of potential sources of failure, non-hardcoded is of course ways more elegant in future.
    The good news: In most cases the two affected radios did restart the wifi without me requiring a reboot. Within one week I had to reboot one radio once - it was without network and rebooting was the only way to get it back again... Thus overall I have to intervene a lot less.

    Since the radios are located furthest away from my office at home, the only way to monitor failures for me means synchronizing the entire apartment. My observations:
    if the WIFI of one of the affected radios fails, the synchronization group is interrupted (maybe 5 second interruption , plays for 5 seconds, then is interrupted for another second). My interpretation: First interruption after a certain time of wifi failure, the group continues without the affected radio and gets interrupted again when the affected radio joins the affected group again (using Philippe's Sync-Group Plugin).

    For me it seems as if the time from detecting the problem first to restarting the network takes a long time, causing these interruptions. One example with time stamps below. That was the reason why I wanted to use only 3 loops with 1 second delay each...
    It looks like the automatic gateway detection does not have to be overridden, as it seems reliable.

    Looking at your logs, what stands out to me is, first of all, the very low signal level ...Link Quality:26/94 Signal level:-69 dBm Noise level:-96 dBm Tx excessive retries:34.... I might have this backwards, but it might be that "Franky24" has a higher signal level than "Franky2". That said, I mistakenly ran a radio with similar levels and it continued to work, albeit with more frequent resets. Also, your "failed" to "reset" time is only 7 seconds vs 19 seconds here, but your "reset" to "up" time is 28 seconds vs 19 seconds here. Perhaps the long up time delay has something to do with low signal strength.

    Since the music generally kept playing here, it seemed OK with the hard coded test frequency and failure delay values. Synchronization adds another level of complexity, and these values may not be optimum for that use case. I think your changes are entirely appropriate, others might consider doing the same.

    The script was giving the radio network stack software, and any other possible future lower level mitigating solutions, every opportunity to do recover before "pulling the rug out" from the radio and restarting everything. Regrettably, the script does not track how many times the radio recovers from a few missed pings. We could add a statistic for number of failed pings and longest ping failure for later transmission to evaluate the time out constants. Modifying these values could lead to an improvement.

    BTW, there are other ways to monitor failures than synchronization. The TCP logger ncat described in manual.txt seems the easiest, yielding a real time display and saved log of failures. I also use the excellent Nirsoft Wireless Network Watcher and NetworkConnectLog apps for an on-screen real time update (although brief interruptions may not be captured by the latter two).

    Thanks for the report.
    Last edited by POMdev; 2021-02-27 at 09:41. Reason: Improve awkward wording

  4. #104
    Junior Member
    Join Date
    Jun 2017
    Posts
    26

    "your player was not found"

    Per the title bar, this problem always happens whenever I don't use my Squeezebox Radio or Boom. It even happens randomly even if I had used my Squeezebox devices in the past previous days. I have to try all sorts of computer 'acrobatics' to get connectivity with my wi-fi router. I'm at my wits end on this.

  5. #105
    Junior Member
    Join Date
    Jun 2017
    Posts
    26
    Quote Originally Posted by vcrpro3 View Post
    Per the title bar, this problem always happens whenever I don't use my Squeezebox Radio or Boom. It even happens randomly even if I had used my Squeezebox devices in the past previous days. I have to try all sorts of computer 'acrobatics' to get connectivity with my wi-fi router. I'm at my wits end on this.
    ...and now I am getting the 'scanner.exe error. the only way i been able to fix this is by completely removing LMS and it registry entries and then re-installing it....a major pita...

  6. #106
    Senior Member toby10's Avatar
    Join Date
    Jul 2007
    Location
    USA (home of the bottomless credit card)
    Posts
    9,296
    Quote Originally Posted by vcrpro3 View Post
    Per the title bar, this problem always happens whenever I don't use my Squeezebox Radio or Boom. It even happens randomly even if I had used my Squeezebox devices in the past previous days. I have to try all sorts of computer 'acrobatics' to get connectivity with my wi-fi router. I'm at my wits end on this.
    SB players or LMS host computer not connecting to WiFi?
    Sure it is not connecting to WiFi or just not connecting to server (LMS or MySB.com)?

  7. #107
    Senior Member toby10's Avatar
    Join Date
    Jul 2007
    Location
    USA (home of the bottomless credit card)
    Posts
    9,296
    Quote Originally Posted by vcrpro3 View Post
    ...and now I am getting the 'scanner.exe error. the only way i been able to fix this is by completely removing LMS and it registry entries and then re-installing it....a major pita...
    What is listed in log immediately following scanner.exe error?

  8. #108
    Senior Member
    Join Date
    Jan 2012
    Posts
    178
    Quote Originally Posted by Tony T View Post
    Yes. Canĺt tape over the case as itĺs the vent...
    ....but, the case is press fit. Easy to pop open and place a small piece of electrical tape directly over the LED.
    I tried it with the Vonets VAP11G-300 and the VAP11N-300. For the G version it worked well, however you have to use multiple layers of tape. for the N version it was less successful as there is little space to cover with the tape and there is a lot of indirect scattering of light.
    Amazing how much light these micro LEDs can emit...
    For all who are interested, the instructions I noted for myself:

    VAP11G-300 / VAP11G-500:
    - Open the two parts using a scissor or screwdriver from the front-end (away from the cables)
    - Put 4 Layers of Tape (Panzerband) onto the two diodes.
    - Put the board into the half with the reset button, ensure that the cables fit
    - press the board with a screw-driver versus the back (cables / reset button) while closing the case starting at the back

    VAP11N-300
    - not as effective as VAP11G-300
    - Open the two parts using a scissor or screwdriver from the front-end (away from the cables)
    - Put 4 Layers of Tape (Panzerband) onto the two diodes.
    - Close the case starting from the back (cables)

  9. #109
    Senior Member Tony T's Avatar
    Join Date
    Nov 2009
    Posts
    1,146
    Worked from me on the “G” with only one small cut square of Scotch 3M Super 33+ Black Electric tape.
    Last edited by Tony T; 2021-03-02 at 05:41.
    Tony
     SBTouch ♪ SBRadio ♬

  10. #110
    Senior Member
    Join Date
    Jan 2012
    Posts
    178

    2 weeks Experience with Script and Vonets

    Quote Originally Posted by POMdev View Post
    It looks like the automatic gateway detection does not have to be overridden, as it seems reliable.

    Looking at your logs, what stands out to me is, first of all, the very low signal level ...Link Quality:26/94 Signal level:-69 dBm Noise level:-96 dBm Tx excessive retries:34.... I might have this backwards, but it might be that "Franky24" has a higher signal level than "Franky2". That said, I mistakenly ran a radio with similar levels and it continued to work, albeit with more frequent resets. Also, your "failed" to "reset" time is only 7 seconds vs 19 seconds here, but your "reset" to "up" time is 28 seconds vs 19 seconds here. Perhaps the long up time delay has something to do with low signal strength.

    Since the music generally kept playing here, it seemed OK with the hard coded test frequency and failure delay values. Synchronization adds another level of complexity, and these values may not be optimum for that use case. I think your changes are entirely appropriate, others might consider doing the same.

    The script was giving the radio network stack software, and any other possible future lower level mitigating solutions, every opportunity to do recover before "pulling the rug out" from the radio and restarting everything. Regrettably, the script does not track how many times the radio recovers from a few missed pings. We could add a statistic for number of failed pings and longest ping failure for later transmission to evaluate the time out constants. Modifying these values could lead to an improvement.

    BTW, there are other ways to monitor failures than synchronization. The TCP logger ncat described in manual.txt seems the easiest, yielding a real time display and saved log of failures. I also use the excellent Nirsoft Wireless Network Watcher and NetworkConnectLog apps for an on-screen real time update (although brief interruptions may not be captured by the latter two).

    Thanks for the report.
    After 2 weeks testing this is my intermediate feedback:
    • both Vonets work very well, the 300n is more hot using the Logitech power supply than the 300g. Also the light-emitting diodes of the 300g are easier to cover by tape (opening the case) than the 300n
    • the Script works pretty well. I modified it in order to trigger a restart after 3 unsuccessful pings instead of 6 (too conservative for a healthy network environment). However if you play synchronized music, you will have two interruptions when the Radio restarts the WIFI.
    • While in synchronized environments the script might no be ideal, it helps to keep the Radio "alive and online", Thus I would recommend to include it into the next Community Firmware --> Ralphy. Without the script the radio turns offline and needs to be rebooted with neighboring WIFI-6...

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •