uiuc_josh

I'm seeing this same thing as well. I was traveling for a while, and don't really know exactly when this started. I've tried to re-add the directories, and plex appears to initiate a directory scan, but when the server library is opened, it gives the 'something went wrong' page.

I'm interested in preventing this, as I have a 2x mismatched SSD cache pool w/ btrfs that has my docker volume on it. Any tipper for success for folks in this position? Edit: Unregard. Answer was way too close the top of the 6.9.0 release notes. Josh

Haha, thanks Squid. Now what excuse am I supposed to use to be on the computer on the weekend? Thanks again, J

saarg, I think you were correct that this wasn't a calibre issue. I removed and had similar issues trying to reload. I'm not 100%, but I think some IPs from the CDN that relays some of the calibre images popped onto a threat list, so a just few of the streams incoming were getting hit by my IDS. Thanks for the help! J

OK--have force updated, but will give the manual remove/replace a try. Thanks!

I'm having a similar issue where some dockers (particularly linuxserver calibre for reasons unknown) haven't not completed a docker pull successfully in months. I used to never have docker pulls fail, but now it's a regular occurrence. I update on the weekend every week. This started early this year, maybe Jan or Feb. I'm on 6.8.3. I usually get something like the following text, and even when the downloads all progress to 100%, they don't Extract. This is very frustrating--I'm not sure what to try. I just pulled 4 updates and not one completed successfully. I'd appreciate any ideas! Josh IMAGE ID [1191746980]: Pulling from binhex/arch-jackett. IMAGE ID [ae8bad35e085]: Pulling fs layer. Downloading 100% of 263 B. Verifying Checksum. Download complete. Extracting. Pull complete. Pulling fs layer. Downloading 100% of 263 B. Download complete. Extracting. Pull complete. IMAGE ID [6bc503260a9b]: Pulling fs layer. Downloading 100% of 3 KB. Download complete. Extracting. Pull complete. Pulling fs layer. Downloading 100% of 3 KB. Download complete. Extracting. Pull complete. IMAGE ID [ff3d0022ca4c]: Pulling fs layer. Downloading 100% of 656 KB. Verifying Checksum. Download complete. Extracting. Pull complete. Pulling fs layer. Downloading 1% of 656 KB. IMAGE ID [85aa5e1255ae]: Pulling fs layer. Downloading 100% of 5 KB. Verifying Checksum. Download complete. Extracting. Pull complete. Pulling fs layer. Downloading 100% of 5 KB. Verifying Checksum. Download complete. IMAGE ID [8bacc57869e2]: Pulling fs layer. Downloading 100% of 200 MB. Verifying Checksum. Download complete. Extracting. Pulling fs layer. Downloading 100% of 200 MB. Verifying Checksum. Download complete. IMAGE ID [5d769186571e]: Pulling fs layer. Downloading 100% of 243 B. Verifying Checksum. Download complete. IMAGE ID [530a345a26e3]: Pulling fs layer. Downloading 100% of 2 KB. Verifying Checksum. Download complete. IMAGE ID [d38befd7d245]: Pulling fs layer. Downloading 100% of 268 B. Verifying Checksum. Download complete. IMAGE ID [fca4f06c64a3]: Pulling fs layer. Downloading 97% of 73 MB. TOTAL DATA PULLED: 274 MB Stopping container: binhex-jackett Successfully stopped container 'binhex-jackett' Removing container: binhex-jackett Successfully removed container 'binhex-jackett' Command:root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name='binhex-jackett' --net='bridge' -e TZ="UTC" -e HOST_OS="Unraid" -e 'UMASK'='000' -e 'PUID'='99' -e 'PGID'='100' -p '9117:9117/tcp' -v '/mnt/user/Downloads/sickrage/torrent/':'/data':'rw' -v '/mnt/user/appdata/binhex-jackett':'/config':'rw' 'binhex/arch-jackett' dadd590554929486c3889695ab42dc916361ed88a6d76627b22f5c75c5cbe5d5 The command finished successfully!

Ok, so mine is stuck on 4.13 and 4.20.0 is current. I am on the latest Docker, so I'll try a different forum. The only reason I put it here is that this is the only docker I seem to consistently have this issue with (out of 8).

saarg, Yes--thanks for pointing that out. Sadly, it will run through the process, restart the container, but will still be on the old version and will be marked as requiring an update. I've seen this with other containers, occasionally, however with this container the downloads haven't successfully completed in several months, with weekly attempts. unRaid will show the same indications as you've pointed out whenever an image within an update doesn't completely download, but I've never had another docker fail consistently like this. So, I think something other than just a single bad update/download is at issue here. J

