kpereira

You seem to misunderstand. I don't care what your opinion on the notification feature or the solicitation is and I'm not criticizing it. I am criticizing what you call "evidence". Just because someone else made an illogical conclusion doesn't make yours valid. Furthermore, there has already been one solicitation through this feature. That's a fact. The developer of the plug-in is offering no guarantee that there won't be additional solicitations in the future. To say it's far-fetched additional solicitations will be injected in the future is just ignorant. Lastly, this is not a limetech plug-in, so I don't know what makes you think limetech is somehow okay with this behavior. I have raised my concerns to their support team, though, so we'll see what they say.

This isn't even logical. There is no voting mechanism, you're just assuming these 800+ people were okay with the solicitation. By that logic, can we just assume everyone who did not participate after the notification was not okay with the solicitation? Since we're just assuming here, I'll assume that the number of people who did not participate after the solicitation outnumber the people who did participate.

The point is that you're soliciting on my server without consent or knowledge. It's one thing to give notifications regarding server related issues or updates, but to insert your own opinions or ideas sets a precedence. What "must see" notifications can we expect in the future? I think what you did was wrong even if you had good intentions. That is all.

If you took the time to read my post, you'd notice that I specifically said the release notes. There's a big difference between release notes that show up in the server interface and a post on the support forum that may or may not be seen.

Just want to say, I don't appreciate the covid-19 banner being injected. I understand the intentions may be good, but are they really? It's shady that there's zero mention of the banner in the release notes. What else is being injected into the plug-in that isn't in the release notes? Gonna have to reconsider further use of this plug-in since it can't be trusted.

I'm having an issue where unraid is saying there's an update available for linuxserver/transmission:latest, but when I apply the update it's the same version that's already installed. After the "install" the update prompt goes away until I check for docker updates again, at which point I'm prompted to update again. I tried uninstalling and installing the docker via community apps, but the problem persists. Has anyone run into this or have any ideas to fix it? EDIT: I should also mention that this isn't happening for any of my other docker containers.

If you toggle the advanced view and remove the false values, you can get it working until a permanent fix is made.

Any word on this showing up in community apps?

I have this running on br0 with a static IP, and it's been working great.

I looked into this, and it turns out this isn't related to nvme drives. It looks like drives mounted via the unassigned devices plugin don't get included in the exclude list, but they are included in the autofan script. I think it's a discrepancy between the different ways drive info is being fetched.

FYI, for the autofan plugin, the new exclude disks feature doesn't list nvme drives. I'm going to take a look later and potentially submit a PR for it.

I submitted a pull request to add nvme support. Please take a look at it when you have a chance.

That makes sense. Is there any plan to do that? Thanks.

Hi, I'm having an issue with the auto fan control plugin. The problem I'm having is that the plugin seems to be incorrectly sensing the temperature of one of my drives. The drive in question is an nvme drive mounted via the unassigned devices plugin. When the nvme drive is the only spun-up drive, the auto fan control plugin says that it's decreasing the fan speed because the hottest drive is 32 fahrenheit. The problem with this is that at the time the drive was actually 91 fahrenheit. I have an hdd also mounted via unassigned devices and auto fan control plugin adjusts the fan speed based on its correct temperature. It occurs to me that 91 fahrenheit is roughly 32 celsius. Not sure if that's of any significance. Any help with this issue will be greatly appreciated. Thanks. EDIT: The nvme drive is now at 97 fahrenheit, and auto fan control still reports it at 32 fahrenheit. Strike the celsius thing I guess.

Okay, I'll try there. Thanks.

Hi, I use the dynamix auto fan plugin to control my case fans based on the hard drive temperatures. After the recent UD update, the auto fan plugin is reporting the temperature of my nvme drive, mounted by UD, as 32 fahrenheit while the UD gui reports it at 91 fahrenheit. I'm guessing the 32 is actually celsius, but that's just a guess. I'm not sure where the issue lies, but since UD just released an update related to nvme temperatures, I figured I'd start here. Any help resolving this will be greatly appreciated.

Cookie fix is verified.

I do not have cookies disabled, but I did some digging around and have a suspicion as to what the problem is. It looks like 2 unassigned-complete-view cookies are being set, each with a different path value. When the cookie is set from the main tab, the path is the root "/", but when setting the cookie from the UD page, the path is "/Main". Once the cookie with the path "/Main" is set, the UD interface on the main tab always reads from that cookie, but still writes to the cookie with the root path. I haven't tested, but I imagine always setting the the path to the root will resolve the issue. You can specify this in the options. $.cookie('unassigned-complete-view', value, {path: '/'}); By the way, I'm using the latest version of Chrome.

Minor Bug Report I noticed that when I toggle the complete/simple switch from the main tab, the setting doesn't save. If I refresh the page after toggling, the switch is back to its original state. If I go to the UD page through the plugins tab, and toggle the switch, the setting does save and the state persists in the main tab. I'm making an assumption that this is a UD issue and not some conflict specific to my system. It would be great if someone else could confirm the behavior I'm describing.

After one of the recent updates, I started having issues with detection of one of my drives handled by UD. Specifically, this is an NVMe drive (Samsung EVO 960). The problem I'm having is that my drive is now listed as missing under the historical devices, but it also shows up under unassigned devices with the option to format it. The volume for this drive is still mounted and data that was stored on the volume is still accessible. I've seen a lot of chatter about NVMe here in recent posts. Is this a known issue that is being worked on?

What exactly does this do? Does it strictly copy files from unRAID to S3, or does it perform a sync between unRAID and S3? So if you were to delete a file off unRAID, will the object be removed from your S3 bucket?

Hey All, When upgrading to unRAID v6 I experience the issue described here: http://lime-technology.com/forum/index.php?topic=36295.0 Could anyone suggest a SATA card that can be used in mixed mode and does not have this issue? Please post links to your recommendations in your comment. Thanks!

Hey trurl, apologies for the lack of info. I'm at work right now, so I don't have access to all the specs and everything. What I mean by faulty is this. v6 has a dashboard in the web gui. One of the columns is "faulty" and this is where that drive is listed. I'm also unable to add it to the array. In v5 the drive functions fine.

Hey All, I tried upgrading to v6.0.1 yesterday and one of my drives came up as faulty after the upgrade. The parity was also listed as not valid, but I assume this is because of the faulty drive. I rolled back to v5.0.6 and there were no issues with the drive or the parity. The drive v6.0.1 is listing as faulty is the only drive I have connected to a SATA controller card. What I'm thinking is that my controller card is supported by v5.x, but not by v6.x. Does this sound probable? Thanks.