DerBunteBall

I would change to MPEG-TS. Then you can stop the Downloader and kill all ffmpegs. You then can do a post processing by converting the files from MPEG-TS to MP4...

Forgot: Wireless LAN and Powerline are also crap for something like StreaMonitor. Everything needs to be wired well.

Then you should switch to MPEG-TS, take the smallest possible resolutions and build a good wrapper around everything. Then this should be good. I would use separate UNIX box. Windows...

I think you should do the following: 1. You should have a setup where it's safe that Controller.py works. Due to the fact that you can't really simple inject something...

That seems to be plausible. ```python thread = Thread(target=execute) thread.start() ``` The downloader thread (all is threaded in the script) isn't a deamon. So the main process will stuck until...

Check this: [py2tmux](https://github.com/stroxler/py2tmux) - a wrapper for tmux ommand. It seems also to be possible to get output directly back by capture and read buffers of panes - [look ehre](https://stackoverflow.com/questions/12665625/how-to-get-the-result-of-send-keys-in-tmux).

Just a few quick thoughts. No warranty that they are the best solution. You would need to implement this in the downloaders package. In StreaMonitor nearly everything is a thread....

https://github.com/lay295/TwitchDownloader That's the prrof of concept for Twitch (GUI just Windows). It's a complex task to capture, render and put everything together. It's in general more a post process task....

> For me it seems easier to implement than you think @DerBunteBall, just requires time, which I will rarely have in the next few weeks. Also I don't like these...

The reason now is clear. If the still running ffmpegs stay alive after closing Downloader.py the subprocess spawning seems not to be influenced by the Thread type. So the subprocess...