NAS

Thats a very fair point and anything XML related is always just that bit harder (as in bloody hard) to automate on the command line. I wonder if we could write a version converter. (I pretty much hate XML the amount of time ive wasted trying to manipulate stuff is scary) Content wise though the new description field is exactly the kind of thing normal every day users could do pull requests for which opens the door for a whole new level of contributors which i like.

https://github.com/owncloud/updater/issues/156#issuecomment-121039613 ^^ hinting 8.1 auto update wont happen https://github.com/owncloud/calendar/issues/853 ^^ broke caldav https://github.com/owncloud/calendar/issues/857 ^^ broke IOS I have no problems with bugs thats life but it feels like anyting to do with IOS, calendar or contacts spends as much time broken as working. They cant just keep breaking core apps like this which is perhaps why they dropped them as core apps lol Not hating just when your family relies on it when it breaks it has real world implications

perhaps hang fire. Yet again OC broke stuff for people.

Sorry I missed your reply. Essentially just a description field so that devs can explain what each and every element is for. If you look at some of the current global descriptions they often have per field descriptions bundled together as it t stands. Its i inconsistent and ugly and for the target audience of "non technical app consumers" its not idea. Also perhaps most theis schema to github to track chnages?

http://ark.intel.com/products/42770/Intel-Celeron-Processor-E3200-1M-Cache-2_40-GHz-800-MHz-FSB It is indeed 64bit

How likely is that scenario compared to say someone really having a hot disk and it failing. To me this is just a problem of getting the logging right.

I think we need to be clear that we are only catering for environmental problems and not inherent system design issues. i.e. its too hot a day and not .... if i spin up 10 disks any day the system overheats. Once we accept that then it is obvious that once something overheats it will likely be hours before the room cools again. Since we dont know air temp universally or reliably we cant use this factor so we have to play it safe and spin down forever until manual intervention comes.

I would say that if disks are spun down due to a over temp state then the alert is sent and manual intervention would be needed to bring it back up. Anything other than this just caters for edge cases where certain users are happy to run hotter and they would either need to turn off the feature or change the over temp levels. The problem of the "disk in use" is a global one for unRAID that needs a global solution. For sure it is relevant here but its a separate issue.

I absolutely agree. Unfortunately this is not a problem of our making but as you say its one we have to deal with. Essnetially you have to teach users a bit of docker technology for them to set this up right. The way docker is being "sold" now in unRAID land is a point and click application store and in many ways it is.. unfortunately this problem breaks that model completely. I suspect LT have some thoughts here.

I am late to this party but we absolutely should not be advocating a default of passing /mnt/user RW into all docker running as root. Yes it is easier for the end user but one day it will cause someone to lose all their data, that is an absolute certainty (russian roulette with hardly any bulltets but with thousands of users and random strangers loading the gun = bad). Even if no one ever makes a mistake there are plenty of applications out there that collect info on people. Why on earth would we let all apps see people documents and family photos. Docker hub is the wild west and they intentionally have a very low skill barrier to post there. At the very minimum and ONLY if we must dumb this down to "share everything with everything" it should be RO but I vote as strongly as I can not to do this as it is essentially the mistake all the phone OS's made and look how much that ruined things.

The repo is fully supported (as are the containers we are adding). However, support is limited to getting the container running and accessible, not configuring Plex from within it. We also do not yet support migrating to this container from a Plugin. Some may be able to get that to work, but we do not have a step-by-step guide on how to do it at this point. I would suggest the OP is updated to reflect this then as this sets this repo above all others

Perhaps even the default?

I agree but I want to make the point again that this is more than a "make folks feel better" option. We should never have a warning triangle for a legitimate user configuration. This is more than semantics as it breeds complacency i.e. orange is ok here so subconsciously users can ignore "safe" warnings . Users should be actively encouraged to rid their setup of warning and errors. I agree this is arguably an edge case so if we are sticking with the orange triangle we need to present them information why they have this triangle and how and why they can get rid of it. They shouldnt need to "hit the books" to understand. Early days I am sure we will settle on something in time.

For reference

Can you please share that link because if there is one officially supported one thats the one this thread should recommend.

Sums it up perfectly.

It seems LT now officially say not to use a card reader. http://lime-technology.com/hardware-recommendations/#usbflash "and not using a card reader." Given how surprisingly hard it has been to find a perfect candidate for it this does not surprise me. Perhaps we can discuss this new wording here, specifically to clear up that it is a recommendation only and what this means for this mini project and current reader users. (I suspect this will just be a recommendation etc etc but we should make sure since its on the official site and not the wiki or forum).

I dont want to.... and I dont think we should be teaching users to get used to ignoring soft errors/warnings. Thats what we are ultimately doing here since for certain configs the symbol will be persistent. Also It is a shared symbol since it is a single symbol representing two different configuration states, one which "should self heal" the other has been configured not to. I can see what you are saying but its just a different user usage case. Or put another way. Users shouldn't have to go to a manual and the forum to work out wtf this is about. This should be "one glance just get it stuff". None of the big boys would do it this way. For instance a yellow triangle on my EMC sans would never mean "its fine ignore it" Edit: travelling cant be to detailed this now.

As above, one state looks like an error condition when it is not. The triangle and color may not be intended to look like an error state but we have been taught by countless products to treat symbols like this as soft errors. This is not helped with the strong unprotected wording whiuch unless you think about it looks like an error. Also it is the only place in the entire web GUI that tells you if running the mover is required and/or will move files. For how I use this page the shared symbol doesnt work for me.

I wouldn't trust forums I would only trust the license since that is definitive. Or put another way I doesnt matter if they say yes or no in the forums the license could make a yes a no or vice versa.

I say we should fork the thread to discuss official repo EDGE etc

The license is the one stop shop to clarify that.

Is it worth clarifying the official/support status of this repo. i.e. unlike every other repo if they dont work can licensed users raise an email ticket?

Version 6.0.0 The shares page currently has an orange triangle to signify "Some or all files are on unprotected storage." However there is a difference between files that are waiting to be processed onto protected storage by the mover script and those files on shares set to cache only. Ideally we should differentiate these two data types symbolically.

Good work. If we are capturing suggestions I still maintain every field should be allowed a corresponding description field that can be used to descriptive what the field is. I dont know what the best method of adding this would be though.