Wifi trainer and companion app disconnect after segment PR, then trainer fails to reconnect automatically (log snips attached)

Bugs and Support
1

A weird thing happened in a TT tonight. Just as I passed through a sprint segment and set a PR, my companion app flipped from “Game” to “Home” and my trainer (JB Victory) dropped all data transmission. The companion app quickly recovered and went back to “Game” in almost a second, but the trainer did not recover transmission.

I went to the pairing screen, and everything was blue “Connected”, but no data even when pedaling. So, I unpaired and re-paired everything which did the trick, and I sheepishly finished the ride without any major issues. I didn’t even notice the timing of the disconnect with the segment finish until after I swept the log file to see if maybe my router had reset and changed IP addresses or something else. That’s when I discovered the disconnect timing. Not sure if it’s just bad luck or indeed a bug from the segment. Either way, I’m curious as to why the trainer doesn’t reconnect on its own. Maybe a quick fix? Maybe my router is to blame?

Here’s the disconnect bit from the log. I backed it up if anyone needs more, and I also have a video of the ride. Zwift also auto captured video that just catches the dropout in the last few frames. Last I have dual power recordings from my assiomas, showing me continuing to push for 12s after the point of the dropout before I noticed something was off.

[18:50:51] TIMING ARCH: Player (male) passed finish line of segment -9223372035799170891 at time 355804577.36 in 19.61 seconds (avg watts 362.67).

[18:50:51] Got Notable Moment: NEW PR!

[18:50:51] [VIDEO_CAPTURE] Initiating delayed save after notable moment, delay = 4.000000

[18:50:51] Got Notable Moment: SET A TIME

[18:50:51] Requesting Notable Moment Screenshot, type=NEW PR!, delay=5.00, distance=12327.77

[18:50:51] LEADERBOARDS: Saving segment results for segment -9223372035799170891 with a time of 355804577.36

[18:50:51] [ActionBarV2] ZCActionBar: UserAction has changed: gameplay:toss_powerup (presentable=true)

[18:50:51] [ActionBarV2] ZCActionBar: UserAction has changed: media:movie (enabled=false)

[18:50:51] LEADERBOARDS: SUCCESS Segment result uploaded (result-id: 1974314693107384336) (segment hash: -9223372035799170891) (event subgroup id: 6641781) (duration: 19611ms)

[18:50:52] [ERROR] Auxiliary Controller received ‘An existing connection was forcibly closed by the remote host.’ (10054) during message length receive handler

[18:50:52] [INFO] Auxiliary Controller shutting down keep alive loop

[18:50:52] [INFO] Auxiliary Controller attempting to connect to phone at: 192.168.68.71:21588 (secure)

[18:50:52] [INFO] Auxiliary Controller connected successfully

[18:50:52] [WARN] Discarding command from phone: 29

[18:50:52] [INFO] Sending Pairing Status of: true

[18:50:53] [GAME]: Saving auto triggered screenshot to server

[18:50:53] [GAME]: GAME_TakeScreenshot(): 3840x2160, Content 0

[18:50:53] [GAME]: GAME_TakeScreenshot(): 3840x2035, Content 1

[18:50:53] [GAME]: Enqueuing screenshots for upload

[18:50:53] LIVESEG: Sending Active Segments.

[18:50:54] Play Haptic USE_POWERUP

[18:50:54] Play Haptic USE_POWERUP

[18:50:54] Got Notable Moment: POWERUP

[18:50:54] [ActionBarV2] ZCActionBar: UserAction has changed: gameplay:toss_powerup (presentable=false)

[18:50:55] [VIDEO_CAPTURE] Saving after delay

[18:50:57] FPS 59.76, 55434, 12431, 1181717

[18:50:57] [ERROR] LAN Exercise Device: Error receiving from Victory B228._wahoo-fitness-tnp._tcp.local. [10054] An existing connection was forcibly closed by the remote host.

[18:50:57] [INFO] LAN Exercise Device: Connecting to device Victory B228._wahoo-fitness-tnp._tcp.local. 192.168.68.51:36866

[18:50:57] Process connect for “Victory B228._wahoo-fitness-tnp._tcp.local.”

[18:50:57] ConnectWFTNPDevice for “Victory B228._wahoo-fitness-tnp._tcp.local.”

