jmztaylor

What I have determined is the controller, when off shows up as the entry with IDLE. Turned on its the next line Even selecting both of them to pass through it doesn't work. Dec 4 17:48:21 Tower usb_manager: Info: rc.usb_manager usb_add 8BitDo_IDLE_E417D8F8FA8C /dev/bus/usb/001/024 001 024 Dec 4 17:48:21 Tower usb_manager: Info: rc.usb_manager usb_remove 8BitDo_8BitDo_Ultimate_wireless_Controller_for_PC_E417D8F8FA8C

Also seem to have a similar problem with the 8bitdo controller I have also. Using your USBM, doesn't seem to work at all for it.

no such file for usb.ini

That was it. As for the USB, its still changing IDs each time I switch on the KVM. So I'm going to just add each of them as they pop up. It actually seems like its cycling through 5 of them. Some chinese garbage Im sure. Thanks for the help!

Thats what I started with doing. I assumed the Windows driver didn't like it for some reason. In the same context since I am running this with a drive passed through, if I boot the unraid server from that drive which is my windows install the bluetooth works without issue.

That sure fixed the issue with my KVM. Changing to usb 3 didn't do anything for my bluetooth issue though.

So I am not sure what information is needed so diags are attached. I have a PCI wifi/bluetooth adapter trying to passthrough to a VM. The wifi portion is working but the bluetooth portion is stating unable to start in device manager in windows. The bluetooth module is showing as USB device as it plugs into a header on the motherboard. The other issue is, I have a 2-port KVM that I use to switch between my pc and the VM. Passthrough works just fine once. Then it seems after I switch it once or twice, the USB ID changes sequentially. So if I stop the VM and try to restart it, it fails since its tied to the wrong USB ID now. Is there anything I can do to fix this? tower-diagnostics-20231204-1527.zip

I didnt mean anything negative towards you at all. I use a lot of yours so was the first that came across my mind. You are on top of your support thread like a hawk. But for someone that isn't on that thread all the time, its a lot of info to try and get through for things that might have already been asked or issues ran into. TBF, yes that would be a lot but admins could do a lot too more easily than you.

So one of my biggest issues with the forum is developers that have a huge amount of CAs and single threads for all of them. Finding any specific information is nearly impossible. For the developer this is easier to maintain support, but for end users its a nightmare. Why not break these developers into their own subforum and have a thread for each app? Most people can agree repeating questions is an annoyance and the current setup encourages this without meaning to. In all reality how is any information supposed to be found for example in @ich777 support thread at 140 pages long. (Even though he is very active and quick to reply to posts) Search is average at best and for specific issues the wording might be different so impossible to find. And if searching fails users might start from the first page but that information might be out of date by the time they get to it. Just my .02. And it wouldn't be that hard to implement.

I was about to say, why even need a special calculator. Unraid core feature is any mixture of sizes and as long as you can add you know the size of your array.

I have never used the utility before so I can't help with that. But the repo should have plenty of details https://github.com/ChubbyAnt/sedutil/

Login to unraid cli wget https://github.com/ChubbyAnt/sedutil/releases/download/1.15-5ad84d8/sedutil-cli-1.15-5ad84d8.zip unzip sedutil-cli-1.15-5ad84d8.zip chmod +x sedutil-cli Then use whatever parameters you need to run ./sedutil-cli XXXXXXXXXX

If you are simply looking for the name of the share, they are in the directory /boot/config/shares

I think you are thinking of cache the wrong way. Cache in unraid is just storage. Just typically SSDs so its faster. Docker/VMs happily stay on cache and recommended to be there. Ignoring specific requirements most users will be all spinning disks on array and SSDs on cache.

Rebuilt on top and every seems good. Will check cables if it happens again

Do you have a link for the steps to rebuild on top?

Showed this way after a clean reboot. What should my next steps be? tower-diagnostics-20230731-1010.zip

I added it and should be an update available soon. This is untested so let me know if it works or not.

I have a feature request in to address this. I know it doesn't help you right now but hopefully it will be redesigned soon

Not the same error as this thread but I have seen this previously and did these steps to fix it. It might wipe out some watched history but it should get you back up and running.

SSH into server and type diagnostics This will generate the diagnostics file and tell you where there file is saved to.

Any resolution on this? I am coming across the same exact issue.

I am not the developer or associated with Mailpit. Only created the Unraid template https://github.com/axllent/mailpit

If you dont care about a beep coming from unraid at all you can add mv /bin/beep /bin/beep.bak to your /boot/config/go file just above /usr/local/sbin/emhttp & And once you reboot the beep will be gone.