Squid

Yeah, that's not the problem. I have a feeling that its something with the database itself. The HTPC originally scanned everything in using the Universal Movie Scraper, which isn't part of Kodi Headless. However, when I switched the sources over to reference IP addresses, I changed it back the TMDB (default). But, maybe there's still remnants of it around (I know that if I didn't have UMS installed on the other HTPCs, they wouldn't be able to update the DB.) I think that I'm going to delete MariaDB, Kodi, and the HTPC and then start everything over again from scratch (grr) Beyond that, Kodi's log is getting spammed with: tdb(__NULL__): tdb_open_ex: called with name == NULL over and over again (couple of hundred appear -> possibly corresponds with attempts to scan). Additionally, manual attempts at updating through the WebUI don't appear to work either.

I've rearranged my servers and HTPC such that sleeping them is now an option, so I figured I'd give this a try. I've got Sonarr communicating with this container (testing says completed successfully). According to Kodi's UI, its communicating with the mySql database no problems. However, the db isn't getting updated after a d/l is completed. I've switched all of my sources to reference IP addresses, rescanned the entire library, and have copied over advancedsettings and sources

Fixed

Works fine on both my servers (Although there's a minor issue where changing the # queued events by itself doesn't activate the apply button). Can you actually write to the flash drive? Try editing config/plugins/checksum/settings/global.json (the delay setting is in seconds ("Pause"))

+1 Nothing drives me more insane than a particular container auto updating but the update is broken. And there's no easy way to back track. Hence why i try and avoid auto updates at all costs. The vast majority of updates that come through on containers are for bug fixes that dont affect the majority of users. But the mentality of having to have the latest couch potato is pervasive even though there is nothing wrong with the older versions that anyone can see. Docker is/was designed so that what works on one users system works on all systems. But with having auto updates means that everyone winds up on a different version, and goes against that fundamental premise.

I'll check it out. I'm assuming that you're hitting apply

Confirmed, no longer appears on my server that doesn't support blake2 Thanks. If you had a share using it, make sure to change the algorithm from md5 to something else then back to md5 so that the change takes effect in the stored settings

Updated to 2015.11.16 - Continuing improvements to UI for PAR2 - Laid ground work for integrations of PAR2 into the scheduler system (no scheduled tasks for this just yet however) - Disallow creation of Blake2 checksums for systems not able to support it. The blake2 issue was a fluke that I found it, and unfortunately after the fix was programmed for it, that particular server got repurposed, so I am currently unable to easily test if it still properly disallows Blake2. If someone could test that fails the command given here: http://lime-technology.com/forum/index.php?topic=43396.msg420079#msg420079. When going to the share creation tab, Blake2 should no longer appear on systems that cannot support it. If you were using blake2, and the system doesn't support it, then the net result is that an infinite loop on creation would happen which you can fix by stopping the monitor. But, you will have to switch any shares that you were having using Blake2 to MD5 / SHA. (To do this, you'll have to change the settings for that share - even though it will already say MD5). Note that this only applies to users who fail the blake2 test and were using blake2. If you weren't using Blake2 or you pass the test then nothing needs to be done.

The way to tell would be to stop the monitor, look at one of your movie folders to see if the hash file is in there. Then start the monitor, wait for the watches to be established and recreate the checksums. Assuming that nothing has changed in the folders, it should recreate the hash files (the checksum log won't show the skipped folders, only the ones with changes)

At work right now (and life has been getting in the way of updates to the plugin), but the only way it would continually recalculate everything over and over again is if it was doing it as Blake2 but the system isn't capable of running Blake (i just found that a couple of days ago and have been very busy so haven't had a chance to release an update)

On my system its harmless (annoying since it shows on any putty session, but harmless). But, on a quick and dirty google search, it looks like it could be docker related NFS related within an LXC container (docker IIRC leverages LXC containers) I am curious if when the message appears for you if that's when one of your containers crash. (Mine never have at all)