After fumbling around for a few seconds, here’s the log after opening the pairing screen:

[18:51:27] PairingScreen CTOR (PBE) start

[18:51:27] BLE initialization

[18:51:27] Pairing screen interface initialization

[18:51:27] …PreferNativeBLE

[18:51:27] Sport: Cycling

[18:51:27] PairingScreen CTOR end

[18:51:27] [INFO] LAN Exercise Device: Start scanning

[18:51:27] [BLE] Starting Native BLE search

[18:51:27] Process connect for “Victory B228._wahoo-fitness-tnp._tcp.local.”

[18:51:27] ConnectWFTNPDevice for “Victory B228._wahoo-fitness-tnp._tcp.local.”

[18:51:28] [BLE] FTMS Service Data for Unknown device: 01, 20, 00

[18:51:28] “Victory” adding component type: 6 (BLE)

[18:51:28] “Victory 43” adding component type: 2 (BLE)

[18:51:28] “Victory 43” adding component type: 0 (BLE)

[18:51:28] “Victory 43” adding component type: 1 (BLE)

[18:51:28] “Victory 43” adding component type: 7 (BLE)

[18:51:28] Device List:

[18:51:28] ===========================================================================

[18:51:28] Left Input: Zwift Play-L 0D9B (0x1F16E148) [BLE]

[18:51:28] Power: Victory B228 (0x1588536C) [BLE (LAN)]

[18:51:28] Cadence: Victory B228 (0x1588536C) [BLE (LAN)]

[18:51:28] Controllable Trainer: Victory B228 (0x1588536C) [BLE (LAN)]

[18:51:28] HR: Victory B228 (0x1588536C) [BLE (LAN)]

[18:51:28] Right Input: Zwift Play-R B0A5 (0x1D3E934A) [BLE]

[18:51:28] Non-Selected: Victory 43 (0x1F7F172B) [BLE]

[18:51:28] ===========================================================================

Any help would be appreciated. No fun having this happen during a race :frowning: but hasn’t happened before.

2

I would run that log through trainerdx.com to see other aspects of game performance when the problem happened, and turn off the Video Screenshots setting in Zwift.

If you hit the Share button on the log report and post the link here, you might get more advice about it. (You may need to mangle the link a little to get it to post on the forum)

If this is a rare phenomenon that you can’t easily reproduce it may be hard to know if anything makes it better.

1 Like
3

Thanks Paul,

I ran the log through trainerdx.com and no issues with graphics, network, crowds, etc. Nothing out of the ordinary except for the companion reconnect. Race started at 6:32 PM central and dropout at 6:51.

Let’s see if this link works: https://trainerdx.com/public/2b141523-410d-4f5b-96c4-aa68d685e727

4

Pretty strong PC so there should be no reason for any performance related issues. My two guesses are either something happened with Video Screenshots (so disabling that could help) or there was a coincidental network drop unrelated to the PC that the game or trainer didn’t recover from very well. Pairing the trainer via Bluetooth instead of WiFi could possibly help in that case. There have been quite a few WiFi problems reported by Victory owners, but I can’t guess if that’s what happened.

The fact that you had a Companion disconnection as well means that the network problem wasn’t just affecting the trainer. It had to be the game or the PC or the network itself that triggered it.

1 Like
5

Yeah my thinking as well. I was worried that my router reset, but I’m not finding any evidence of that (my internet connection to Zwift would have dropped too). Overall, a very weird thing.

I’ve only had my trainer drop connection 3-4x since this firmware was released over the summer, and I ride about every day. However, when it does drop, it doesn’t automatically reconnect which I guess is the more concerning issue. If that were the case, the 2-3 seconds of sticky watts would have caused this to be a non-factor.

6

Replying with possible solution. Seems that a few “smart” devices on my network have been having some issues within the past 24 hrs. I’ve rebooted my router and all mesh nodes, and no more issues. I’m going to chalk this up to a router/IoT issue. The JetBlack, like many IoT devices, uses an ESP chip. So, probably a good chance for connection conflicting. I’ve since given an address reservation for my trainer and other smart devices throughout the house. I’ve also set the trainer to only use 2.4 Ghz and placed it on my IoT subnet.