speeding_ant

Ha, yes.

Hi! SimpleFeatures wasn't really meant to be a replacement for unMenu, it's more a skin for the current GUI with some overlapping plugins to give better unRAID 5 support and to take advantage of the technologies used in the SimpleFeatures base package. You can happily use both side-by-side.

Working out some specifics with Tom before I do anything with SF. Will let the community know when I have further info!

Well, cant you just pull out SF and reboot? after that it should just give you the stock gui. To do it without rebooting would be more of a pain, you would have to go back and replace all the gui files in active memory with the originals... i think the point is that when the emhttp goes unresponsive, it becomes increasingly difficult to *safely* shutdown the array. exactly. This happened again yesterday, SF died again, and I had to use unmenu to stop the array. The sad news is that as soon as I hit Stop on unmenu, it too because non-responsive. I had to use the console and Powerdown, which didn't power all the way down. So, had to issue the reboot command and it rebooted. I did not have these issues with rc11, and it first showed it ugly head in rc12a for me, but is now very bad. SF just isn't happy. @Speeding Ant - do you already know the root cause for this? Even better, do you know how to fix it? If you need syslogs or anything, let me know. I just figured given this has been a issue with so many people reporting it, you must already have figured out what the cause is. Please fix and update SF. If you are running uot of memory, then any process that is idle will be killed. I've had times when logging in would have my login session killed. (granted, I was attempting to compile something I did not have the memory for, so I knew the cause of the OOM condition) It might not be SimpleFeatures itself, but it is a symptom of memory used by one of your other add-ons. +1, the only time I've personally seen the GUI go down is when Plex shat itself. I've raised a few things with Tom anyhow - however he's quite preoccupied with releasing V5 final.

Running the OS X maintenance script fixed this for me. In my case it was a caching issue. Paste the below command into Terminal, it will require your admin password: sudo periodic daily weekly monthly Does that command have anything to do with flushing cache? I never used it before (thanks for the info). •Daily: deletes some temporary files, etc., and records various statistics. On older versions of OSX, some log files are "rotated," but in newer versions that's been moved to another process. •Weekly: rebuilds some system databases. •Monthly: rotates some minor log files, records user statistics.

Running the OS X maintenance script fixed this for me. In my case it was a caching issue. Paste the below command into Terminal, it will require your admin password: sudo periodic daily weekly monthly

I'm having the same issue - it will come back after a minute. I'm working with Tom on a few things, will keep you all in the loop.

Bizarre - I'm running an AMD server as my main unRAID server - not a problem. Do you get this issue without simpleFeatures installed on that server? Can you send through a syslog when it crashes? Thanks

Bizarre - I'm running an AMD server as my main unRAID server - not a problem. Do you get this issue without simpleFeatures installed on that server?

Based on what the web site promises for the new server, it's fairly obvious that the long-promised btrfs cache pool is going to be included in v5.0. Can you confirm that this will be in RC13? [i presume that's the reason for the intervening RC before "final" -- to get some quick feedback on that feature (and perhaps confirm that various fixes work okay) ] 5.0-rc13 will include fix for "slow write" along with some code suggestions from others (e.g., JoeL). It will not include the btrfs pool. The btfs pool will be included in 5.0 "final" as an "experimental" feature. More on this in the 5.0 announcement. even if the experimental feature is not utilized, how can you be 100% sure that the changes to the code won't introduce unforeseen problems with the core functioning? As a programmer, you can be sure that it works when you release a product (which Tom has done, I've never had an issue with the core product). You can NEVER be 100% sure of some uncontrollable variable causing an issue, especially so when you're relying on other 3rd party software (eg, Linux kernel) to do some of the heavy lifting. Every NAS has issues, just look at the release notes.

What differences are there, in terms of software and hardware, between the two servers? Cheers

I hope that a solution to the sloooow parity checks when the web interface is open is included. I'm working through this one with Tom, as it technically shouldn't be possible. However, it's quite obvious he has a lot of work on at the moment, and it's likely to be tested after a new unRAID release.

What makes you think you need it at all? (Most of us with Microsoft clients on the LAN do not.. Only people I can think of who might are those with Linux or MAC clients on their LAN.) +1

What do you want to use it for?

It is bad practice, though from a support point of view I expected permissions issues to be the biggest problem (like running ownCloud, user nobody would not be able to access files from a user share for example). Lighttpd is relatively secure as it is, though this plugin isn't meant to run anything other than a personal blog. A new version of unRAID (being released soon) will be running lighttpd to replace the built in emhttp service. At this point I'd expect it to be configured properly, and my Web Server plugin will cease to exist.

Take that back! I design much nicer sites than this! However, the new site is better than the old one... Your "speeding_ant", I said "speedingant" (aka the imposter) But for you my friend, I take it back either way! There's an imposter?! I had do a member search to make sure. You had me worried Though, actually. If the imposter can continue on my work I'd be happy. Currently no time for anything productive outside of work right now...

Take that back! I design much nicer sites than this! However, the new site is better than the old one...

It's a good concept, though your new site looks outdated in my eyes Still, a nice improvement over the old one!

If you have a timezone set in unRAID, the plugin should automatically insert that timezone into the php.ini file. If not, meh, and edit it manually

Post 2

Post 1

Yeah - I'm running a crap low end AMD CPU. If you're running something decent I'd expect that number to drop significantly. Another way to reduce it is to limit each cam to 5-10 fps. I'm looking into a different build of ffmpeg to improve efficiency also.

Can I ask what kind of resources the Virtual Machine is using? I'm considering doing that too at this point, or, maybe installing unRAID on a full slackware distro (Which apparently zoneminder works on). Also, do you have X/somekindofGUI on your ubuntu machine? Or have you disabled that so it just runs text based? Without Zoneminder installed, Ubuntu server only uses 3% of one core and 2-300MB RAM. With ZoneMinder enabled, and processing 25fps from one cam uses 20-25% CPU, and around 500MB RAM. Not running a GUI, but no need for this as it's a waste of resources. Install Ubuntu server in a VM (quite easy to get this running under unRAID using the plugin), configure network, run: apt-get update, apt-get upgrade, apt-get install ZoneMinder. Boom!

I bought an IP cam, installed it on an Ubuntu virtual machine via the Virtualbox plugin. That works really well, loving Zoneminder!

Sounds like that's an aggregate link failure (if you have that set up). If a link fails and you haven't configured your link to fail over nicely, a loop will occur and thrash the crap out of your switches.