md5 has the advantage of being arguably the most portable of all the algorithms (and the fastest at generation) But, there is a greater chance of "collisions" with it than with sha1 / 256 or blake2. A collision means that the original file if corrupted could wind up generating the same hash value as the non corrupted. Collisions are possible under any hashing method. Its just a tad more likely with md5 versus the other algorithms. That being said, this is all mathematical abstractions, and in the real-world (ie: non cryptography applications) the chances of a corruption in a file generating the same hash value are slim to none. In other words, unless you're working for the NSA I wouldn't particularly worry about it. The flaws in MD5 / SHA1 are more concerning if someone is trying to crack your password than with file corruption.

Just a compatibility note here. It appears that Blake2 requires the SSE4.1 CPU extensions. Unfortunately, not all CPU's have these instruction extensions (in my case, my A6-3500, whereas my other 2 CPU's do have those extensions) I will be issuing a patch to disallow the use of Blake2 on systems where it is incompatible. If you have been using blake2 via this plugin, you can tell if you are affected by either looking at one of the generated hash files (there will be no hash within the file) or by entering in the following command: /usr/local/emhttp/plugins/checksum/include/b2sum /usr/local/emhttp/plugins/checksum/include/b2sum (an attempt to generate a checksum of itself) If the command returns "Illegal Operation", then blake2 is incompatible with your system and you should switch to a different hash algorithm.

"the server doesn't have enough......." what's the rest of that line? Beyond that, since this is happening while Sab is unpacking or something, then you best course of action is to pin Sab to certain cores instead of leaving it access to everything so that it doesn't steal all the CPU cycles available. See http://lime-technology.com/forum/index.php?topic=36257.msg337500#msg337500

observium/observium

Most apps don't have a configurable setting for where to store the logs. And, I'm not even sure what happens if you create a mapping for a folder that already exists within the container (eg /var/logs to /tmp). Does it store it outside? inside? both? Someone like sparklyballs would know.

@Brit I posted in here to see if anyone else has the same problem so we can collaborate to fix it. If you don't have the problem, that's great. But telling those of us that do have the problem that its our problem and we have to fix it ourselves is not helpful. What would be helpful is if you could tell us which dockers you are using that have not given you any problems so we can possibly eliminate them from the list of potentially misbehaving dockers. Running 24/7 Needo / Couchpotato Needo / MariaDB LinuxServer / NZBGet Needo / Plex Needo / Sonarr Hurricane / Ubooquity Running On Demand cadvisor Dolphin Handbrake MKVToolNix-GUI

Thought it was like this... Gave up on that... Crayons just don't taste the same anymore (and they don't mix too well with beer)

You can always email etransfers to [email protected] Seriously though, I really don't care. This is how I relax.

Coming. Also number of blocks. More advanced features like block size, etc which are only useful for usenet probably won't make it into the GUI.

For the most part, I would tend to agree, however there has been some evidence that updates to containers are increasing the docker.img utilization (most likely related to C.O.W.) However, like you I have seen no abnormal increases in my utilization, and have never run out of space using 20G. But, any sudden and drastic increases in image utilization would have to be related to configuration and/or misbehaving apps (I believe there was a report somewhere about a log file for a particular app growing quickly to be in the GB range)

Updated to 2015.11.10 This release has optional PAR2 creation / verification / repair. The PAR2 side of things would be Beta. I released it just to see if I'm on the right track here. Currently, its 100% a manual operation (no scheduling yet) It is however fully functional and (basically) bug free. There are some issues with regards to the logging, and verify / repair buttons, but it does work as advertised. In a couple of days once its closer to RC status I'll actually explain what PAR2 is (for those who don't know) and how it may save your bacon, but in the meantime if you know and understand PAR2 feel free to play around. Also, this is now a "Suite" of related apps, so rather than throw a couple of icons into User Utilities, a new section (Checksum Suite) is created within Settings.

lol... Been waiting for you to bring that up...

If you mean how do you install it, just install Community Applications and go from there: http://lime-technology.com/forum/index.php?topic=40262.0

My old Seagate 3000DMs can hit it (1TB / platter, 7200RPM). Spec'd at max sustained of 210MB/s. Diskspeedtest.sh reports they max out for me at 207MB/s