adam/pyMC_Repeater
1
0 Fork 0
mirror of https://github.com/pyMC-dev/pyMC_Repeater.git synced 2026-10-30 19:51:59 +01:00
Code Issues 41 Packages Projects Releases Wiki Activity

Issue: feat/companion #49

New Issue
Closed
opened 2026-10-27 09:30:13 +01:00 by adam · 7 comments
adam commented 2026-10-27 09:30:13 +01:00
Owner
Copy link
Copy source

In the new feat, when i set channels and contacts, the channels and contacts didn't live through a device disconnect from the official MC app.

In the new feat, when i set channels and contacts, the channels and contacts didn't live through a device disconnect from the official MC app. <!-- github-sync-id:4039459483 -->
adam closed this issue 2026-10-27 09:30:13 +01:00
adam commented 2026-10-27 09:30:14 +01:00
Author
Owner
Copy link
Copy source

Do you have any indication whether it is a persistence issue or a loading issue?

When you connect, the logs should show something like:

2026-03-07 14:26:33,069 - CompanionFrameServer - INFO - Companion cmd 0x01 (1) len=24
2026-03-07 14:26:33,070 - CompanionFrameServer - INFO - Companion cmd 0x36 (54) len=2
2026-03-07 14:26:33,070 - CompanionFrameServer - INFO - Companion cmd 0x14 (20) len=1
2026-03-07 14:26:33,071 - CompanionFrameServer - INFO - Companion cmd 0x06 (6) len=5
2026-03-07 14:26:33,072 - CompanionFrameServer - INFO - Companion cmd 0x04 (4) len=1
2026-03-07 14:26:33,257 - CompanionFrameServer - INFO - Companion cmd 0x16 (22) len=2
2026-03-07 14:26:33,257 - CompanionFrameServer - INFO - Companion device info sent: FIRMWARE_VER_CODE=10 (byte at index 1), version string='10.0', frame_len=82
2026-03-07 14:26:33,262 - CompanionFrameServer - INFO - Companion cmd 0x1f (31) len=2
2026-03-07 14:26:33,262 - CompanionFrameServer - DEBUG - Companion cmd 0x1f (GET_CHANNEL), payload_len=2
2026-03-07 14:26:33,297 - CompanionFrameServer - INFO - Companion cmd 0x1f (31) len=2
2026-03-07 14:26:33,297 - CompanionFrameServer - DEBUG - Companion cmd 0x1f (GET_CHANNEL), payload_len=2
2026-03-07 14:26:33,335 - CompanionFrameServer - INFO - Companion cmd 0x1f (31) len=2
2026-03-07 14:26:33,335 - CompanionFrameServer - DEBUG - Companion cmd 0x1f (GET_CHANNEL), payload_len=2
2026-03-07 14:26:33,335 - CompanionFrameServer - INFO - Companion cmd 0x1f (31) len=2
2026-03-07 14:26:33,335 - CompanionFrameServer - DEBUG - Companion cmd 0x1f (GET_CHANNEL), payload_len=2
2026-03-07 14:26:33,336 - CompanionFrameServer - INFO - Companion cmd 0x1f (31) len=2
2026-03-07 14:26:33,336 - CompanionFrameServer - DEBUG - Companion cmd 0x1f (GET_CHANNEL), payload_len=2
2026-03-07 14:26:33,336 - CompanionFrameServer - INFO - Companion cmd 0x1f (31) len=2
2026-03-07 14:26:33,336 - CompanionFrameServer - DEBUG - Companion cmd 0x1f (GET_CHANNEL), payload_len=2
2026-03-07 14:26:33,336 - CompanionFrameServer - INFO - Companion cmd 0x1f (31) len=2
...

Followed by a bunch of fetches for contacts.

