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
  #281 (permalink)  
Old 09-23-2017, 11:47 PM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Dec 2016
Location: Milpitas, CA
Posts: 263
Default

Reliability is increasing. Most disconnects less than 3 minutes now. Lowered the threshold for a reboot helped.
When connection is lost it seems to happen in 'swarms' and it takes 5 or 6 tries to reconnect. Then it stays happy for sometimes 10-12 hours without a single loss of connection. RPI is only running at 60C but thinking about adding a fan anyway. Still do not know why the rpi rtl-sdr config has such a hard time staying connected in the first place.

PS: I think the connection reliability is probably a problem with ezstream.

Last edited by JACK26; 09-24-2017 at 12:25 AM..
Reply With Quote
Sponsored links
  #282 (permalink)  
Old 09-24-2017, 10:54 PM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Dec 2016
Location: Milpitas, CA
Posts: 263
Default

Updated the files again and included a readme file with some install instructions.
https://drive.google.com/open?id=0Bx...k9TSkNiV2RnVUE

Seems to be working well now. Can be increased to handle more rtl-sdr's by duplicating some script files and updating them with the specific details of each feed.
Reply With Quote
  #283 (permalink)  
Old 09-25-2017, 1:35 AM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Dec 2016
Location: Milpitas, CA
Posts: 263
Default google shared drive

Something is wrong with that last link. Here is a better link
https://goo.gl/JBhveK
Created the readme file with notepad++ for windows.

Seems to be working really well with max disconnect times of less than 3 minutes and fewer disconnects overall.

These are my feed links again. 2 feeds with 2 rtl-sdr's on one rpi3 using the code on the google shared drive:
https://www.broadcastify.com/listen/feed/23831
https://www.broadcastify.com/listen/feed/25781

Last edited by JACK26; 09-25-2017 at 1:55 AM..
Reply With Quote
  #284 (permalink)  
Old 09-26-2017, 4:16 AM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Dec 2016
Location: Milpitas, CA
Posts: 263
Default

Update: The rpi3 feed is working really well with close to 36 hours and no down time in my Broadcastify stats. I took it down once today to troubleshoot an issue with still loosing ssh and VNC access. Was hoping it would do an auto reboot but got tired of waiting.

I think the issue with loosing the ssh and VNC access is that the rpi starts using a local IPV6 that is provided by my comcast router (the only router I have on the system right now). Since ssh and VNC use static IPV4 addresses, they are no longer able to connect.

Long story short, I disabled the IPV6 on the rpi by adding the following lines to /etc/sysctl.conf

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
net.ipv6.conf.eth0.disable_ipv6 = 1
net.ipv6.conf.[interface].disable_ipv6 = 1

Pretty sure I had this same problem with my ads-b pi2 feeder and haven't had to do anything to that feed for months and is always accessible with ssh and VNC.

ps: I also disabled IPV6 to the local network in the comcast router but those settings are kind of vague and comcast has more control than I do. Read a post by someone who seemed to be very knowledgable on the subject and they advised to buy your own router. There is no advantage to have IPV6 addresses on a local network that has less than 20 devices attached or even 200.000 devices attached. IPV6 was introduced because they were running out of IPV4 addresses on the world wide web. Not sure why comcast is serving IPV6 addresses to the local area net.

pps the post I was refering to is here and goes into a lot more detail.
http://forums.businesshelp.comcast.c...ngs/td-p/26044

ppps the source for the code to disable IPV6 on the rpi is here near the end of the thread by Bsmallz:
https://www.raspberrypi.org/forums/v...c.php?t=138899

Went through this same IPV6 disable exercise on my RPI2 ads-b feeder a couple of years ago and not sure I fixed it the same way as suggested above. But the feed is zero maintenance always up and accessible for at least 10 months with no intervention.

The only instance where you might want an IPV6 address on an rpi is if it is connecting directly to the internet without a router which is probably the case with some remote installations. But it complicates using apps like ssh and VNC to find the correct IP address.

Last edited by JACK26; 09-26-2017 at 6:15 AM..
Reply With Quote
  #285 (permalink)  
Old 09-27-2017, 12:06 AM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Dec 2016
Location: Milpitas, CA
Posts: 263
Default

Improved the checkstream1.sh and checkstream2.sh for faster reconnects. Google drive updated.
Google link: https://goo.gl/k3EzBm

So is anyone actually downloading these files? No feedback from google drive on download statistics and no one has commented here for awhile.
Reply With Quote
Sponsored links
  #286 (permalink)  
Old 09-28-2017, 4:30 AM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Dec 2016
Location: Milpitas, CA
Posts: 263
Default

Update: Eliminating the IPV6 on the rpi eliminated the loss of connection with VNC and ssh.
The reboot times are down to around 2 minutes. Still struggling with clean reconnects that should take less than 15 seconds.
Need more technical details of the parameters of the connection limitations with Broadcastify.
Any suggestions?
Reply With Quote
  #287 (permalink)  
Old 09-30-2017, 3:47 AM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Dec 2016
Location: Milpitas, CA
Posts: 263
Default

Updated some of the bash files again. The tcpdump command was occasionally locking up the rpi. I changed the check interval from 20 seconds to 1 minute and simplified the tcpdump parameters. Details are in the readme file. I think the 20 second interval and the more complex tcpdump parameters was locking up the wifi.
New link here if anyone is following this effort:
http://goo.gl/PWG3e3

