Thanks. Clearly my scanning the thread was careful enough. For anybody else doing this, make also sure that you follow the instructions on the machine you're actually running this on. I did it in a browser on another machine, using the address where it was hosted, and that only made the changes visible on that machine.
I've been having the restart issue pop back up again occasionally where after rebooting my linux server, the ws4channels container doesn't properly load. A simple restart of the container seems to fix it. This hasn't been happening as much as what it used to be prior to the latest fix you did a month ago, but it's still been happening every now and then over the last couple weeks. Here is what I'm seeing in the logs:
(node:1) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 SIGINT listeners added to [process]. Use emitter.setMaxListeners() to increase limit
(Use node --trace-warnings ... to show where the warning was created)
(node:1) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 SIGTERM listeners added to [process]. Use emitter.setMaxListeners() to increase limit
(node:1) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 exit listeners added to [process]. Use emitter.setMaxListeners() to increase limit
(node:1) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 SIGHUP listeners added to [process]. Use emitter.setMaxListeners() to increase limit
Not sure if some further tweaks can prevent this from happening for good? Thanks as always for the help!
Iāll try to check it out sometime later this week.
1 Like
Made some tweeks to hopefully fix maxlisteners. Use the Latest tag. Also some people using this wanted custom channel number in environments with a default of 275. This is not needed for channels but they are using other software. This changes some of the unique channel ids so be aware that you may need to choose your own channel number in the channels source and reload the source in channels and possibly run a delete and recreate guide database. It might not be an issue at all though. Let me know if there are any issues as I canāt test it because I run an older ws4kp.
Updated it and everything seems to be working fine so far after a few restarts. Fingers crossedā¦thanks!
1 Like
Came here just to say thanks for making this! The first thing I thought of when I set up Channels was "I wonder if I can make WS4K a channel now..." and went down a rabbit hole lol. Took some tinkering but it's working great and doesn't seem to be running away with resources. Much appreciated man!
So I have been running this on UNRAID for a while now without many issues, I sometimes have to restart the containers, but otherwise fine.
But I decided to move both containers to a standalone NUC host using the exact same run lines used on the UNRAID server, but Iām stuck with the WeatherStar place holder screen. Just looking for some ideas on what I may be missing in the setup?
Iām using a script to do the docker run for now, once I confirm it all works my plan was to use a compose and setup a proper systemd script for start, stop, and status.
What is your docker run? Anything in the logs?
#!/bin/bash
docker run -d \
--name ws4kp \
--restart unless-stopped \
-p 9090:8080 \
-e 'TZ=America/New_York' \
ghcr.io/netbymatt/ws4kp
sleep 10
docker run -d \
--name ws4channels \
--restart unless-stopped \
--memory="1096m" \
--cpus="1.0" \
-p 9798:9798 \
-e "ZIP_CODE=29455" \
-e "WS4KP_HOST=10.0.10.110" \
-e "WS4KP_PORT=9090" \
ghcr.io/rice9797/ws4channels:latest
That's the run script I'm using for now, I've poked around inside both containers and didn't see an obvious log for either. I'm sure this is operator error somehow but I'm hoping more eyes can help spot any mistakes I have.
Try losing the quotes on the three -e variables
If that doesnāt help see if you get the desired variables as output when you run this command in terminal
docker exec ws4channels env | grep -E 'ZIP|WS4KP'
# docker exec ws4channels env |grep -E 'ZIP|WS4KP'
ZIP_CODE=29455
WS4KP_HOST=10.0.10.110
WS4KP_PORT=9090
No change but that was a good idea to try.
Iām not sure then. Try restarting ws4kp then restart ws4channels and watch the logs for any clues. Not much help I know.
Where does ws4channels log its output ?
This will restart the container and show logs.
docker restart ws4channels && docker logs -f --tail 50 ws4channels
# docker restart ws4channels && docker logs -f --tail 50 ws4channels
ws4channels
Running with 8 CPU cores, 31750MB RAM
Streaming server running on port 9798
Puppeteer old Headless deprecation warning:
In the near future `headless: true` will default to the new Headless mode
for Chrome instead of the old Headless implementation. For more
information, please see https://developer.chrome.com/articles/new-headless/.
Consider opting in early by passing `headless: "new"` to `puppeteer.launch()`
If you encounter any bugs, please report them to https://github.com/puppeteer/puppeteer/issues/new/choose.
Loaded 7 music files
Started FFmpeg
Running with 8 CPU cores, 31750MB RAM
Streaming server running on port 9798
Puppeteer old Headless deprecation warning:
In the near future `headless: true` will default to the new Headless mode
for Chrome instead of the old Headless implementation. For more
information, please see https://developer.chrome.com/articles/new-headless/.
Consider opting in early by passing `headless: "new"` to `puppeteer.launch()`
If you encounter any bugs, please report them to https://github.com/puppeteer/puppeteer/issues/new/choose.
Loaded 7 music files
Started FFmpeg
Nothing really odd there
That looks right. I guess delete both containers and start fresh. I honestly donāt know.
I got it working - smoking the container images as you suggested and starting from scratch fixed whatever was going on. Thanks for the second set of eyes!
1 Like
So, I've found despite moving both ws4kp and ws4channels to their own host (NUC with i5-8259U CPU, 2.30GHz, 32G ram) I still have to restart the ws4channels container fairly often. It will run for an hour or so, then when things have gone bad I can tune to it channel and the display is frozen. ws4kp is still working, going directly there with a browser works as expected. The docker host doesn't have any load, cpu, or memory issues.
Restarting the container fixes it but I'm wondering what else I can do to improve the life of the container.
I've played with passing in more CPUs and RAM:
--cpus="2.0" \
--memory="2048m"
but that hasn't made an observable difference.