Do you have any indication whether it is a persistence issue or a loading issue? When you connect, the logs should show something like: ``` 2026-03-07 14:26:33,069 - CompanionFrameServer - INFO - Companion cmd 0x01 (1) len=24 2026-03-07 14:26:33,070 - CompanionFrameServer - INFO - Companion cmd 0x36 (54) len=2 2026-03-07 14:26:33,070 - CompanionFrameServer - INFO - Companion cmd 0x14 (20) len=1 2026-03-07 14:26:33,071 - CompanionFrameServer - INFO - Companion cmd 0x06 (6) len=5 2026-03-07 14:26:33,072 - CompanionFrameServer - INFO - Companion cmd 0x04 (4) len=1 2026-03-07 14:26:33,257 - CompanionFrameServer - INFO - Companion cmd 0x16 (22) len=2 2026-03-07 14:26:33,257 - CompanionFrameServer - INFO - Companion device info sent: FIRMWARE_VER_CODE=10 (byte at index 1), version string='10.0', frame_len=82 2026-03-07 14:26:33,262 - CompanionFrameServer - INFO - Companion cmd 0x1f (31) len=2 2026-03-07 14:26:33,262 - CompanionFrameServer - DEBUG - Companion cmd 0x1f (GET_CHANNEL), payload_len=2 2026-03-07 14:26:33,297 - CompanionFrameServer - INFO - Companion cmd 0x1f (31) len=2 2026-03-07 14:26:33,297 - CompanionFrameServer - DEBUG - Companion cmd 0x1f (GET_CHANNEL), payload_len=2 2026-03-07 14:26:33,335 - CompanionFrameServer - INFO - Companion cmd 0x1f (31) len=2 2026-03-07 14:26:33,335 - CompanionFrameServer - DEBUG - Companion cmd 0x1f (GET_CHANNEL), payload_len=2 2026-03-07 14:26:33,335 - CompanionFrameServer - INFO - Companion cmd 0x1f (31) len=2 2026-03-07 14:26:33,335 - CompanionFrameServer - DEBUG - Companion cmd 0x1f (GET_CHANNEL), payload_len=2 2026-03-07 14:26:33,336 - CompanionFrameServer - INFO - Companion cmd 0x1f (31) len=2 2026-03-07 14:26:33,336 - CompanionFrameServer - DEBUG - Companion cmd 0x1f (GET_CHANNEL), payload_len=2 2026-03-07 14:26:33,336 - CompanionFrameServer - INFO - Companion cmd 0x1f (31) len=2 2026-03-07 14:26:33,336 - CompanionFrameServer - DEBUG - Companion cmd 0x1f (GET_CHANNEL), payload_len=2 2026-03-07 14:26:33,336 - CompanionFrameServer - INFO - Companion cmd 0x1f (31) len=2 ... ``` Followed by a bunch of fetches for contacts. <!-- github-comment-id:4017548388 -->
adam commented 2026-10-27 09:30:15 +01:00
Author
Owner
Copy link
Copy source

@rightup informed me about an updated build, and after testing pyMC_Repeater v1.0.6.dev185+g884de123b, the channels now stay synced when switching between the MeshCore Windows app over TCP and my Android phone.

Contacts do not sync unless they are marked as favorites. Not a big deal for me, but just wanted to point it out.

@rightup informed me about an updated build, and after testing `pyMC_Repeater v1.0.6.dev185+g884de123b`, the channels now stay synced when switching between the MeshCore Windows app over TCP and my Android phone. Contacts do not sync unless they are marked as favorites. Not a big deal for me, but just wanted to point it out. <!-- github-comment-id:4019558319 -->
adam commented 2026-10-27 09:30:15 +01:00
Author
Owner
Copy link
Copy source

I just did a little testing. I was able to break the syncing when I connected to the host using Tailscale, while connecting over the local lan was successful and immediately synced contacts on iOS. I don't have an Android device to test with. If you are able to test and look at the logs for pyMC_repeater, do you see anything that looks like this?

2026-03-08 12:20:34,589 - CompanionFrameServer - INFO - Companion client connected (port=5050)
2026-03-08 12:20:34,596 - CompanionFrameServer - INFO - Companion cmd 0x16 (22) len=2
2026-03-08 12:20:34,596 - CompanionFrameServer - INFO - Companion device info sent: FIRMWARE_VER_CODE=10 (byte at index 1), version string='10.0', frame_len=82
2026-03-08 12:20:34,597 - CompanionFrameServer - INFO - Companion already has a client; evicting previous connection (port=5050)
2026-03-08 12:20:34,597 - CompanionFrameServer - INFO - Companion client connected (port=5050)
2026-03-08 12:20:34,597 - CompanionFrameServer - INFO - Companion client disconnected (port=5050): empty_read

I'm going to send over a PR to @rightup with some improved logging for connection issues, and a small fix for a race condition in the eviction code.

Any additional details would be helpful in pinning this down. 😄

