Home of the Squeezebox™ & Transporter® network music players.
Page 12 of 14 FirstFirst ... 21011121314 LastLast
Results 111 to 120 of 139
  1. #111
    Junior Member
    Join Date
    Feb 2016
    Posts
    8
    Thanks, trying this !
    I was getting ready to buy a new Radio but it seems the new one might get the issue...

    I copied the zip using WinSCP
    Also I redirected the output to /var/log to get some logging without having to run nc on the pi.
    /etc/wlanpoke/wlanpoke.sh -x > /var/log/wlanpoke.log &

    Will report back !

    Edit : Ah sorry it seems there are plenty of logs already :-)
    Last edited by gomi; 2020-09-19 at 11:51.

  2. #112
    Junior Member
    Join Date
    Aug 2020
    Posts
    21

    Today's Update & Watching the Radio

    Quote Originally Posted by gomi View Post
    Thanks, trying this !
    I was getting ready to buy a new Radio but it seems the new one might get the issue...
    I copied the zip using WinSCP
    Also I redirected the output to /var/log to get some logging without having to run nc on the pi.
    /etc/wlanpoke/wlanpoke.sh -x > /var/log/wlanpoke.log &
    Will report back !
    Edit : Ah sorry it seems there are plenty of logs already :-)
    I don't think a new radio would be immune to the wireless connectivity issue. I'm using squeezelite and jive on two pi zeros, and they have been reliable. I was integrating Bluetooth, line level audio input streaming, and re-enabling the image viewer screen savers when I was interrupted by this project.

    Could you post your instructions for using WinSCP to upload the software so I can put it into the manual?

    I don't know how much storage is reasonable for log files to occupy on the radio. Then, they have to be uploaded for viewing. It was quicker and easier to stream the logs to a more capable machine. This is, hopefully, temporary use software. Also, it is important to run the software at boot up, which means you don't see the output except using 'tail -f', and until storage is exhausted.

    By the way, 'nc' and 'tail' are so much fun to watch. You can fiddle with the log level to get more or less console output, which is intended for debugging the wlanpoke script, not the radio. Without 'nc' you will miss the circular buffer prior events display, as it is not echoed to the console. (Perhaps it should be.) Would it be helpful to have a cookbook Windows solution for remote logging and display? You can run a reasonable Ubuntu in Windows 10, and have terminal messages scrolling up in a desktop window as an amusement. Of course, for modifying and debugging wlanpoke, you need to launch from the terminal shell, and a high log level.

    I have attached a recent t21a_2020-09-19_16-54_tail_did.zip log file from here as captured by nc -l -k -p 1121 >> t21a.log & and displayed by tail -f t21a.log &. Looking at the log file, during this brief time span, there were several disconnections. The signal levels were excellent. The bit rates of a couple declined to 5.5 Mb/s and 1 Mb/s at the time of ping failure. I remember these values falling earlier than in the last 2 seconds, but that is not shown here. AFAICT, things seem to be going well until suddenly, they aren't.

    Not wanting to make a habit of daily releases [sic], but the log file was produced by today's 0.5.1 update, wlanpoke.0.5.1.zip. It addresses several bugs and includes additional enhancements for troubleshooting. The 6 radios have been running for 4 days now on various versions of the software without other intervention.
    Last edited by POMdev; 2020-09-19 at 16:33.

  3. #113
    Junior Member
    Join Date
    Feb 2016
    Posts
    8
    OK dunno if it's corrected in 0.5.1 but got an issue in 0.5.0
    Seems the scripts restarted at 22:55

    Code:
    wlanpoke 0.5.0 9/18/2020
    Running as 720
    2020-09-19T22:55:14+0200 Stopping and restarting wlan...
    ..unloading all
    Setting eth1 macaddr: 00:04:20:2C:36:4F
    Load Board Data from /lib/atheros/calData_ar6102_15dBm.bin
    Updating MAC address
    BMI Write Memory (address: 0x502400, filename: /lib/atheros/athwlan.bin)
    BMI Write Memory (address: 0x52d8bc, filename: /lib/atheros/data.patch.hw2_0.bin)
    BMI Write Memory (address: 0x500418, value: 0x52d8bc)
    BMI Bit-Wise (OR) modify Register (address: 0x500410, orig:0x0, new: 0x1,  mask:0x1)
    BMI Done
    Restarting dhcp
    udhcpc (v1.18.2) started
    Sending discover...
    Performing a DHCP renew
    Sending discover...
    Sending select for 192.168.1.54...
    Lease of 192.168.1.54 obtained, lease time 86400
    adding dns 192.168.1.1
    2020-09-19T22:55:29+0200 Waiting for successful ping...
    And it seems it worked beacause the Radio is responding.
    But I have a huge wlanerr.log of 3 MB, with a new line every 2/3 secs

    Code:
    2020-09-20T12:44:22+0200 Marlin failed reset 2020-09-19T22:55:14+0200 up 2020-09-19T22:55:29+0200 eth1 AR6000 802.11g ESSID:"SynGom" Mode:Managed Frequency:2.462 GHz Access Point: 00:11:32:72:5F:59 Bit Rate=54 Mb/s Tx-Power=15 dBm Sensitivity=0/3 Retry:on Encryption key:off Link Quality:25/94 Signal level:-70 dBm Noise level:-96 dBm Rx invalid nwid:0 Rx invalid crypt:15 Rx invalid frag:0 Tx excessive retries:29 Invalid misc:0 Missed beacon:0 PING 192.168.1.1 (192.168.1.1): 56 data bytes 64 bytes from 192.168.1.1: seq=0 ttl=64 time=2.943 ms --- 192.168.1.1 ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max = 2.943/2.943/2.943 ms
    2020-09-20T12:44:25+0200 Marlin failed reset 2020-09-19T22:55:14+0200 up 2020-09-19T22:55:29+0200 eth1 AR6000 802.11g ESSID:"SynGom" Mode:Managed Frequency:2.462 GHz Access Point: 00:11:32:72:5F:59 Bit Rate=54 Mb/s Tx-Power=15 dBm Sensitivity=0/3 Retry:on Encryption key:off Link Quality:25/94 Signal level:-70 dBm Noise level:-96 dBm Rx invalid nwid:0 Rx invalid crypt:15 Rx invalid frag:0 Tx excessive retries:29 Invalid misc:0 Missed beacon:0 PING 192.168.1.1 (192.168.1.1): 56 data bytes 64 bytes from 192.168.1.1: seq=0 ttl=64 time=8.293 ms --- 192.168.1.1 ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max = 8.293/8.293/8.293 ms
    2020-09-20T12:44:28+0200 Marlin failed reset 2020-09-19T22:55:14+0200 up 2020-09-19T22:55:29+0200 eth1 AR6000 802.11g ESSID:"SynGom" Mode:Managed Frequency:2.462 GHz Access Point: 00:11:32:72:5F:59 Bit Rate=54 Mb/s Tx-Power=15 dBm Sensitivity=0/3 Retry:on Encryption key:off Link Quality:26/94 Signal level:-69 dBm Noise level:-96 dBm Rx invalid nwid:0 Rx invalid crypt:15 Rx invalid frag:0 Tx excessive retries:29 Invalid misc:0 Missed beacon:0 PING 192.168.1.1 (192.168.1.1): 56 data bytes 64 bytes from 192.168.1.1: seq=0 ttl=64 time=35.303 ms --- 192.168.1.1 ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max = 35.303/35.303/35.303 ms
    2020-09-20T12:44:30+0200 Marlin failed reset 2020-09-19T22:55:14+0200 up 2020-09-19T22:55:29+0200 eth1 AR6000 802.11g ESSID:"SynGom" Mode:Managed Frequency:2.462 GHz Access Point: 00:11:32:72:5F:59 Bit Rate=54 Mb/s Tx-Power=15 dBm Sensitivity=0/3 Retry:on Encryption key:off Link Quality:26/94 Signal level:-69 dBm Noise level:-96 dBm Rx invalid nwid:0 Rx invalid crypt:15 Rx invalid frag:0 Tx excessive retries:29 Invalid misc:0 Missed beacon:0 PING 192.168.1.1 (192.168.1.1): 56 data bytes 64 bytes from 192.168.1.1: seq=0 ttl=64 time=5.020 ms --- 192.168.1.1 ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max = 5.020/5.020/5.020 ms
    2020-09-20T12:44:33+0200 Marlin failed reset 2020-09-19T22:55:14+0200 up 2020-09-19T22:55:29+0200 eth1 AR6000 802.11g ESSID:"SynGom" Mode:Managed Frequency:2.462 GHz Access Point: 00:11:32:72:5F:59 Bit Rate=54 Mb/s Tx-Power=15 dBm Sensitivity=0/3 Retry:on Encryption key:off Link Quality:26/94 Signal level:-69 dBm Noise level:-96 dBm Rx invalid nwid:0 Rx invalid crypt:15 Rx invalid frag:0 Tx excessive retries:29 Invalid misc:0 Missed beacon:0 PING 192.168.1.1 (192.168.1.1): 56 data bytes 64 bytes from 192.168.1.1: seq=0 ttl=64 time=6.277 ms --- 192.168.1.1 ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max = 6.277/6.277/6.277 ms
    2020-09-20T12:44:36+0200 Marlin failed reset 2020-09-19T22:55:14+0200 up 2020-09-19T22:55:29+0200 eth1 AR6000 802.11g ESSID:"SynGom" Mode:Managed Frequency:2.462 GHz Access Point: 00:11:32:72:5F:59 Bit Rate=54 Mb/s Tx-Power=15 dBm Sensitivity=0/3 Retry:on Encryption key:off Link Quality:26/94 Signal level:-69 dBm Noise level:-96 dBm Rx invalid nwid:0 Rx invalid crypt:15 Rx invalid frag:0 Tx excessive retries:29 Invalid misc:0 Missed beacon:0 PING 192.168.1.1 (192.168.1.1): 56 data bytes 64 bytes from 192.168.1.1: seq=0 ttl=64 time=2.955 ms --- 192.168.1.1 ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max = 2.955/2.955/2.955 ms
    Any clue ?

    Concerning WinSCP
    1 . Install
    2 : Launch, in login choose protocol SCP, use to correct ip address user root pass 1234
    3 : Answer yes to the 2 questions the questions
    4 : Enjoy

    Hope it helps,
    Name:  winscp.png