Feeds (1 each rpi3 with 2 rtl-sdr's):
https://www.broadcastify.com/listen/feed/23831
https://www.broadcastify.com/listen/feed/25781

Last edited by JACK26; 09-30-2017 at 3:56 AM..
Reply With Quote
  #288 (permalink)  
Old 09-30-2017, 7:14 AM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Dec 2016
Location: Milpitas, CA
Posts: 263
Default

New link due to a typo in the readme file.
https://goo.gl/yQr5Ac
Reply With Quote
  #289 (permalink)  
Old 10-02-2017, 7:02 AM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Dec 2016
Location: Milpitas, CA
Posts: 263
Default

To those interested, updated the bash files checkstream1.sh, checkstream2.sh and runstream.sh at :
https://goo.gl/yQr5Ac
again.

Prayers to the victims of the Las Vegas shooting today.
Reply With Quote
  #290 (permalink)  
Old 10-02-2017, 11:44 PM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Dec 2016
Location: Milpitas, CA
Posts: 263
Default

Major changes; updated several bash files and created 2 new ones to handle the feed restarts with improved restart aglo. More details in the readme.txt file. New google link for those who are interested:
https://goo.gl/EzADQu
Reply With Quote
  #291 (permalink)  
Old 10-04-2017, 2:56 AM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Dec 2016
Location: Milpitas, CA
Posts: 263
Default

Updated several bash files again. Spaced out interrogating the ports by five seconds and cleaned up the code (there was several mistakes). Details updated in the readme.txt file.

This link is still ok for those who are interested::
https://goo.gl/EzADQu
Reply With Quote
  #292 (permalink)  
Old 10-05-2017, 3:15 AM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Dec 2016
Location: Milpitas, CA
Posts: 263
Default

Well, this latest version is working best except that there is still an intermittent problem with spurts of connection issues. Sometimes the rpi restarts the feed ok and starts feeding to the bcfy servers but locks out ipV4 local connections again. Thought I fixed that with recent confg changes to disable ipV6 but still maybe happens sometimes.

Any ideas? I know this was a problem on my rpi2 years ago and fixed it then but not sure I have it fixed on the rpi3 bcfy feeder.

All this restart script I've been sharing depends on a working ipV4 connection to work properly and I think there may be still a problem with my rpi 3\s configuration to make that work

Any ideas (DC31 especially!) ?

PS: I no longer trust my Comcast wireless router to feed all my connections as there is no clear instructions on how to fully disable ipV6 on the local network. Seen suggestions by others who agree and suggest buying another router for your local net. ....If this is true it is outrageous for consumers and may end up with lawsuits with the cost of the additional routers.

That is my next step to make this work though, independent wireless router that is not controlled by Comcast. If this fixes my problem. Comcast should credit the cost to my enormous cable bill .

ps: I am hoping this is still a problem that can be resolved with rpi3 config files as I don't have this problem with my rpi2 ads-b feeder.

Last edited by JACK26; 10-05-2017 at 4:02 AM..
Reply With Quote
  #293 (permalink)  
Old 10-05-2017, 11:53 PM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Dec 2016
Location: Milpitas, CA
Posts: 263
Default

re-edited "/etc/sysctl.conf" again and put this line near the end of the file instead of the top:
net.ipv6.conf.all.disable_ipv6 = 1

Seems to be working ok again.
Reply With Quote
  #294 (permalink)  
Old 10-06-2017, 2:07 AM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Dec 2016
Location: Milpitas, CA
Posts: 263
Default

Updated several bash files again to clean up the stats logging. Also some '&' were missing.
New link is here for those interested:
https://goo.gl/VnNHFr
Reply With Quote
  #295 (permalink)  
Old 10-07-2017, 6:12 AM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Dec 2016
Location: Milpitas, CA
Posts: 263
Default

Latest version is working well and not changed it since the last upload. Works as designed.
There is still a problem with the rpi/rtl-sdr reliabilitity I'm still working on. Sometimes the rtl-sdr disconnects for no apparent reason, but when it does, my restart code will reconnect in less than about 3 minutes and most cases within 30 seconds or less.
Looking at beefing up the 5VDC power supply again. Still using the 2.5A 5VDC wall wart that came with rpi3 kit. Went through this exercise a while back though and it didn't solve anything.

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

Updated the restart code with some better checks for reconnect and shortened the sleep times.:
Details are in the readme.txt file:
https://goo.gl/zVfzKj
Reply With Quote
  #297 (permalink)  
Old 10-12-2017, 5:09 AM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Dec 2016
Location: Milpitas, CA
Posts: 263
Default

Latest version is working well, The only problem (if you can call it a problem) is the my rpi3 Milpitas, CA feeder has not lost connection to Broadcastify for at least 28 hours. So the restart code hasn't had a chance to cycle again. But seems to be working very well so far. When I started this project I could not get a rpi3 feeder with sdr only to feed for more than about 6 hours without loosing connection and no way to recover. So this solution is working really well and comparable to the scannercast windows software so far.
Reply With Quote
  #298 (permalink)  
Old 10-13-2017, 6:06 AM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Dec 2016
Location: Milpitas, CA
Posts: 263
Default

Updated the restart code again. Finally had some real world disconnects and found a syntax error. Updated restartfeed1.sh and restartfeed2.sh if statements with quotes and double brackets.
The original version was returning true and rebooting the rpi even with a successful reconnect.

Still learning about what syntax works with what version of linux and so far it is extremely convoluted and confusing.
New link with updated bash files is here:
https://goo.gl/9p1oZJ
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 7:42 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