[GH-ISSUE #929] Automatic address switching does not follow the order

kerem commented

2026-02-28 12:06:13 +03:00

Owner

Originally created by @itagagaki on GitHub (May 11, 2025).
Original GitHub issue: https://github.com/1Remote/1Remote/issues/929

Originally assigned to: @VShawn on GitHub.

In automatic address switching mode, it would connect to the alternate even if the primary could connect.
In the availability detection window, the primary was red and the alternate was green.

Primary is laptop over Wi-Fi, alternate is wired desktop.

The code seemed to be trying to shift the candidates by 200 milliseconds, so I changed it to 1000 and both the primary and alternate turned green, but it still seemed like the alternate succeeded first and canceled the primary.

Originally created by @itagagaki on GitHub (May 11, 2025). Original GitHub issue: https://github.com/1Remote/1Remote/issues/929 Originally assigned to: @VShawn on GitHub. In automatic address switching mode, it would connect to the alternate even if the primary could connect. In the availability detection window, the primary was red and the alternate was green. Primary is laptop over Wi-Fi, alternate is wired desktop. The code seemed to be trying to shift the candidates by 200 milliseconds, so I changed it to 1000 and both the primary and alternate turned green, but it still seemed like the alternate succeeded first and canceled the primary.

kerem

2026-02-28 12:06:13 +03:00

closed this issue
added the
bug
label

kerem commented

2026-02-28 12:06:14 +03:00

Author

Owner

@VShawn commented on GitHub (May 12, 2025):

The code seemed to be trying to shift the candidates by 200 milliseconds, so I changed it to 1000 and both the primary and alternate turned green, but it still seemed like the alternate succeeded first and canceled the primary.

Could it be that the wifi delay? By default, 1RM first try to quickly check the primary address, and if there’s no response within 100ms, it will then attempt to ping the alternate addresses simultaneously, and using the first address responds.

I’ve encountered primary address quick check failed with poor wifi signals, but after the availability check window ended, it consistently returned to the primary address.

I changed it to 1000 blabal: It doesn’t make sense. Have you tried debugging it with breakpoints? We need to first determine which address was pinged successfully first.

@VShawn commented on GitHub (May 12, 2025): > The code seemed to be trying to shift the candidates by 200 milliseconds, so I changed it to 1000 and both the primary and alternate turned green, but it still seemed like the alternate succeeded first and canceled the primary. Could it be that the wifi delay? By default, 1RM first try to quickly check the primary address, and if there’s no response within 100ms, it will then attempt to ping the alternate addresses simultaneously, and using the first address responds. I’ve encountered `primary address quick check failed` with poor wifi signals, but after the availability check window ended, it consistently returned to the primary address. `I changed it to 1000 blabal`: It doesn’t make sense. Have you tried debugging it with breakpoints? We need to first determine which address was pinged successfully first.

kerem commented

2026-02-28 12:06:14 +03:00

Author

Owner

@itagagaki commented on GitHub (May 12, 2025):

I changed it to 1000 blabal: It doesn’t make sense. Have you tried debugging it with breakpoints? We need to first determine which address was pinged successfully first.

I'm just presenting a result as supplemental information to a bug report. Please don't ask someone who just reported a bug to investigate it, or make sense in the reported fact.

@itagagaki commented on GitHub (May 12, 2025): > I changed it to 1000 blabal: It doesn’t make sense. Have you tried debugging it with breakpoints? We need to first determine which address was pinged successfully first. I'm just presenting a result as supplemental information to a bug report. Please don't ask someone who just reported a bug to investigate it, or make sense in the reported fact.

kerem commented

2026-02-28 12:06:14 +03:00

Author

Owner

@itagagaki commented on GitHub (May 12, 2025):

Could it be that the wifi delay? By default, 1RM first try to quickly check the primary address, and if there’s no response within 100ms, it will then attempt to ping the alternate addresses simultaneously, and using the first address responds.

I’ve encountered primary address quick check failed with poor wifi signals, but after the availability check window ended, it consistently returned to the primary address.

Ah, okay.
I thought 1Remote would test a list starting with primary followed by alternatives. I see that it does not, it tests the primary first, and if there is no response within 100 milliseconds, it tests the alternatives (with shifting the start by 200 milliseconds each).
So even if the primary was available, if it did not respond within 100 milliseconds, it would connect to one of the alternatives. Because of this specification, this is not a bug, but a possible behavior.

@itagagaki commented on GitHub (May 12, 2025): > Could it be that the wifi delay? By default, 1RM first try to quickly check the primary address, and if there’s no response within 100ms, it will then attempt to ping the alternate addresses simultaneously, and using the first address responds. > > I’ve encountered `primary address quick check failed` with poor wifi signals, but after the availability check window ended, it consistently returned to the primary address. Ah, okay. I thought 1Remote would test a list starting with primary followed by alternatives. I see that it does not, it tests the primary first, and if there is no response within 100 milliseconds, it tests the alternatives (with shifting the start by 200 milliseconds each). So even if the primary was available, if it did not respond within 100 milliseconds, it would connect to one of the alternatives. Because of this specification, this is not a bug, but a possible behavior.

kerem commented

2026-02-28 12:06:14 +03:00

Author

Owner

@VShawn commented on GitHub (May 13, 2025):

Please don't ask someone who just reported a bug to investigate it, or make sense in the reported fact.

Well, I asked just because you are one of the team member. If it were feedback from a user, I would not ask them to debug. Annnd if you are no longer interested in participating in the development never mind it's ok. I will not ask or discuss debugging matters with you in future.

I thought 1Remote would test a list starting with primary followed by alternatives. I see that it does not

Since the timeout seems to be set at 5 seconds, if I have 5 addresses are tested one by one, and only the last one is reachable, it would require the user to wait for 4 * 5 seconds before open the conn. I consider this UX to be suboptimal. Therefore, I decided to conduct simultaneous testing and connect to the first address that completes the test.

@VShawn commented on GitHub (May 13, 2025): > Please don't ask someone who just reported a bug to investigate it, or make sense in the reported fact. Well, I asked just because you are one of the team member. If it were feedback from a user, I would not ask them to debug. Annnd if you are no longer interested in participating in the development never mind it's ok. I will not ask or discuss debugging matters with you in future. > I thought 1Remote would test a list starting with primary followed by alternatives. I see that it does not Since the timeout seems to be set at 5 seconds, if I have 5 addresses are tested one by one, and only the last one is reachable, it would require the user to wait for 4 * 5 seconds before open the conn. I consider this UX to be suboptimal. Therefore, I decided to conduct simultaneous testing and connect to the first address that completes the test.

kerem commented

2026-02-28 12:06:14 +03:00

Author

Owner

@itagagaki commented on GitHub (May 13, 2025):

I'm honored that you recognize me as a member of the team, and I will contribute in any way I can. Because this product is useful and has great potential for me.
I was just a little surprised by your dismissive response to my report.

Since the timeout seems to be set at 5 seconds, if I have 5 addresses are tested one by one, and only the last one is reachable, it would require the user to wait for 4 * 5 seconds before open the conn. I consider this UX to be suboptimal. Therefore, I decided to conduct simultaneous testing and connect to the first address that completes the test.

Understood. Thank you.

@itagagaki commented on GitHub (May 13, 2025): I'm honored that you recognize me as a member of the team, and I will contribute in any way I can. Because this product is useful and has great potential for me. I was just a little surprised by your dismissive response to my report. > Since the timeout seems to be set at 5 seconds, if I have 5 addresses are tested one by one, and only the last one is reachable, it would require the user to wait for 4 * 5 seconds before open the conn. I consider this UX to be suboptimal. Therefore, I decided to conduct simultaneous testing and connect to the first address that completes the test. Understood. Thank you.

kerem commented

2026-02-28 12:06:14 +03:00

Author

Owner

@VShawn commented on GitHub (May 13, 2025):

I was just a little surprised by your dismissive response to my report.

I didn't mean to be dismissive at all. I apologize if my response made you feel uncomfortable. English is not my native language, so it's possible that I unintentionally conveyed a different meaning while writing.

My TRUE intention was to ask if you had done any debugging after encountering the issue, especially you mentioned trying to adjust the delay time in the code. I assumed you might have done some debugging and wanted to inquire about the results for our further analysis.

@VShawn commented on GitHub (May 13, 2025): > I was just a little surprised by your dismissive response to my report. I didn't mean to be `dismissive` at all. I apologize if my response made you feel uncomfortable. English is not my native language, so it's possible that I unintentionally conveyed a different meaning while writing. My TRUE intention was to ask if you had done any debugging after encountering the issue, especially you mentioned trying to adjust the delay time in the code. I assumed you might have done some debugging and wanted to inquire about the results for our further analysis.

kerem commented

2026-02-28 12:06:14 +03:00

Author

Owner

@VShawn commented on GitHub (May 17, 2025):

During the investigation, I suddenly realized that I had used the CancellationTokenSource incorrectly in the Auto address switching section, which caused occasional throw exceptions when testing address connectivity. This might be the reason for the not follow the order issue you mentioned.

In short, I did not handle the exceptions thrown by Task.Delay(500, cancellationToken.Token).

see: https://stackoverflow.com/questions/20509158/taskcanceledexception-when-calling-task-delay-with-a-cancellationtoken-in-an-key

@VShawn commented on GitHub (May 17, 2025): During the investigation, I suddenly realized that I had used the CancellationTokenSource incorrectly in the `Auto address switching` section, which caused occasional throw exceptions when testing address connectivity. This might be the reason for the `not follow the order` issue you mentioned. In short, I did not handle the exceptions thrown by Task.Delay(500, cancellationToken.Token). see: https://stackoverflow.com/questions/20509158/taskcanceledexception-when-calling-task-delay-with-a-cancellationtoken-in-an-key

Rows
Columns

[GH-ISSUE #929] Automatic address switching does not follow the order #1714