I really like this docker for my book library needs. That said, I've been stuck on 4.13 for several months, as all the docker update attempts within unRaid fail on this docker, with one or two components freezing below 100%. I have this problem intermittently with the linuxserver unifi controller docker, but no others. This (calibre) docker hasn't completed a pull in many months. I've checked my firewall/IDS logs and nothing is being blocked during the update process. There is alwyays one or two files that do not completely download. Any ideas on this one? The update always looks something like the following: Pulling image: linuxserver/calibre:latest IMAGE ID [1436953874]: Pulling from linuxserver/calibre. IMAGE ID [6b59f4d42254]: Pulling fs layer. Downloading 97% of 25 MB. IMAGE ID [875de62a65e8]: Pulling fs layer. Downloading 100% of 275 B. Verifying Checksum. Download complete. IMAGE ID [7af6c5f56812]: Pulling fs layer. Downloading 100% of 13 MB. Verifying Checksum. Download complete. IMAGE ID [c7bd6e473c84]: Pulling fs layer. Downloading 100% of 4 KB. Verifying Checksum. Download complete. IMAGE ID [862cf5bf9c91]: Pulling fs layer. Downloading 100% of 94 MB. Verifying Checksum. Download complete. IMAGE ID [9ee8bb076a0e]: Pulling fs layer. Downloading 11% of 4 KB. IMAGE ID [7ea0e6f90ec9]: Pulling fs layer. Downloading 100% of 616 KB. Verifying Checksum. Download complete. IMAGE ID [cdc6542d74b6]: Pulling fs layer. Downloading 100% of 103 MB. Verifying Checksum. Download complete. IMAGE ID [8d9f46996599]: Pulling fs layer. Downloading 100% of 2 KB. Verifying Checksum. Download complete. IMAGE ID [ecc00f389bd3]: Pulling fs layer. Downloading 100% of 185 MB. Verifying Checksum. Download complete. IMAGE ID [85b4fae8406b]: Pulling fs layer. Downloading 100% of 653 B. Verifying Checksum. Download complete. TOTAL DATA PULLED: 421 MB Stopping container: calibre Successfully stopped container 'calibre' Removing container: calibre Successfully removed container 'calibre' Command:root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name='calibre' --net='bridge' -e TZ="UTC" -e HOST_OS="Unraid" -e 'GUAC_USER'='XXXXX' -e 'GUAC_PASS'='xxxxxxxxxxxxxxx' -e 'PUID'='99' -e 'PGID'='100' -p '8097:8080/tcp' -p '8098:8081/tcp' -v '/mnt/user/Kindle_Library/':'/books':'rw' -v '/mnt/user/Kindle_Library/0. Import/':'/import':'rw' -v '/mnt/user/appdata/calibre':'/config':'rw' 'linuxserver/calibre' 9xxxxxxxxxxxxxxxxxxx The command finished successfully!

Hello, I have a weird docker-ism where my docker always shows that I'm in need of an update. The docker install is on 5.6.42. I can pull the update, but on next check, it will always say I need to pull a new version. Weird. It's not a big deal, but I've attached my docker settings and the "header" on the docker summary page. Thanks guys--if you have a free minute or know what causes this, I'd appreciate the insight! Josh PS: I have a similar cert issue that dorgan's having, except I can manually override the Chrome objections and go to the site. Not sure how to get a properly signed cert from the IP address I have the docker on like I do with the main unRaid server site.

Hello all! New to the world (and frustration) of Unifi. I'm experimenting with upgrading off of LTS, and attempted ijuarez's method posted in March. Every time I attempt to restore my backup file from 5.6.42 onto either 5.8 or 5.9, I get an error saying that the uploaded file is "newer" than the current controller version. Any known workarounds? Thanks! J

I'm not seeing any corresponding events logged there. I'm reconfiguring the log rotation in the IPMI to make sure I'm not missing anything from a full log file. After rebooting the server, I've had three recurrences of the error in two weeks. Not sure what I'm dealing with here. Josh

All, I'm getting the following (flagged by FCP) in my syslog: May 6 22:37:21 unServer kernel: mce: [Hardware Error]: Machine check events logged May 6 22:37:21 unServer kernel: EDAC sbridge MC0: HANDLING MCE MEMORY ERROR May 6 22:37:21 unServer kernel: EDAC sbridge MC0: CPU 0: Machine Check Event: 0 Bank 9: 8c000041000800c0 May 6 22:37:21 unServer kernel: EDAC sbridge MC0: TSC 397c3a0867fb60 May 6 22:37:21 unServer kernel: EDAC sbridge MC0: ADDR 1d0543000 May 6 22:37:21 unServer kernel: EDAC sbridge MC0: MISC 90000004000428c May 6 22:37:21 unServer kernel: EDAC sbridge MC0: PROCESSOR 0:50662 TIME 1525646241 SOCKET 0 APIC 0 May 6 22:37:21 unServer kernel: EDAC MC0: 1 CE memory scrubbing error on CPU_SrcID#0_Ha#0_Chan#0_DIMM#0 (channel:0 slot:0 page:0x1d0543 offset:0x0 grain:32 syndrome:0x0 - area:DRAM err_code:0008:00c0 socket:0 ha:0 channel_mask:1 rank:0) They are occuring about every 1-3 days for about the last month. Is this a bad ECC DIMM? I haven't rebooted since this started, so I'll start there. Any ideas how to read this error? I'm running a XeonD-1520 setup on an AsRock D1520D4I on unRAID 6.4.1. It's been in service about 20 months. Thanks! Josh

Is anyone using this with Jackett? I cannot for the life of me get it to work. I have the latest binhex/arch-medusa running (rebuilt from my Sickrage media, but not database). This worked fine, and things were up and running. My downloader is deluge-VPN, which I've always gotten to work via WebUI. Deluge also looks a a folder /downloads/jackett/ for torrents. It seems that Medusa is passing the request just fine to Jackett, but can't deal with what it gets back. Jackett has a "black hole" setting, but it doesn't actually seem to put anything in there on normal requests, just manual downloads that I tell it to put there. Apologies in advance for the jpg spam, but I'd really like to figure out why Jackett isn't pushing the torrent or magnets back to Medusa in a way that can be passed to deluge. Thanks to anyone with enough insomnia to look at this one. As I look over the stuff, I'm wondering if the issue has something to do with medusa not handling the magnet links well. That reminds me of some SR issues I think I had before, but I can't remember that cause/solution. Edit: Replying to myself here--It was a medusa side issue that they've fixed by adding explicit Jackett providers. Sadly you can't treat all of Jackett as one provider, and have to configure each separately, but it's working with Jackett. Thanks! josh

Thanks guys, I ended up using rclone successfully with this guide here: http://lime-technology.com/forum/index.php?topic=46663 Muchas gracias to stignz--it's a little fiddly at first, but works like a champ!