coppit

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.

That's news to me! Awesome! There's a kernel build, and some reports that the Java workaround is working. I was going to dust off my equipment and rebuild my server. This fix sounds like a more "proper" fix.

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.

Hi everyone, I just pushed an update that adds a couple features that people asked for. (1) Don't remember files forever, so that if a file is put back into the input directory, it will be processed again, and (2) allow the user interface part to be disabled to save resources. This version also fixes a user/group ID issue. NOTE: The container will exit after being updated. You need to compare filebot.conf with filebot.conf.new, merging in the new settings. Then do the same with filebot.sh and filebot.sh.new. After you do that, increasing the version number, the container will start normally. Also note that the default setting for USE_UI is "no", meaning that if you want to use the UI, you'll need to set that to "yes". See the documentation for more information.

Checking back in after months away... It's the bash quoting that's biting you. Try putting a \ in front of each of the $. It's not the container deleting anything. My guess is that it's some sort of filebot behavior to delete empty dirs after move is done. You could try putting some file in there like "dont-delete-this" that FileBot can't process. Then it will probably leave the dir behind. I've found the UI running in a container to be pretty... finicky. I had to modify the filebot startup to deal with some rendering problems. So it's possible that this is another rendering problem. I bumped the version of Java, which might fix this, but probably won't. I could try playing with this some if you can give me precise repro instructions. Does the log say anything interesting when you pop that window up? Does the close window button work? There's also a chance that this has nothing to do with the container or Guacamole. Maybe try asking your question on the FileBot forums. Dang! You're not kidding! I just pushed a new version that adds a new USE_UI config setting. The default "no" setting uses about 10x less memory and CPU! The base gui image spews a million errors and warnings, but seems to work okay. Are you seeing any real problems? Sadly, it doesn't seem to be maintained any more. There have been several forks, but it's not clear to me that anyone is providing a good alternative to the original image. Maybe? I don't know what you're asking exactly. The container looks at the file system for changes. Are you wanting it to somehow look for new files on the Internet, and copy and rename them to your local machine?

Seeing the same thing with 6.4.0_rc10b. My OS clock is off too, even with NTP running. Is yours?

I can't find solid confirmation that this might work, especially for NVIDIA boards, which is all I have. https://forum.level1techs.com/t/threadripper-pcie-bus-errors/118977/21 I'd be willing to rip up my Intel setup and reinstall my AMD one (again), if there was at least a little more indication that it might work.

Yay! I figured it out! I think what was happening was that when I followed the instructions to dump the VBIOS in unraid, I got confused with respect to which GPU I was dumping versus which I was trying to pass through from the first slot. I grabbed an old card and put it into slot 1, and followed the remaining instructions exactly, and it worked!

I'm wondering if someone can help me get this working. Setup: Core i7 7820X AsRock X299 Killer SLI/ac motherboard GTX 960 in slot 1, SATA controller in slot 2 ROM config set up Guest: Windows 10 OVMF Symptom: The machine boots okay, with the console going to my display. When I start the VM, my display goes black but I never see the "TianoCore" logo. Eventually the monitor goes to sleep. I can RDP into the VM, and Device Manager says "Windows has stopped this device because it has reported problems. (Code 43)" I tried removing and re-adding the device, and deleting the installed drivers. Rebooting the host restores my console display. I tried using a vbios dumped from unraid, dumped from CPU-Z, and several downloaded from TechPowerUp. (All edited with a hex editor.) Unexpectedly, the ones dumped from the card didn't require the hex edit. Also surprisingly, the ones from CPU-Z and from unraid differed (?). I also tried switching to Seabios with no luck. Last night when I was playing with passthrough with both Windows VMs, I could have sworn I got the slot 1 card to work, briefly. (I need to get an i9 CPU for x16 speeds on slots 1 and 3.) Today when I'm trying to get just slot 1 working, I'm having no luck. My UEFI BIOS doesn't have an option to select a video card, as far as I can tell. Otherwise I'd buy a cheap single-slot card and boot of off that. And I can't give up slot 1 for that card, since I need both slots 1 and 3 for my two passthrough VMs... Attaching my CPU-Z report and my XML. windows.xml

#!$#!@! I wish I had seen this before buying: https://www.reddit.com/r/Amd/comments/6vbe6w/threadripper_broken_on_linux_for_pci_passthrough/