RadioReference on Facebook   RadioReference on Twitter   RadioReference Blog
 

Go Back   The RadioReference.com Forums > Computer Aided Monitoring and Programming > Streaming / Broadcasting / Audio Recording


Streaming / Broadcasting / Audio Recording - Interested in putting your scanner online for others to hear? Want to listen to other radios on the internet. This forum is here for you to discuss these topics related to streaming scanners online.

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
  #261 (permalink)  
Old 09-03-2017, 10:36 PM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Dec 2016
Location: Milpitas, CA
Posts: 231
Default

I know this is incredibly complex but working for me so far. Let me know if I left out any bash files. Also this requires a level of expertise to create the supporting files and assigning the appropriate access levels.

Last edited by JACK26; 09-03-2017 at 11:03 PM..
Reply With Quote
Sponsored links
  #262 (permalink)  
Old 09-07-2017, 8:27 PM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Dec 2016
Location: Milpitas, CA
Posts: 231
Default

Update: Still changing the restart script.
Raspberry Pi bash code has got to be the most unstable programming environment I've ever dealt with. One minute everything is working fine and the next day it doesn't work.
Latest problem is that cron no longer likes something in my bash script files and refused to run the files.
Googled the problem and apparently there is a problem with the cron environment variables versus running the .sh files in a command terminal window.

Long story short, I've abandoned using cron to rely on the restart code and now running everything inside a while loop with a sleep command. Works well so far but will see how it goes in the next few days.

This is the simple while loop I'm using :

#!/bin/bash
trap "exit" INT
while :
do
trap command SIGINT
sleep 20
/etc/PIDSTREAM/checkstream1.sh
done

Will post the details once I see it disconnect and reconnect a few times on it's own. Trying to simulate a disconnect is not really possible since it happens between my internet connection and the Broadcastify servers.

PS I think my problems are related to recent updates by the Raspberry consortium updates from running this:

sudo apt-get dist-upgrade

Safer to only use:
sudo apt-get upgrade

Also be careful trying to upgrade to Raspberry Pi "stretch" that has the potential to really mess up working apps and ruin your day .

Last edited by JACK26; 09-07-2017 at 9:32 PM..
Reply With Quote
  #263 (permalink)  
Old 09-10-2017, 6:20 PM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Dec 2016
Location: Milpitas, CA
Posts: 231
Default

Update: Thought I had working code to completely kill and restart the processes independently for each feed. Wrote all the script to kill every possible related process and then restart them. I can simulate a disconnect (somewhat) by killing one of the sox instances and everything seemed to work to reconnect.

When I went live with the code it would sometimes take 1/2 hour for the code to finally reconnect after a last resort branch to a reboot. So I finally took the time to step through the code a few lines at a time and it turns out the wifi connection was locking up. I'm using an RPI3 which has a built in wifi but I don't think it's the hardware as DC31 has an RPI2 which uses an external wifi stick and also had the disconnects.

Anyway I think I've solved that problem by resetting the wifi chips with the following code at the start of the first checkstreamn.sh file:

if ! [ "$(ping -c 1 10.0.0.1)" ]; then
sudo ifdown wlan0
sudo ifup wlan0
echo "Wifi reset." >> /etc/PIDSTREAM/start1.log
date >> /etc/PIDSTREAM/start1.log
fi

10.0.0.1 is my main routers address. All the other code I wrote is also needed to reset everything without rebooting too so not a waste of time.

Not sure why the wifi is locking up. When it happens I can log onto my router and the rpi3's wifi still has an active connection but no communications.
Was able to trouble shoot the problem as I'm using hard wired lan (eth0) for ssh and VNC and it doesn't seem to have the lock up problem. The broadcastify feeders only use wifi (wlan0).

Will post the rest of the code after I see it working for awhile.

Last edited by JACK26; 09-10-2017 at 8:19 PM..
Reply With Quote
  #264 (permalink)  
Old 09-10-2017, 8:45 PM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Dec 2016
Location: Milpitas, CA
Posts: 231
Default

To those who are still interested these are my feeds live with rpi3, 2 rtl-sdr sticks and complex auto restart algorithm :

https://www.broadcastify.com/listen/feed/25781
https://www.broadcastify.com/listen/feed/23831
Reply With Quote
  #265 (permalink)  
Old 09-11-2017, 7:18 PM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Dec 2016
Location: Milpitas, CA
Posts: 231
Default

Update: Improved uptime since integrating the wifi online status check but so far no logged events of a witi reset. So the witi disconnect events are probably not that common but when they do happen, the check and reset code is needed to recover.

So far Ive reduced the maximum down time from about 20-30 minutes to 5-8 minutes so making progress.
I need to improve the code with while loops to make sure each process is killed and restarted successfully.

