Good morning :)
I have some questions regarding an icecast-setup.
We have my own (Nextcloud)-Server sitting in our church. This works perfectly fine and since here in Germany the community services got forbidden already once during all this Covid19-stuff, we want to have a stream-setup. I managed to set up an icecast-instance on our server and we use my old laptop with Rocket Broadcaster and a Steinberg CI2 to provide the source for the stream. That works all as intended. We already used it once because we stopped public services for two weeks after one of our member got tested positive after he went abroad for a week.
Our operator on the PA doesn't want to have another display there, which would disturb him from listening the sermon.
My project regarding this: I have a RPi4 and a Behringer U-Phoria UMC202HD. The input atm is a standard mic, that is connected to the Interface.
The Pi is configured with darkice and uses its own icecast installation, while I am testing everything at home. Since I started the streaming project, after the service we switched Rocket Broadcaster to use VLC and a folder of old service recordings (mastered and in MP3-format) to provide a source to listen while we are at work or on travels. This option gets used pretty regularly and I want to keep it going.
My plan is to have a little box with a LED levelmeter, where the input level is shown. That should be done with a little python script. Also I want to add two buttons, where presets for the two setups get loaded. Button 1: kill the current source and start the darkice livestream. Button 2: kill the current source and start the playback of old recordings. Both options should have visual feedback for the operator. The raspberry has to work in headless mode without need for a VNC or SSH-connection for the normal usage.
My problem: I tried:
sudo killall darkice && /home/pi/darkice.sh
This code will get changed, because I probably have to use ices for the mp3-playback. So basically it kills darkice, starts the ices playback (for now only restarts the stream in a blink) and vice versa.
The bash-file exists and gets executed at reboot via cronjob. That works well. When I execute the above mentioned killall command, icecast continues the broadcast almost instantly, but the stream stops on the clients. Everyone needs to restart it.
Do I have an option to change the setup, so that I am able to switch between the two options without the need for everyone to restart?
My plan was to create a bash-script, where I do this all inside and execute it via GPIO-input and pythoncode.
Thanks in advance!
Related
I would like to switch an On Air sign at my work-from-home office when my webcam is on.
Detecting whether the webcam is on can easily be done via
cat /sys/module/uvcvideo/refcnt
if it outputs 0 no app is using the webcam, otherwise it is.
I already have a Wifi plug which can be switched using a HTTP GET request.
My only question is: Do I have to poll the output of the above command regularly, or can I get notified in some Bash, Python or PHP script from the kernel?
The idea would be to not generate unnessary system load by polling - or doesn't that matter?
I already tried inotifywait but it does not seem to notice changes on the above pseudo file.
Based on jasonharpers answer I implemented it as a daemon that uses polling
https://github.com/amenk/OnAirDaemon
I'll try to be as clear as possible with what I'm trying to aim for.
I have a running Python script on my Raspberry Pi and I'd like multiple users to send inputs to the script remotely (through SSH or anything else that might work better).
So for example if I have this script running:
Name = input ("Please type in your name. \n")
type (Name)
print ("Hello there" , Name)
time.sleep(3) # Pause for 3 seconds.
I want users to send names to this script remotely from devices that are connected to the same network as the Raspberry Pi.
If possible, I also want to implement the following functionalities:
Sending the output (aka the printed text) back to the specific device the input came from.
A queuing system: If multiple users send names at the same time, the script will take the names in order, one by one.
I know it's a lot to ask for, but I'd really appreciate if someone could help me get started with this by pointing me in the right direction. I've searched around quite a bit for the past few days but I haven't really come across anything that fits my needs.
Edit: I'm running this on PYTHON 3
Your comment that you would like to communicate (via network) to the script directly, opens up a world of possibilities. You have to modify your Python script a little though, because it won't communicate via stdin/stdout any longer.
I'm still not entirely sure how you want things to work but it does sound to me that a solution based around RPC can possibly work for you. May I suggest you have a look at Pyro4? Basically what that does for you is enable you to do normal Python method calls, but over the network, to code running on another computer.
So you can set up a server on your Pi (that needs to run continuously) which accepts remote calls from other computers, and can then call into your python code on the pi. It can process calls in parallel or in sequence. You didn't say if you need any form of security, but some basic security features are provided (no built-in encryption or communication over TLS yet, sorry).
A simple example is here and lots more are on github so you can have a look to see if this fits your requirements?
Another solution that doesn't require third party libraries is perhaps to write a WSGI http server that calls your script, run this on the pi, and access it via HTTP from your other computers.
A simple python script publishes commands to the mavros node which is connected to an arduplane SITL instance.
Succesfully publishing to change mode from AUTO to GUIDED (so no connection or other issues). After changing, the plane is loitering.
Publishing to the services ~cmd/command or ~cmd/command_int the commands are rejected (return code 3).
Publishing to the topic ~setpoint_raw/global has no effect whatsoever.
The published command is a simple 16 MAV_CMD_NAV_WAYPOINT
The question is: is there any way that I can use any of the topics/services of mavros in order to simply stream waypoints (pairs of global coordinates) for the UAV to follow (in GUIDED or in any other mode).
I think that clearing and continuously uploading a mission in AUTO is not exactly an option since it would delay significantly.
Please note that the solution is intendeed for a fixed wing (aka Plane).
Versions:
ROS: Kinetic
ArduPilot: 3.8.0beta5
The issue has also been raised in mavros and Ardupilot hubs.
Did you try to do that using GCS and it failed too?
I also suggest to try dronekit . It is in python and simple to implement and send commands for the vehicle.
I've got several MR-3020's that I have flashed with OpenWRT and mounted a 16GB ext4 USB drive on it. Upon boot, a daemon shell script is started which does two things:
1) It constantly looks to see if my main program is running and if not starts up the python script
2) It compares the lasts heartbeat timestamp generated by my main program and if it is older than 10 minutes in the past kills the python process. #1 is then supposed to restart it.
Once running, my main script goes into monitor mode and collects packet information. It periodically stops sniffing, connects to the internet and uploads the data to my server, saves the heartbeat timestamp and then goes back into monitor mode.
This will run for a couple hours, days, or even a few weeks but always seems to die at some point. I've been having this issue for nearly 6 months (not exclusively) I've run out of ideas. I've got files for error, info and debug level logging on pretty much every line in the python script. The amount of memory used by the python process seems to hold steady. All network calls are encapsulated in try/catch statements. The daemon writes to logread. Even with all that logging, I can't seem to track down what the issue might be. There doesn't seem to be any endless loops entered into, none of the errors (usually HTTP request when not connected to internet yet) are ever the final log record - the device just seems to freeze up randomly.
Any advice on how to further track this down?
It could be related to many things: things that I had to fix also: check the external power supply of the router, needs to be stable, the usb drives could drain too much current than the port can handle, a simple fix is to add a externally powered usbhub or the same port but with capacitors in parallel to the powerline and at the beginning of the usb port where the drive is, maybe 1000uF
How can I detect when a flash drive is plugged in? I'm using a bare Debian installation, without any GUI and want to be notified in my Python script when a new flash drive appears... I know that D-BUS distributes such information, but i dont want to use D-BUS. Is there a more bare access to that information? Shouldn't that be available under /proc or /sys? How can I "connect" to that source?
Bye
falstaff
All mayor Linux distros include udev, that allows you to write custom scripts on hardware events.
You can read uevents from kernel via a Netlink socket and look for events where "ACTION" is "add" (you can also watch if a partition from a device was mounted or unmounted, or if a device is being removed). That's as close to the source of events as one can get in user space. As far as I know, this is how udev detects inserted removable media.
But probably using D-Bus/HAL API via Python bingings will be much easier (no uevents data parsing, etc). Not sure why you are opposed to this. Since you are using Python, I suspect that resources are not really the issue.
If you are targetting an embedded device, then you can run mdev instead of udev.
Then you can write mdev rules that are quite simple and triggers a script.
Of course you are not directly monitoring from your script, mdev is doing it, but you can launch any command. You can probably do the same thing with udev, but it always looked quite complicated to me.
When an USB device is plugged in syslog writes messages concerning this to /var/log/messages. The "dmesg" command shows this log. You can check near the end of the log to see which channel the device was attached to, it is usually /dev/sd(letter)(number) depending on the partitions and number of serial disks plugged into the system.
/proc/partitions shows all the partitions known to the kernel.
I did this using zenity in a script and udev with rule on rhel6 with:
KERNEL=="sd[b-d]", DRIVERS=="usb", ACTION=="add", RUN+="/path/to/script"