admsteck

I recently switched to the binhex versions of several apps (sonarr, radarr, etc) since I'm already using a binhex vpn image. I would have thought that would also save some space since they should all be based on the same base image, but that doesn't seem to be the case. When I installed the new apps, they downloaded all the layers, and I would have thought some of them should have already existed. Also, I noticed that the binhex images are significantly larger than the linuxserver versions. Radarr is 1.17 GB vs linuxserver at only 196 MB for example. And all the binhex images that I use are over 1 GB. I'll see if I can do some digging to figure out why they don't appear to be using base images correctly and why they are so large, but just wanted to see if anyone else had noticed this or had any explanation.

Is it possible to remove the user/password prompt?

That's what I figured, just thought I'd ask. External hosting won't work since I don't expose my Unraid server outside of my home network and I want to build a custom dashboard from data pulled from other docker containers. I'll have to take a look at which web server containers are available... I'm sure there are plenty.

Any way this could serve up a static html page from somewhere on the array? Or do I need to install some web server docker container first and serve the file from there?

It's awesome that there is now an official Plex docker image. I'm still running the LimeTech version.... is there anything special I need to do to switch to the official? After I remove the docker container, should I also remove the plex folder in appdata to start clean?

I've been looking around and it would be really nice if the guide would include a little more detail on general maintenance. For example, the guide says you should start with a 10G size and can increase it later, but doesn't say how. Along the same lines, how can we tell how much of the 10G each of the installed containers are using?

DDR2. I've got one stick of 1GB DDR2-800mhz in now.

Can't remember exactly where the downloads go to (flash drive or to RAM), but it sounds like either the flash drive is full or your tmpfs in ram is full. If its not the flash drive, rebooting and then updating right away should fix the problem Shut down all docker containers and turned off auto start, removed all extra plugins, rebooted, got to 78% before I got the error. I have 1GB of ram and the dashboard shows 43% in use. Flash drive is 16GB and the main tab shows 15.9GB free on the flash drive. Huh, well the zip file itself is 138MB and downloaded to /tmp. Then it's about 301MB extracted also to /tmp. That's about 439MB of RAM used. Now add to existing booted release taking up RAM and you're right on the edge with 1GB We may need to look into this further, in the meantime you can update the "old fashioned way" by plugging your flash device into a PC and copying the zip contents over there manually. You want: bzimage bzroot bzroot-gui make_bootable.bat make_bootable_mac memtest changes.txt license.txt syslinux/syslinux.cfg- Another thing to check: your bios is probably carving out some memory for onboard video. Some bios permit you a few options for how much to reserve. If yours is like this make sure it's at the lowest setting. Thanks. I've got more RAM on my wishlist. I guess I'll have to manually update this time or buy myself a little present.

Can't remember exactly where the downloads go to (flash drive or to RAM), but it sounds like either the flash drive is full or your tmpfs in ram is full. If its not the flash drive, rebooting and then updating right away should fix the problem Shut down all docker containers and turned off auto start, removed all extra plugins, rebooted, got to 78% before I got the error. I have 1GB of ram and the dashboard shows 43% in use. Flash drive is 16GB and the main tab shows 15.9GB free on the flash drive.

When I try to update through the plugin, the download gets to 74% and then says "File I/O error". Any ideas?

Default. The only setting I changed was the output location.

You could try to enable the "log debug messages" and see if you get any useful. Unfortunately it looks like "log debug messages" only writes the messages from the log window to a file and doesn't actually provide any more detail. I'm still running unRaid on some low spec hardware I had laying around to get started (only 1 core celeron and 1G ram). I think my next step is to use some beefier hardware and see if that helps.

It is using a cache drive... and the cache drive shows 89G free.

The mkv is not inside the container. I can see it in the user share from another machine on the network. MakeMKV also shows 82G free and the output size never makes it to 1G before it errors. Unfortunately, the log window doesn't really provide any help either. I guess I'll keep digging and see if I can find any other logs. You wouldn't happen to know if MakeMKV stores logs somewhere else?

Here is what I have done so far: 1. In the unRaid web interface, add '--device=/dev/sr0:/dev/sr0' to the extra parameter field for the docker container so that the drive is accessible from within the container. If your drive isn't sr0, you may have to change this. 2. SSH into your unRaid server, then open a bash shell inside the docker container. a. Update the owner of /dev/sr0 within the container or update the 'nobody' user so they have permission on the drive. With a fresh install, `ls -l /dev` showed that the owner of sr0 was root and the group was 19. There was no group 19 inside the container. So I did `chown root:cdrom /dev/sr0` to change the group and then `usermod -a -G cdrom nobody` to add the user to the group. b. Added a few different things to /etc/apt/sources.list and tried installing a few different things. Ubuntu-restricted-extra and vlc were the two I remember. After all that, HandBrake successfully scanned the disk and started encoding. It was extremely slow since I have unRaid on a very old system right now. I left it run over night and when I woke up, I had a m4v file that I couldn't get to play. Not sure what happened. The next time I opened HandBrake, it said something about unfinished process, so it might have died sometime during the night. I still have some experimentation to do, but it's progress. I definitely how easy unRaid and Docker make it to try experiment and start over when needed.