Each audio bell called gtk.MediaFile.newForFilename, which spins up a full GStreamer pipeline. The GTK4 GStreamer backend's GL sink starts gstglcontext/gldisplay-event threads that are never joined on teardown, so allocating a MediaFile per ring leaked a pipeline and ~4 threads on every bell. A long-running instance accumulated 705 threads over ~4h of normal use. Cache one MediaFile per surface (priv.bell_media), rebuilt only when bell-audio-path changes and unref'd on dispose. Each bell now replays the same pipeline via seek(0)+play() instead of creating a new one. The notify::ended -> unref handler is removed: it was what discarded (and leaked) a pipeline per ring. seek(0) is required so an ended stream plays again (#8957). Verified on a real instance: GStreamer's global element counter reached only oggdemux4 over an hour of use (one pipeline per bell-ringing surface, reused) and thread count stayed flat, versus per-bell growth before. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>