One thing, apparently the rpi3 wifi had a lot of problems with dropping off the network due to power management enabled by default. They did fix most of the problems since then and I was not aware of the problem until now. Power management is still enabled by default and puts the wifi to sleep after some amount of inactivity. Anyway to disable power management to insure that the wifi never goes to sleep add the following line to the /etc/network/interfaces file using nano.

sudo iw dev wlan0 set power_save off

I also added this to /etc/rc.local
sudo iwconfig wlan0 power off

This probably also affects rpi2 with external usb wifi stick and not hardware related.

Last edited by JACK26; 09-11-2017 at 7:23 PM..
Reply With Quote
Sponsored links
  #266 (permalink)  
Old 09-13-2017, 8:12 PM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Dec 2016
Location: Milpitas, CA
Posts: 231
Default

Making progress with raspberry pi restart solution. There was a lot of bugs in the initial restart code.
The solution is so complicated that it's no longer practical to post the code here or any other similar forum.
My plan is to post all the bash files on a google drive and invite beta testers who are also interested to test it out.
Reply With Quote
  #267 (permalink)  
Old 09-13-2017, 10:30 PM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Dec 2016
Location: Milpitas, CA
Posts: 231
Default

Link to the code so far for those who are interested.
https://drive.google.com/open?id=0Bx...HM0ZUNWWG1FeFU

ps: If you're wondering why I am not submitting to a simple reboot, it's because I have 2 feeds and they don't always loose connection at the same time. Also the end goal is to have the raspberry pi working as well as scannercast for clean reconnects within a few seconds.

Last edited by JACK26; 09-14-2017 at 12:20 AM..
Reply With Quote
  #268 (permalink)  
Old 09-15-2017, 1:56 AM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Dec 2016
Location: Milpitas, CA
Posts: 231
Default

Update: Error in the killpids1.sh and killpids2.sh. Replaced the >= operators with >.
Apparently the bash version I'm using expects a unary operator there.

The disconnect events I'm targeting are rare and have no way to duplicate it so hours between disconnects and may still take some more time to fine tune the code.
Reply With Quote
  #269 (permalink)  
Old 09-15-2017, 2:28 AM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Dec 2016
Location: Milpitas, CA
Posts: 231
Default

Never mind. Will update the google drive with updates. Let me know if you need any help .

Last edited by JACK26; 09-15-2017 at 2:38 AM..
Reply With Quote
  #270 (permalink)  
Old 09-15-2017, 4:33 AM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Dec 2016
Location: Milpitas, CA
Posts: 231
Default

If any of you admins on the Broadcastify side that can help me by creating artificial server disconnects, please pm me
Reply With Quote
  #271 (permalink)  
Old 09-15-2017, 4:59 AM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Dec 2016
Location: Milpitas, CA
Posts: 231
Default

I don't know what just happened but now my rpi3 is unresponsive. If an admin did that it would be nice to coordinate it next time

Update back online.

Last edited by JACK26; 09-15-2017 at 5:42 AM..
Reply With Quote
  #272 (permalink)  
Old 09-17-2017, 2:08 AM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Dec 2016
Location: Milpitas, CA
Posts: 231
Default

Update: Still struggling with a working restart algo. Deleted all the files I previously posted on the google drive but says that it's still accessible by others. Since then I've made a lot of changes to allow faster reboots after failed attempts to reconnect the feed to Broadcastify.

Not sure why the code is not working to disconnect and reconnect to Broadcastify without rebooting and still researching that.
So far I think I am killing all the related processes for a specific feed, i.e. ezstream, sox, rtl_fm and the the parent feed.
But for some reason the restart code doesn't become active with traffic on the target port and sits quiet.

Any advice from anyone is welcome .

PS: Sometimes the algo works and sometimes not, so not sure what is not always working.

Last edited by JACK26; 09-17-2017 at 3:21 AM..
Reply With Quote
  #273 (permalink)  
Old 09-17-2017, 2:50 AM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Dec 2016
Location: Milpitas, CA
Posts: 231
Default

Updated link with latest script files:
https://drive.google.com/drive/folde...FU?usp=sharing
Reply With Quote
  #274 (permalink)  
Old 09-19-2017, 1:21 AM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Dec 2016
Location: Milpitas, CA
Posts: 231
Default

Just updated the code on the google drive again. Several files updated to consolidate the script.

Still a problem to duplicate the real world disconnect events and so not confident this code covers all the events yet.
Reply With Quote
  #275 (permalink)  
Old 09-20-2017, 12:13 AM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Dec 2016
Location: Milpitas, CA
Posts: 231
Default

