iCUE debug log errors for developer review

[Freeblazin]

First off thanks to the dev team and community support members here on the forums for all the hard work you guys put into supporting these products. Below are a few issues/items I have identified while putting the software through the paces. I hope this information helps to further the development of this awesome control software. Please let me know if more information is needed or if I can perform any further testing.

 

 

Symptom 1: MM800RGB lighting response and effects are extremely slow and sporadic. The addressable LEDs will freeze and fail to change with the pattern speed. For example setting an effect of Predefined - Spiral Rainbow, the LEDs stutter and change color randomly instead of a smooth transition. Same behavior for other effect types. The delay/stutter is also mirrored in the iCUE software display.

 

CUE Log Entry: Numerous entries for "MouseMat LED colors change failed. request timed out for MM800RGB"

 

Additional Details: After some time the device errors out and is flagged with a red triangle in iCUE. Default "Demo" rainbow wave works as expected when iCUE is closed. Device still functions normally under the old version of CUE.

 

[ame=

]

[/ame]

[ame=

]

[/ame]

 

Symptom 2: Numerous log entries of a Device Crash trace error for the VID/PID of my Corsair Link Commander Loader (CLCL)

 

CUE Service Log Entry: FATAL: DevicesMonitor | -> An exception CorsairLink4.Common.Shared.DevicesData.DeviceException (Device crashes. Device: Device instance: vid=1b1c, pid=1c11, serial=ar5w2 Error: Exception of type 'SIUSBXpWrapper.USBDeviceReadException' was thrown.) has occurred. Please see the errors log file for details.

2018-03-28 01:48:14.3797 | 13 | INFO: DevicesMonitor | TIME = 996(avg: 1014) ms

 

 

Symptom 3 : Type Lighting(Ripple) effect stops and does not continue out to the last port of devices in my configuration. The effect travels through the devices, but does not continue out the Commander Pro LED Port 2 devices, which is at the end of the pattern. Not sure if it is due to the rather large number of devices in the chain?

 

Configuration Details:

Lighting Node Pro #1 Port 1 - 4 LL-140 Fans

Lighting Node Pro #1 Port 2 - 4 LL-140 Fans

Lighting Node Pro #2 Port 1 - 5 LL-140 Fans

Commander Pro LED Port 1 - 4 LL-140 Fans

Commander Pro LED Port 2 - 4 LL-140 Fans

CUE Log 2018-03-28T03-22-05.log

Service_Error.log

Service_Trace.log

[Spec Samantha]

Hello! Thank you for the logs and information, I to have a similar issue with my MM800's they will just crash for no reason and go back to the default rainbow profile, I was told by the dev's that my mm800 just stopped accepting commands, I feel that you might be experiencing something similar with your request time out.

 

I will let them know my bug was able to replicated in some other similar fashion but due to most likely the same reason. I would imagine it fixes itself when you restart Icue or does the issue continue even after a reboot?

 

I also forgot to add, for me the timeout definitely shows up alot more frequently in ICUE then CUE, so that is lines right up with it starting to manifest itself in ICUE for you where as you didn't see the issue in CUE.

[Freeblazin]

Hello! Thank you for the logs and information, I to have a similar issue with my MM800's they will just crash for no reason and go back to the default rainbow profile, I was told by the dev's that my mm800 just stopped accepting commands, I feel that you might be experiencing something similar with your request time out.

 

I will let them know my bug was able to replicated in some other similar fashion but due to most likely the same reason. I would imagine it fixes itself when you restart Icue or does the issue continue even after a reboot?

 

I also forgot to add, for me the timeout definitely shows up alot more frequently in ICUE then CUE, so that is lines right up with it starting to manifest itself in ICUE for you where as you didn't see the issue in CUE.

 

Yup, you are correct. Didn't notice anything in CUE, but as the symptoms take some time to manifest I might have just missed it. The symptoms are reset and it works as expected for a few with a close and relaunch of iCUE. I also have Type Lighting(Ripple) configured across all devices and noticed if nothing is typed for a while, when I start typing again the mousepad LEDs respond appropriately for a few until they eventually bug out and begin to timeout again, even though the log contains an entry for every single keypress.

 

Possible that iCUE waits on an acknowledgement of some sort for each LED change command sent and when they are not received it times out.

[Corsair James]

Wow thats a long chain! I'll have our lab test all of these. Please make sure you give me all of the logs as well. I do know though issue 1 is usually due to the USB port. Have you tried using different USB ports?

[Freeblazin]

I was able to revisit the reported errors with the following information gathered from troubleshooting. To note, I did receive the update to iCUE v3.1.133. Updated Logs attached.

 

Symptom 1:

Corsair James, you are correct. The MM8000 produces errors only while attached either directly or through a powered hub on the Realtek Semiconductor SuperSpeed USB 3.1 Hub on the rear IO host controller. It does not produce errors when plugged into any other USB 3 Reg Speed ports. I can provide further testing or details if this is something that could potentially be fixed in Corsair software.

 

Symptom 2:

Device Crashing is actually my ax1600i power supply. I see that it is not on the iCUE supported product list yet and assume the dev team is still coding that one out.

 

Symptom 3:

No update, RGB Type Lighting Link effects do not reach the last set of devices attached at the end of the chain. I have 21 total RGB devices with 16 LEDs each for a total of 336 LEDs in the chain.

iCUE Log Files.zip