[kel-mo]

Description

Kodi aborts in ~IptvSimple() if the add-on is disabled while its connection manager is still checking the M3U URL.

The destructor sets m_running = false and skips the join, because the update thread hasn't started yet. Then it calls connectionManager->Stop(), which waits for the connection thread. That thread is still in WebUtils::Check(). When the check succeeds, ConnectionManager::Process() calls SetState(PVR_CONNECTION_STATE_CONNECTED), so ConnectionEstablished() loads the playlist, sets m_running = true and starts m_thread. The destructor then finishes, and the still-joinable std::thread member calls std::terminate().

This change stops the connection manager first, so nothing can start the update thread once the destructor joins it.

Backtrace of the aborting thread without the change:

#5  std::terminate()
#6  IptvSimple::~IptvSimple() [clone .cold] () from pvr.iptvsimple.so.22.6.5
#7  IptvSimple::~IptvSimple() ()
#8  kodi::addon::CAddonBase::ADDONBASE_DestroyInstance(...)
#9  ADDON::CAddonDll::DestroyInstance  AddonDll.cpp:289
#11 PVR::CPVRClient::Destroy  PVRClient.cpp:572
#12 PVR::CPVRClients::StopClient  PVRClients.cpp:321
#13 PVR::CPVRClients::UpdateClients  PVRClients.cpp:270

Testing

Kodi 22.0 RC1 (Piers) flatpak on Linux x86_64, pvr.iptvsimple 22.6.5 (6d334f6):

• I served the M3U from an HTTP server that waits 4 s before it answers and pointed an instance at it (remote path, cache off). Then I enabled the add-on and disabled it 1.5 s later with JSON-RPC Addons.SetAddonEnabled.
• Without the change, Kodi aborted on the first try. With it, two tries in a row shut down cleanly: the update thread starts, the connection manager stops, then the destructor joins the update thread.

(Diagnosed with Claude Code.)

[garbear]

PR #1049 — Review

No blocking findings.

The shutdown ordering fixes the reported race without introducing an apparent regression. CI checks passed.

Verdict: Approve.