Welll... the updated code seems to be working as expected and successfully restarted both feeds separately as needed a couple of times over night.
Bad news is that rpi eventually hangs and stops trying to reconnect and stops running the checkstream code for some reason. When it happens it locks out the remote ssh and VNC access. I can still see the rpi on my router as connected and this last time it happened I was able to get return pings from the rpi on the local area net. Other times when it hangs, it doesn't respond to pings.

My feeling is that this problem of not able to reconnect and hangs is related to the original problem of the rpi to maintain a connection using rtl_fm and/or Ezstream for more than about 9 hours.
I don't think it's a hardware problem or a problem with my restart code.

PS: My restart code has a high level requirement before a reboot and the rpi sometimes locks up before that condition is satisfied. It only takes 4 tries for a reboot to be triggered so something deeper with the rpi is happening that causes the lock up.

Last edited by JACK26; 09-20-2017 at 12:26 AM..
Reply With Quote
  #276 (permalink)  
Old 09-20-2017, 12:54 AM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Dec 2016
Location: Milpitas, CA
Posts: 231
Default

Investigating problems with the network connections locking up the rpi. Any ideas or suggestions are welcome!

ps: I am extremely suspicious that Ezstream is corrupting protected memory.

Last edited by JACK26; 09-20-2017 at 1:31 AM..
Reply With Quote
  #277 (permalink)  
Old 09-21-2017, 12:40 AM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Dec 2016
Location: Milpitas, CA
Posts: 231
Default

Well..it ran for another 9 hours or so and reconnected a few times but on the last disconnect the restart code stopped running again.. This time the VNC connection was still open with the last command line terminal window still open and was able to communicate with the rpi with VNC so no reboots occurred. This time it wasn't a complete loss of network comm, wifi and wired were still working..
Added debug code to the restart script to try and narrow down the problem.. Most likely this problem is related to the original problem of this configuration (rtl-sdr and rpi using rttl-fm, lame or sox and ezstream) not staying connected to Broadcastify which means that even a simple reboot app would fail after awhile too.
Highly suspicious of ezstream corrupting memory when it looses connection. I think it tries to buffer the stream when the connection is lost and overflows into memory used by other processes.

One thing I was wondering is that the dead air padding with rtl_fm seems to be at the same data rate as an active voice. Why not just send a keep alive byte once a second? I'm suspicious that ezstream tries to buffer the high data rate when connection is lost and is causing problems with corrupting memory.

This seems to be a limitation with Broadcastify servers in that it requires a constant open audio stream as if listening to a radio that never squelches to zero. I've noticed that a lot of feeders have a low level buzz in the background to keep the connection alive. The server code could be improved if it didn't depend on a constant "open mike" stream to stay alive and would greatly reduce the bandwidth load on the servers.
Reply With Quote
  #278 (permalink)  
Old 09-21-2017, 12:56 AM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Dec 2016
Location: Milpitas, CA
Posts: 231
Default

Just to clarify this rtl-sdr connection problem has nothing to do with any flaws with Broadcastify,. The suggestion with the padding requirements is just a suggestion to improve Broadcastify.
Reply With Quote
  #279 (permalink)  
Old Yesterday, 1:33 AM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Dec 2016
Location: Milpitas, CA
Posts: 231
Default

Update: Cleaned up a lot of the restart script and now running much better. Was able to restart on it's own for over 24 hours. Sill sometimes taking up to 20 minutes to reconnect but so far no complete lock ups.
It still has this occassional problem with locking out ssh and VNC on the local network for some reason but keeps running and feeding Broadcastify on it's own and restarting when needed.

I consolidated the code to kill the processes in 2 bash files only (1 bash file per feed) and cleaner killing algos.

This is the link to the updated shared google drive to those interested:
https://drive.google.com/open?id=0Bx...HM0ZUNWWG1FeFU

ps: Debugging is enabled and will work that way but to conserve power change "DEBUG...on" to "DEBUG...off" at the headers in several of the bash files. Leaving debug on will help you getting it to work the first time.

One other thing, the script is specifically written to use the wifi (in my case rpi3 embedded wifi) but will still work with a usb wifi stick. If you want to use eth0 lan wired only change wlan0 to eth0 where you see it in the script.

Last edited by JACK26; Yesterday at 1:49 AM..
Reply With Quote
  #280 (permalink)  
Old Yesterday, 3:06 AM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Dec 2016
Location: Milpitas, CA
Posts: 231
Default

Just re-uploaded several of the files again. Wrong file transfer between rpi and windows pc. All should be ok now.
Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On



All times are GMT -5. The time now is 5:35 AM.


Powered by vBulletin® Version 3.8.2
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
All information here is Copyright 2012 by RadioReference.com LLC and Lindsay C. Blanton III.Ad Management by RedTyger
Copyright 2015 by RadioReference.com LLC Privacy Policy  |  Terms and Conditions