03-13-2025, 09:11 AM
(This post was last modified: 03-13-2025, 10:14 AM by Jesse Johannesen.
Edit Reason: added info
)
(03-05-2025, 04:09 AM)ekkomouse Wrote: https://www.dropbox.com/scl/fi/3ydgvnjoh...zicu8&dl=0
Here I was experiencing the clock issue on USB-C, so I factory reset the second mrcc, I only had one routing to a mioxl by usb D this time, that input was not routed anywhere else, but I was receiving double clock on remote 12. Filtering inputs from D did not remove clock, filtering output on D did work, but again it was not assigned anywhere. So it seems like there’s something routed before it reaches the USB filters.
This one is a fairly complicated issue and I am having trouble following the exact steps to recreate it from the video, so I am hoping that you might be available for a zoom call to take a closer look. If you could reach out to me at Support@conductivelabs.com with a few time slots you'll be available (I am busy Wed Sat and Sun 8am to 6pm Pacific Time, but can make time pretty much any other days) I can set us up a call for us.
(03-13-2025, 04:37 AM)ekkomouse Wrote: There’s a definite bug when using two MRCC units and routing from one to another on usb, there are phantom routings that come back unintentionally, I think I’ve posted a couple videos already. Can you confirm that you’ve got this and understand?
https://www.dropbox.com/scl/fi/rj0y5923d...swncq&dl=0
Got it. I am looking at some of this stuff today to try and reproduce it.
Quote:(03-01-2025, 02:24 PM)ekkomouse Wrote:OK so for this one, the video doesn't show the MRCC doing anything funky. I recreated the issue by sending MRCC internal clock on PC port 1 of unit 1 to the USB host C port of unit 2 Factory restting unit 2, I still see Red Clock Arrows on the display. I think this is the expected behavior, as I get the same results from sending via DIN as well.
Separately I have an issue where I have a routing where clock is going from MRCC one to two, MRCC 2 Is sending clock back to a remote routing on 12 unintentionally when it’s not assigned , The only way I can stop it is to filter on the outport page.
https://www.dropbox.com/scl/fi/nv8podofy...ksdrs&dl=0
Not to say the issue you're reporting doesn't exist, but what is shown in the video doesn't illustrate an issue as far as I can tell.
If you were to factory reset the MRCC that is the clock source and it still showed red arrows on the destination then we would be looking at an issue, but here you are factory resetting the destination unless I am misunderstanding?
(03-05-2025, 04:09 AM)ekkomouse Wrote: https://www.dropbox.com/scl/fi/3ydgvnjoh...zicu8&dl=0
Here I was experiencing the clock issue on USB-C, so I factory reset the second mrcc, I only had one routing to a mioxl by usb D this time, that input was not routed anywhere else, but I was receiving double clock on remote 12. Filtering inputs from D did not remove clock, filtering output on D did work, but again it was not assigned anywhere. So it seems like there’s something routed before it reaches the USB filters.
This one is a fairly complicated issue and I am having trouble following the exact steps to recreate it from the video, so I am hoping that you might be available for a zoom call to take a closer look. If you could reach out to me at Support@conductivelabs.com with a few time slots you'll be available (I am busy Wed Sat and Sun 8am to 6pm Pacific Time, but can make time pretty much any other days) I can set us up a call for us.
(03-13-2025, 04:37 AM)ekkomouse Wrote: There’s a definite bug when using two MRCC units and routing from one to another on usb, there are phantom routings that come back unintentionally, I think I’ve posted a couple videos already. Can you confirm that you’ve got this and understand?
https://www.dropbox.com/scl/fi/rj0y5923d...swncq&dl=0
Got it. I am looking at some of this stuff today to try and reproduce it.