I just did a little testing. I was able to break the syncing when I connected to the host using Tailscale, while connecting over the local lan was successful and immediately synced contacts on iOS. I don't have an Android device to test with. If you are able to test and look at the logs for pyMC_repeater, do you see anything that looks like this? ``` 2026-03-08 12:20:34,589 - CompanionFrameServer - INFO - Companion client connected (port=5050) 2026-03-08 12:20:34,596 - CompanionFrameServer - INFO - Companion cmd 0x16 (22) len=2 2026-03-08 12:20:34,596 - CompanionFrameServer - INFO - Companion device info sent: FIRMWARE_VER_CODE=10 (byte at index 1), version string='10.0', frame_len=82 2026-03-08 12:20:34,597 - CompanionFrameServer - INFO - Companion already has a client; evicting previous connection (port=5050) 2026-03-08 12:20:34,597 - CompanionFrameServer - INFO - Companion client connected (port=5050) 2026-03-08 12:20:34,597 - CompanionFrameServer - INFO - Companion client disconnected (port=5050): empty_read ``` I'm going to send over a PR to @rightup with some improved logging for connection issues, and a small fix for a race condition in the eviction code. Any additional details would be helpful in pinning this down. 😄 <!-- github-comment-id:4019845548 -->
adam commented 2026-10-27 09:30:16 +01:00
Author
Owner
Copy link
Copy source

yeah im seeing those too.

2026-03-08 19:19:33,481 - CompanionFrameServer - INFO - Companion already has a client; evicting previous connection (port=5000)
2026-03-08 19:19:33,484 - CompanionFrameServer - INFO - Companion client connected (port=5000)
2026-03-08 19:19:33,485 - CompanionFrameServer - INFO - Companion cmd 0x16 (22) len=2
2026-03-08 19:19:33,486 - CompanionFrameServer - INFO - Companion device info sent: FIRMWARE_VER_CODE=10 (byte at index 1), version string='10.0', frame_len=82
2026-03-08 19:19:33,515 - CompanionFrameServer - INFO - Companion cmd 0x01 (1) len=24

Im also on discord too, same username if thats easier.

yeah im seeing those too. ``` 2026-03-08 19:19:33,481 - CompanionFrameServer - INFO - Companion already has a client; evicting previous connection (port=5000) 2026-03-08 19:19:33,484 - CompanionFrameServer - INFO - Companion client connected (port=5000) 2026-03-08 19:19:33,485 - CompanionFrameServer - INFO - Companion cmd 0x16 (22) len=2 2026-03-08 19:19:33,486 - CompanionFrameServer - INFO - Companion device info sent: FIRMWARE_VER_CODE=10 (byte at index 1), version string='10.0', frame_len=82 2026-03-08 19:19:33,515 - CompanionFrameServer - INFO - Companion cmd 0x01 (1) len=24 ``` Im also on discord too, same username if thats easier. <!-- github-comment-id:4020238920 -->
adam commented 2026-10-27 09:30:16 +01:00
Author
Owner
Copy link
Copy source

Okay, that looks like the same issue I found earlier. I added cancellation and awaiting of the old writer task to ensure proper cleanup before creating a new task when handling one connection evicting the other. It solved that issue for me in testing. I'll send the PR for the fix over now.

Also on Discord as hercules.mulligan

Okay, that looks like the same issue I found earlier. I added cancellation and awaiting of the old writer task to ensure proper cleanup before creating a new task when handling one connection evicting the other. It solved that issue for me in testing. I'll send the PR for the fix over now. Also on Discord as hercules.mulligan <!-- github-comment-id:4020284543 -->
adam commented 2026-10-27 09:30:17 +01:00
Author
Owner
Copy link
Copy source

Merged.

Merged. <!-- github-comment-id:4023609364 -->
adam commented 2026-10-27 09:30:18 +01:00
Author
Owner
Copy link
Copy source

Made a new companion on pyMC_Repeater v1.0.8.dev3+g6bf252f58.

I added 4 channels and 3 repeaters. Then I reconnected to it from my work phone (fresh install) via Tailscale, and everything synced over without any issues.

Made a new companion on `pyMC_Repeater v1.0.8.dev3+g6bf252f58`. I added 4 channels and 3 repeaters. Then I reconnected to it from my work phone (fresh install) via Tailscale, and everything synced over without any issues. <!-- github-comment-id:4026536929 -->
Sign in to join this conversation.
No Branch/Tag Specified
Labels
No items
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
adam (Adam Wojcieszonek)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: adam/pyMC_Repeater#49