[harshdeepsinghin]

VLCClientFactory defines clientConnectionLost twice:

• the first definition (added in 9b90dd5, "Attempt to fix VLC connection issues") logs the loss and delegates to ReconnectingClientFactory.clientConnectionLost;
• the second definition (added earlier, in 9a10730) is the VLC-specific implementation that reconnects while within VLC_OPEN_MAX_WAIT_TIME and otherwise drops the player.

Because Python keeps the last definition, the second one wins, so the first was unreachable dead code — meaning the 2021 change never actually took effect for lost connections.

This removes the unreachable definition so the class has a single, unambiguous clientConnectionLost. Runtime behaviour is unchanged, since the removed method could never be called. The delegating clientConnectionFailed added in the same commit is unaffected and still in use.

If the intent in 9b90dd5 was in fact to replace the older implementation with the delegating one, then the fix should go the other way (remove the second definition instead) — happy to adjust.

[Et0h]

Hi, thanks for your contribution.

While I'm responsible for the VLC implementation, I don't actually use VLC on a day-to-day basis.

Your suggested change looks correct to me, as it should not alter the existing behaviour. Have you tested it with VLC, particularly that it connects normally and that closing VLC still causes Syncplay to shut down as expected?

[harshdeepsinghin]

Full transparency: I originally filed this PR because I experienced VLC closing repeatedly, but I can no longer reproduce that issue on either master or the fix branch - both work identically now.

Tested both:

• Normal VLC connection: ✅ Works
• Close VLC window: Syncplay stays open (macOS background process)
• Fully quit VLC (Cmd+Q): ✅ Syncplay closes
• Reconnection logic: Works

Since the removed method was dead code (overridden by the second definition), this PR safely cleans up the duplicate without changing runtime behavior. The code is clearer now. Ready to merge if you agree.