Home of the Squeezebox™ & Transporter® network music players.
Page 26 of 28 FirstFirst ... 162425262728 LastLast
Results 251 to 260 of 273
  1. #251
    Junior Member
    Join Date
    May 2011
    Posts
    15

    two questions

    I've plug in for community firmware in my Squeezebox server but how to install the latest radio firmware, baby_8.0.1_r16855.zip?

    How do I install wlanpoke?

    Thanks in advance,
    Stefan

  2. #252
    Quote Originally Posted by seth_space View Post
    For now it works for >95% and that is a lot more then i had. So thanks for that already.
    The webserver keeps crashing after one or two hours.
    You suggested some lines added to a script.
    Please explain a bit more in detail (pref a example) to find the cause.
    Does ">95%" mean occasional gaps in the music, or that you have to reboot the radio to restore a connection (hope it is not the latter)?

    See the new issues topic regarding the web server.

  3. #253
    No reboot necessary. Just sometimes gaps in the sound. I set the buffer on the max in LMS ( if it really has some effect, not sure)
    Strange the webserver is stable for hours now. Normally max 2 hours.

    But i will try the suggestions on github.

    not sure if i did i the right way

    it resulted in this putty reaction.
    login as: root
    root@192.168.1.228's password:

    This network device is for authorized use only. Unauthorized or improper use
    of this system may result in you hearing very bad music. If you do not consent
    to these terms, LOG OFF IMMEDIATELY.

    Ha, only joking. Now you have logged in feel free to change your root password
    using the 'passwd' command. You can safely modify any of the files on this
    system. A factory reset (press and hold add on power on) will remove all your
    modifications and revert to the installed firmware.

    Enjoy!
    # cd /etc/wlanpoke/ahttpd.sh -F -W 80
    -sh: cd: can't cd to /etc/wlanpoke/ahttpd.sh
    # /etc/wlanpoke/ahttpd.sh -F -W 80
    Unsupported argument: '-W'

    so without the W argument i get:

    # /etc/wlanpoke/ahttpd.sh -F
    /etc/wlanpoke/ahttpd.sh 0.1.1 3/16/2021 /root
    Killing process 26928

    And no webserver and a crashed radio network connection.. will reboot now.

    But i am very unsure about the locations of the echo arguments in the files. especially: in arequest.sh

    So a complete example file would be nice. I use the standard wlanpoke files.
    Last edited by seth_space; 2021-04-19 at 15:25.

  4. #254
    Quote Originally Posted by seth_space View Post
    ...
    But i am very unsure about the locations of the echo arguments in the files. especially: in arequest.sh
    So a complete example file would be nice. I use the standard wlanpoke files.
    OK. See the GitHub issue.

  5. #255
    Junior Member
    Join Date
    Apr 2021
    Posts
    3
    Quote Originally Posted by POMdev View Post
    I launched the script via ssh on the hardest-hit (54268s: Qr:67 Fr:12) machine here: /etc/wlanpoke/wlanpoke.sh -W slow -Wp 80 -Q 3 &, then "pounded" on it from a Firefox browser window, including odd URLs, but it kept working, even through seven quick resets followed by a full reset. (Firefox is pretty aggressive retrying unresponsive sites.) You frequently experience the server not working, and might be in a good position to fix this issue. Adding some logging would give a clue, e.g., adding several echo `date` "got (here)" > /var/log/w.log or something, then looking at the log to see where it stopped. If you want to debug this, the GitHub issues tab would be a good place to correspond. If not, there is always ssh cd /etc/wlanpoke ; ./awstats.sh to get the current report.

    BTW, your "Resets" entry does not show the quick reset despite Qr:1 Fr:1. That's odd. What is expected is Resets:1 @1618672526 -Gap+OK secs: +81,-41+-15,-15+1906,, where the 15s are the time taken by the quick reset. Another mystery. Thanks for testing all this.
    POMdev -- thank you for your work on the script!! It has allowed me to have the Radios mostly stay online over the last month. They still do drop off (even with the script, one lasts less than a day before requiring a power off/on). All interference is from neighbors. Internally wireless system has not changed in years. Swapping Radios will change the characteristics of their drops offs -- so problems are location based.

    Any suggested changes to script to make keep this one from going completely offline every 12 hours or so?
    Back1 wlanpoke.sh 0.8.4.1 4/6/2021 launched 2021-04-18_17:14:52 1618791291 Options:
    2021-04-18T18:58:10-0700 ( 18:58:10 up 1:43, load average: 1.58, 1.39, 1.27 )
    Ping 2s-1q6f Events, Fails[0..7] 6190s : Qr:0 Fr:2 Wr:0 Wc:0 [ 2078 4 0 0 0 0 2 0 ]
    Step 0:0, limit:results: [ 12:0,0, 18: 26: 37: 53: ] Wlan: Rate=24 Quality:25/94 level:-70 retries:0
    Gaps:6 @1618797482 -Gap+OK secs: +2505,-42+460,-3+837,-3+417,-3+80,-42+1135,-3+661,
    Resets:2 @1618797482 -Gap+OK secs: +2505,-42+1803,-42+1799,

    This Radio needs to be restarted after 2-3 days
    Kitchen wlanpoke.sh 0.8.4.1 4/6/2021 launched 2021-04-19_15:36:12 1618871772 Options:
    2021-04-20T06:08:06-0700 ( 06:08:06 up 14:32, load average: 1.22, 1.10, 1.01 )
    Ping 2s-1q6f Events, Fails[0..7] 52307s : Qr:0 Fr:70 Wr:0 Wc:0 [ 16827 20 0 0 0 0 70 0 ]
    Step 0:0, limit:results: [ 12:0,0,0,0,0,0,0,0,0,0,0,0 18: 26: 37: 53: ] Wlan: Rate=54 Quality:44/94 level:-51 retries:
    0
    Gaps:90 @1618924079 -Gap+OK secs: +121,-41+334,-42+815,-40+718,-41+547,-41+819,-40+822,-40+700,-41+809,-40+71,-3+654,-40
    +586,-42+682,-41+574,-41+694,-40+328,-41+326,-41+572,-41+253,
    Resets:70 @1618924079 -Gap+OK secs: +120,-42+334,-42+815,-40+718,-41+547,-41+818,-41+822,-40+700,-41+809,-40+728,-40+586
    ,-42+682,-41+574,-41+694,-40+328,-41+326,-41+572,

    These two stay online for about a week before needing to be restarted:
    Floater wlanpoke.sh 0.8.4.1 4/6/2021 launched 2021-04-17_17:13:02 1618704782 Options:
    2021-04-20T06:07:38-0700 ( 06:07:38 up 2 days, 12:54, load average: 1.22, 1.18, 1.10 )
    Ping 2s-1q6f Events, Fails[0..99] 219263s : Qr:0 Fr:101 Wr:3 Wc:0 [ 72114 44 2 1 0 0 64 0 13:1 18:1 24:1 34:1 36:1
    99:3 ]
    Step 0:0, limit:results: [ 12:0,0,0,0,0,0,0,0,0,0,0 18:18,18,18,18,18,18, 26:26,0,26,26,26,6,26, 37:36,36,0,0,36,4, 53:0
    ,52,52,14,52,52,52,52 ] Wlan: Rate=36 Quality:72/94 level:-23 retries:0
    Gaps:119 @1618924045 -Gap+OK secs: +1081,-42+3716,-42+2655,-42+809,-41+1506,-41+904,-40+2454,-41+1310,-42+7559,-43+2280,
    -42+2660,-41+159,-3+25,-3+118,-3+444,-3+312,-3+524,-3+87,
    Resets:72 @1618924045 -Gap+OK secs: +1081,-42+3716,-42+2655,-42+809,-41+1506,-41+903,-41+2454,-41+1310,-42+7559,-43+2280
    ,-42+2660,-41+2041,-41+2423,-44+2555,-41+5338,

    Back2 wlanpoke.sh 0.8.4.1 4/6/2021 launched 2021-04-17_11:17:34 1618683454 Options:
    2021-04-20T06:07:42-0700 ( 06:07:43 up 2 days, 19:02, load average: 1.33, 1.24, 1.18 )
    Ping 2s-1q6f Events, Fails[0..7] 240601s : Qr:0 Fr:145 Wr:1 Wc:0 [ 79113 31 0 0 0 0 145 0 ]
    Step 0:0, limit:results: [ 12:0,0,0,0,0,0,0,0,0,0,0,0 18: 26: 37: 53: ] Wlan: Rate=36 Quality:31/94 level:-64 retries:
    0
    Gaps:176 @1618924055 -Gap+OK secs: +854,-42+1533,-42+939,-41+937,-42+1432,-42+848,-42+1306,-43+1314,-40+3886,-41+2777,-4
    1+943,-41+943,-41+1919,-40+1429,-42+2286,-42+1796,-42+1183,-41+1844,
    Resets:145 @1618924055 -Gap+OK secs: +854,-42+1533,-42+939,-41+937,-42+1432,-42+848,-42+1306,-43+1313,-41+3886,-41+2777,
    -41+943,-41+943,-41+1919,-40+1429,-42+2286,-42+1796,

  6. #256
    Quote Originally Posted by jc77 View Post
    Any suggested changes to script to make keep this one from going completely offline every 12 hours or so? [Back1] ...
    This Radio needs to be restarted after 2-3 days [Kitchen] ...
    These two stay online for about a week before needing to be restarted: [Floater & Back2] ...
    Wow, this is a lot. Thanks for the report. This is the first report of a radio requiring a reboot to reconnect since a quick reset related bug caused the script to drop out last month, and you have 4 of them!. There is something happening that is out of the ordinary in your environment. Here, the only outages have been from hardware (power supply connector) failures.

    To troubleshoot this, use the -d /etc/log/ to save the log files where they will not be lost after a reboot, and examine the files as soon as you notice the radio off. Generally, the script will keep trying to reconnect forever, but it limits each trial to a specified amount of time before trying again. If it tries again too soon, a possible recovery is aborted, a new cycle begins, and the radio does not recover. This was a problem with weak signals and heavy interference in earlier versions, where the retry time was fixed at a relatively short time. Later versions like you are using have an adaptive retry time that has an upper limit. You might be hitting that upper limit. On the other hand, something else may be happening (e.g., the script may be exiting), so looking at the logs after a reboot is important. You can zip them and upload them into a new GitHub issue.

    None of your radios have any Options showing. The 'slow' web server is recommended for monitoring. Change launch in /etc/init.d/rcS.local to:
    /etc/wlanpoke/wlanpoke.sh -W slow -d /etc/log/ &
    and check out http://Back1:8080 (use Back1's IP address if needed). Also, ncat is handy. If you are not using it, disable tcp logging with the -x option.

    Of your radios, only "Floater" is showing extended full reset recovery times (possibly from going out of range of the access point) and it stays on for a week. All the others recover right away.
    You can increase this time by editing the script (no command line option yet) variables FRWaitSecsMax and FRWaitStepPct, increasing one or both.

    Your 'Back1' radio reports a signal level of -70 dBm. It may be just out of range of the AP given your environment. "Floater" had a very high signal level at the time of measurement, but perhaps that unit had also been in the hinterlands for a while, which would explain the repeated failure of the full resets to work, as Floater recovered when brought into a strong signal area. (Does Back1 recover without rebooting when moved into a high signal area?)

    Back1 is failing the most often, so it makes sense to concentrate on this unit first, and perhaps Floater as well, as it exhibits the interesting increasing recovery time steps, which might also being experienced by Back1, but the logs are lost.

    It would also be useful for you to track the radios as a whole to see about time of day phenomena. The excellent free Wireless Network Watcher and NetworkConnectLog from Nir Software on your Windows pc will capture the status of the devices on your LAN. This would give you an important "last seen" time to correlate with your log files. And you might try the latest software in the development branch to see if a quick reset is effective in your environment, and to improve the Reset report. Still, your 0.8.4.1 should work as is.

  7. #257
    Junior Member
    Join Date
    Apr 2021
    Posts
    3
    Quote Originally Posted by POMdev View Post
    To troubleshoot this, use the -d /etc/log/ to save the log files where they will not be lost after a reboot, and examine the files as soon as you notice the radio off.
    They are all logging to a server via NCAT, so I have those logs. I'll add the "-d /etc/log" as well.

    Quote Originally Posted by POMdev View Post
    If it tries again too soon, a possible recovery is aborted, a new cycle begins, and the radio does not recover. This was a problem with weak signals and heavy interference in earlier versions, where the retry time was fixed at a relatively short time. Later versions like you are using have an adaptive retry time that has an upper limit. You might be hitting that upper limit.
    I was previously using version 0.6.3.1 (with a fix noted in 2/23/21 post) and 'Back1' seemed to stay online for several days vs. half a day. However, this is just based on my memory.

    Quote Originally Posted by POMdev View Post
    None of your radios have any Options showing. The 'slow' web server is recommended for monitoring.
    I set "WSERVER="slow"" in the script. The details I posed here are grabbing the RawFails from each Radio web server.

    Quote Originally Posted by POMdev View Post
    Of your radios, only "Floater" is showing extended full reset recovery times (possibly from going out of range of the access point) and it stays on for a week.
    Floater is about 15 inches from the AP, so it should not be going out of range of the AP....

    Quote Originally Posted by POMdev View Post
    Your 'Back1' radio reports a signal level of -70 dBm. It may be just out of range of the AP given your environment. "Floater" had a very high signal level at the time of measurement, but perhaps that unit had also been in the hinterlands for a while, which would explain the repeated failure of the full resets to work, as Floater recovered when brought into a strong signal area. (Does Back1 recover without rebooting when moved into a high signal area?)
    'Floater' is about 15 inches from the AP and should have great signal. 'Back1' and 'Back2' are in a poor signal area (but up until the last year with the all these drops, had no issues). 'Kitchen' has a good signal.

    Quote Originally Posted by POMdev View Post
    Back1 is failing the most often, so it makes sense to concentrate on this unit first, and perhaps Floater as well, as it exhibits the interesting increasing recovery time steps, which might also being experienced by Back1, but the logs are lost.
    I've moved 'Back1' temporarily nearby to 'Floater'. Based on earlier tests, 'Back1' should stay online longer now. I can also move 'Back1' to its original location for more testing.

    Quote Originally Posted by POMdev View Post
    And you might try the latest software in the development branch to see if a quick reset is effective in your environment, and to improve the Reset report. Still, your 0.8.4.1 should work as is.
    I updated Radios to the Community build firmware a few weeks ago \, and it made no difference in reducing the issue.

  8. #258
    Junior Member
    Join Date
    Apr 2021
    Posts
    3
    Quote Originally Posted by POMdev View Post
    To troubleshoot this, use the -d /etc/log/ to save the log files where they will not be lost after a reboot,
    I added this to each of the Radios. The directory /etc/log was created, but nothing was created in the directory. AND, in eight hours over night every one of the Radios went lost wireless and I have to reboot to get them back.

    What information should I grab from NCAT -- since nothing was saved in the /etc/log directory?

  9. #259
    Quote Originally Posted by jc77 View Post
    I added this to each of the Radios. The directory /etc/log was created, but nothing was created in the directory. AND, in eight hours over night every one of the Radios went lost wireless and I have to reboot to get them back.
    What information should I grab from NCAT -- since nothing was saved in the /etc/log directory?
    Talk about going from bad to worse. Was there any information in ncat? The script is supposed to exit with an error message if it cannot write its status and log files. This might happen if the "-d /etc/log/" setting is missing the trailing '/', although those files might be in the /etc folder with names preceded by "log" such as "logwlanerr.log", "logfping.txt", and so on. The script is quite weak on parameter validation, even with 1548 lines of code (how did that happen?). If the script exits, the radios are on their own.

    The first thing is to get the logging to work. Try launching from the ssh terminal, and observe the messages, and the various log and status files. You may want to increase the log level. Check the permissions on /etc/log. The script runs as root, so they should be ok, but ...

  10. #260
    Senior Member
    Join Date
    May 2017
    Posts
    779
    15 inch is pretty close to ap, try 6 feet. What brand/type ap are you using, has this changed? Are neighbors close by?
    SqueezeBoxes: 1x Transporter (Living room) 1x SB2 (shed), 1x Radio (Kitchen), 1x Boom (Dining room), 1x piCorePlayer (jacuzzi), 1x piCorePlayer (Garden) 1x OSMC + Squeezelite (Movie room), 1x Touch (Study 2), few spare unit's (SB2, SB3, Boom, Touch)
    Server: LMS on Pi3B+ 8.1.2 on PcP 7.0.1
    Network: Draytek, Netgear Smart Switch 24p, Ubiquiti PoE, 3x Ubiquity

Posting Permissions

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