Views: 212
Size:  7.9 KBName:  winscp2.png
Views: 213
Size:  30.6 KB

  4. #114
    Junior Member
    Join Date
    Feb 2016
    Posts
    8
    I think the problem is because I use -x so TCPLOG is not set, we don't get in the test if [[ -n TCPLOG ]] and DTRST is never reset, so we keep logging

    Code:
      if [[ -n "$DTRST" ]]; then
          # Append to the error log.
          echo $DTOK $HOSTNAME.$IPLAST"_"$VerSign failed $DTNG reset $DTRST up $DTEND `iwconfig $IFACE` `cat $PINGLOG` >> $ERRLOG
          if [[ -n TCPLOG ]]; then
            if [[ "$LOGLEVEL" -gt 3 ]]; then
              echo "Sending wlanerr.log to $TCPLOG $TCPPORT"
            fi
            #if cat /etc/wlanerr.log | nc -w 3 $TCPLOG $TCPPORT     # 0.4.2: log no longer in /etc/, fails to send logs...!!!
            if cat "$ERRLOG" | nc -w 3 $TCPLOG $TCPPORT
            then
              if [[ "$LOGLEVEL" -gt 3 ]]; then
                echo "Send Successful"
              fi
              DTRST=
              DTEND=
              UploadStats

  5. #115
    Junior Member
    Join Date
    Aug 2020
    Posts
    21
    [QUOTE=gomi;989248]I think the problem is because I use -x so TCPLOG is not set, we don't get in the test if [[ -n TCPLOG ]] and DTRST is never reset, so we keep logging

    Right-o. No, it is not fixed in 0.5.1. And I was hoping to not do an update today. But here I am, adding a real log file. I am working on keeping the log file to a known reasonable size, and this is not done. But for now, you can add he following - untested - code:
    Code:
          if [[ -n TCPLOG ]]; then
         ... not shown ...
          else		# 0.5.2: handle no TCPLOG case: stop logging to the error log!
            DTRST=			
            DTEND=
          fi
    Looking forward to yet another release sooner rather than later.

    BTW, another way to handle the situation is to let the TCP send fail by removing the -x option. That way, the control is from the desktop, running or not a server, not the radio. But the code had a horrible bug with the -x option, one out of many, many to be found. Thank you!

  6. #116
    Junior Member
    Join Date
    Aug 2020
    Posts
    21

    Local Logging and AP Scan Results

    The 6 radios here have remained operational since 9/15, over 5 days now.

    The latest release adds support for local log files, handy for those who don't implement a tcp logging server (e.g., 'nc -l -k -p 1121 >> 1121.log &'). These files are by default limited to 50 KB in size, with 4 previous rotated versions, consuming 250 KB of storage on the radio. Several new options for managing the log files have been added.

    Although the core purpose of the software is keeping the radios connected, another important purpose is to aid in troubleshooting connections as they fail. An additional report of access points scanned by the wireless has been included to test the theory that one reason for failure, or an indicator of potential imminent failure, is that the radio sometimes does not include its connected AP in its periodic scan results. You can examine the upload and now the local log to see if there is a correlation, or not.

    Those inclined to investigate can try to add additional debug info to the GetStats () function, which is called every 2 seconds to add entries to a circular buffer, which is saved to a local log, and later transmitted upon reconnection.

    The latest version wlanpoke.0.6.0.zip is here. I hope this is helping.

  7. #117
    Junior Member
    Join Date
    Feb 2016
    Posts
    8
    Hi,

    Updated on 0.6, was running working perfect on 0.5 ish.

    I was ready to buy a new Radio and was looking some craigslist, the script saved it, thanks so much !

    Maybe this deserves its own thread so it is more easily found and solved by all the "My Squeeze Radio Wifi keeps dropping" owners !

    The biglog issues didn't happen again, maybe it was a side effect of me being on static IP and the script activating DHCP.

    Anyways now everything in DHCP, it's running smooth, so no more dreaded red Wifi signal, and no more alarm.mp3 on the morning wakeups !

    Thanks again !

  8. #118
    Junior Member
    Join Date
    Aug 2020
    Posts
    21
    I am glad to hear your radio doing well. Please keep us posted, especially if the radio loses its connection and does not recover. And bug reports are always welcome. You can help out by checking your logs, you might stumble upon the clue that cracks the case!

    Quote Originally Posted by gomi View Post
    Hi,
    ...
    I was ready to buy a new Radio and was looking some craigslist, the script saved it, thanks so much !
    ...
    Maybe this deserves its own thread so it is more easily found and solved by all the "My Squeeze Radio Wifi keeps dropping" owners !...
    I believe a 'new' radio would have the same problem in your environment. I believe the issue is caused by interference or incompatibility of some sort. Perhaps a new radio service at a frequency near or in the shared low WiFi band, a proliferation of devices using access points or ad-hoc networks for setup that never are, updates to router software that are somehow incompatible with SB wireless as configured, etc.

    I think this topic (thread?) is for building firmware, which is important. I would like to see a WiFi troubleshooting topic. Perhaps it could possibly double as a support thread for this band-aid mitigation and troubleshooting software, although a separate topic might be better. Someone who has been around longer can decide what to do about topics.

  9. #119
    Junior Member
    Join Date
    Sep 2020
    Posts
    1

    How to install his own 7.8 image into the SqueezeboxRadio

    Hi!

    I finally success to build the baby_7.8.0_r16796.bin with my docker (ubuntu 12.04) configuration, with some patches...
    Now i don't know how to flash my devices with this images.

    I've read about copying it into the cache/update/ folder of my lms ? What's the right way to do this?
    Thanks!

  10. #120
    Junior Member
    Join Date
    Dec 2018
    Posts
    8
    Quote Originally Posted by hfongarnand View Post
    I've read about copying it into the cache/update/ folder of my lms ? What's the right way to do this?
    Ralphy explained it into this post: https://forums.slimdevices.com/showt...l=1#post987818

    This is what I do for my LMS Server.

    # 1. On the LMS Server, backup the old stable firmware 7.7.3 R16676 (thank you mrw), e.g.:
    cp /var/lib/squeezeboxserver/cache/updates/baby_7.7.3_r16676.bin /var/lib/squeezeboxserver/cache/updates/baby.version ~/backup/lms/7.7.3_r16676/

    # 2. On the build machine, prepare & copy the newly built firmware to the LMS server, e.g.:
    unzip tmp-baby/deploy/images/baby_7.8.0_rxxxxx.bin -d tmp-baby/deploy/images/ jive.version
    mv tmp-baby/deploy/images/jive.version tmp-baby/deploy/images/baby.version
    scp tmp-baby/deploy/images/baby_7.8.0_rxxxxx.bin tmp-baby/deploy/images/baby.version $LMSSERVER:~

    # 3. On the LMS server, copy the firmware files and restart the LMS server, e.g.
    sudo cp ~/baby_7.8.0_rxxxxx.bin ~/baby.version /var/lib/squeezeboxserver/cache/updates
    sudo chown squeezeboxserver:nogroup /var/lib/squeezeboxserver/cache/updates/baby_7.8.0_rxxxxx.bin
    sudo service logitechmediaserver restart

    # 4. Restart the radio(s) and you should be prompted for the upgrade...
    Last edited by cris-; 2020-09-25 at 10:34. Reason: Added chown command...

Posting Permissions

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