zinkpro45

Disregard, didn't know that "Skip Updating Entries" blocks this. I had to update the setting to be something closer to this:

Seemingly having an issue with this where it just doesn't check for new issues automatically. Has anyone else ran into this? I'm only using the Weeb Central extension as a source. Going to a manga and clicking update manually grabs everything new, but then it just won't check automatically after that.

NOPE! The wonderful solution is to just buy a compatible NVME drive.

Any update on getting this to work? @limetech We'd really like this patch re-merged back into the kernel or a different working way of getting this controller to work.

Yes, which is why we had a Patch that fixed it. Don't remove the patch until you have a proper method of supporting the device that the patch fixed. A very very large portion of NVME drives use this controller. There's no reason why Unraid can't re-add the patch and get this working until a suitable non-patch solution can be found.

Yup. 6.7 straight up doesn't work. Thebrelease candidates before the patch was removed work great. You know honestly, if you pay for a product and something's broken in it, it's not unreasonable to expect communication about why it's broken and fixes. That on top of the fact that it was working on the release candidates means they should revert to making the patch included by default until unraid can communicate how to make the new way work properly.

Please someone respond to this. Weeks without an update is not acceptable.

Is there any luck with this? I'd really like to upgrade to the newest version.

Final Release of 6.7 completely broke my windows VM with the 2262 controller. Used the workaround that was stated in the link above. Reverted back to RC5.

That would be amazing, thanks!

Any update to this? I have a HP EX920 and would very much like to be able to passthrough the drive to my VM.

Latest version on normal (Intel, supermicro) hardware.

Anyone?

Alright I've posted here before about this and never got any responses. Up until now I was able to fix it by blowing away my docker completely and recreating everything, but it seems that doesn't even work now. My issue is that after restarting my docker, after an undetermined amount of time it looks like the daemon just dies. It shows as offline. The logs look like this when I try to start the daemon up. 2018-10-02 20:52:52,486 DEBG 'deluge-web-script' stderr output: [ERROR ] 20:52:52 main:243 There is a deluge daemon running with this config directory! 2018-10-02 20:52:52,486 DEBG 'deluge-web-script' stderr output: [ERROR ] 20:52:52 main:244 You cannot run multiple daemons with the same config directory set. [ERROR ] 20:52:52 main:245 If you believe this is an error, you can force a start by deleting /config/deluged.pid. So I delete deluged.pid and restart the docker and everything starts back up fine, but the issue just happens again, sometimes as quickly as 10 minutes later. The docker image has plenty of space, so it's not that. But I can't figure out what the issue is. It's been present on and off for more than a year now.

I'm having the same issue. After a few hours the daemon will crash. The web ui is still accessible, but nothing like Sonarr or Radarr can connect to it. Also nothing will appear in the GUI like in your picture. Restarting the docker helps, as does restarting the daemon. Not sure what's wrong but it's been happening for about a month now. Really frustrating.