coppit

Are you saying that where it prints: Configuration: USERNAME=foo PASSWORD=<hidden> DOMAINS=bar INTERVAL=baz DEBUG=zap It displays your password in the USERNAME line? A couple of thoughts: Make sure that your password is within single-quotes like: PASSWORD='your password goes in here' However, if your password contains a single quote, then you have to escape it. LMK if that's the case. Second, make sure that you aren't defining environment variables for the container that are overriding the config file.

Moved to Alpine linux, reducing the image size from 232MB to 90MB Also: Make the change monitors more like services that restart if they crash. Added a feature to use polling, so that Windows shares can be monitored too.

Does the client connect and complain about the version? Or does it not connect at all to the port? Are you remapping 10090 or 8090, or both?

I moved the image to Alpine linux, which drops the size from 229MB to 64MB. I also added the ability to configure it using env vars instead of the config file. This is a pretty big change, so let me know if you guys see any issues.

I switched the container from the phusion base image to Alpine linux. The size dropped from about 250MB to about 16MB. It also handles options set using environment variables rather than the config file better. This is a pretty big change, so let me know if you guys see any issues.

Docker image updated with the fix.

Hi everyone, I found a bug in the container that causes the recordings to be saved inside the container, instead of to the attached disk volume. I'll release a fix soon. You must run the following command before updating your container, or your videos will be lost! docker exec -it Xeoma bash -c 'cd /usr/local/Xeoma/XeomaArchive; for n in *;do mv "$n"/* "/archive/$n";done' I'll wait about a day before releasing the fix, in case anyone has auto-update configured for their docker containers.

The author (or moderators of Community Applications) of the plugin template (https://raw.githubusercontent.com/coppit/unraid-mosh/master/mosh.plg) has specified that this plugin is incompatible with your version of unRaid (6.5.3). You should uninstall the plugin here: Maximum OS Version: 6.4.1 I didn't specify any such thing. Tested as working with 6.5.3. How do I get this fixed?

User reports it works: https://github.com/coppit/unraid-mosh/issues/1 I installed it and it works as well. Are you the keeper of plugins? Can someone please point me to the latest plugin documentation? My plugin files aren't part of a txz like I see others have. When it gets installed by the system, the directory is missing "other" read and execute permissions, which means that emhttp can't read the icon. I also see that the latest plugin plg's don't have "iconfile". I'd like to renovate my plugin, but don't know how.

Can someone please point me to the latest XML template for plugins, so that I can update my mosh plugin? It's currently not even showing up in CA, I guess because it's assumed to be incompatible with the latest version of UNRAID until I indicate otherwise.

Whoa. My SageTV and UNRAID worlds are colliding! To be honest, I'm not very familiar with USB devices and docker. This post seems to suggest that you can pass the devices through. The container is based on Ubuntu, so you could try getting into it with "docker exec -it xeoma bash" and installing USB drivers there. Heck, maybe it will "just work" without any special drivers, being "universal" and all. If that works, I could see about including those drivers in the container. But to be honest, USB cameras are not that great. I would get HikVision cameras, which are affordable, have good features, and support power-over-ethernet. Then maybe get some powerline adapters to provide PoE and also networking over your power outlets. Something like this and this.

Sorry. That was a goof on my part. I just pushed a fix. As soon as the container rebuilds on the hub, you'll have the fix.

Thanks everyone for helping folks to enable the UI. I appreciate the assistance. I've updated the first post to this thread, so hopefully people won't have to keep asking.

I saw this too. After I rewrote the download code, it went away. Not sure if I really fixed it or not. I'll try to keep an eye on this thread in case anyone sees it again.

They changed the format of the webpage that I was using to get the latest version information. Good news though... I did some sleuthing into how Xeoma itself learns about new versions, and found the XML endpoint where they publish the information. With that knowledge, I rewrote the code to use that endpoint, which should be a lot more reliable going forward. As a bonus, I also exposed port 10090, so if you want to add the web server feature to your camera workflows, you can access Xeoma through the web browser as well. See https://felenasoft.com/xeoma/en/articles/transmitter/ for more details.

Yeah, it looks like the website switched from http to https. (That's why downloading it manually and saving it as the .tar.gz worked.) I just pushed an update that hopefully will fix it. However, I'm still having trouble getting my container to start. I'll work on it before I have to catch a plane. Let me know if the latest version fixes the "stable" and "beta" download methods, please. Be sure to delete the contents of the downloads folder and update your conf before trying it though. Otherwise it will use the cached .tar.gz

After updating to the latest version, the container doesn't seem to lock up. (After 2 days, at least.)

Did you set it up using the SpaceInvader One approach? I had to hard-reboot my server, and after a few days it ended up the same way. I'm wondering if a log or something is causing the container to lock up after a few days.

Maybe if the feed can't be reached, issue a warning but let people use the cached app list? I'm all excited to try out pihole for the latest SpaceInvaderOne video, but instead I have to do Easter stuff with my family. :-)

Is the update server down? Loading the apps tab fails the refresh.

Did you set USE_UI to true in the config file?

If the script or config files update, the container exits and asks you to compare the new files versus yours. I don't think you're looking at the right git repo. I'm not the most prolific coder, but there have been changes the last few weeks. https://github.com/coppit/docker-filebot

Yep. Bug is fixed. Fixed that one too. Yep, sorry. I hereby issue you a full refund. I'll check that out. It didn't exist when I started this container. If it's better, then I'll drop mine from unraid apps. Part of the problem is that the GUI base image that I'm using is ancient. Looks like jlesage has a replacement that's probably much better.

Yep. It's a bug that I fixed in the latest version. Operating systems tend to try to keep useful memory around until there is pressure to give it up. It's also possible that the UI loads things it needs on first use. You can restart the container after every UI use, but in general I wouldn't worry about it. If you'd like, in the latest version you can set USE_UI to "no" in your config file, and it will disable the UI, resulting in 10x less memory and CPU usage. I noticed that the CLI version is good about giving up the memory after an encode is complete. The latest version disables the UI be default. If you wish to use the UI, set "USE_UI=true" in your HandBrake.conf file.

Inside my container, there's only eth0. Are you using bridged networking? If not, try that. Ug. The problem is that the no-ip people don't really give me control over when the update happens -- they have a binary that hides that logic. That said... Does the container properly update your DNS when you restart it? If so, perhaps their binary force-updates when it's first started. So what I could do is compare the DNS lookup IP against my current IP, then force-restart their binary to "encourage" it to do the update.