System Media Tansport Controls Integration for Windows

[rlpratyoosh]

Summary

• Added smtc-tokio library for SMTC integration in the app
• Pressing media keys to control playback is now supported in windows.
• Resolves Media Key/RPC Server Support #229

Testing

• cargo fmt --all
• cargo clippy --locked -- -D warnings
• cargo test --locked (244 passed)

Additional notes

spotatui_smtc.mp4

• smtc-tokio library is created by me, and can be checked on https://github.com/rlpratyoosh/smtc-tokio

[LargeModGames]

Thanks for this. Really clean integration, and it mirrors the existing macOS (macos-media) wiring closely, which makes it easy to follow. A few things before merge:

Should fix:

• windows-media = ["smtc-tokio"] doesn't pull in streaming, but the SMTC manager setup in runtime.rs references streaming_player, which only exists under the streaming feature. Building --features windows-media without streaming won't compile. Please make it windows-media = ["smtc-tokio", "streaming"] to match macos-media. Default builds are fine since they include both; this is just so the feature is self-contained.

Worth a look (non-blocking):

• Both the player-event handler (events.rs) and the new 1s polling loop in runtime.rs push set_position / set_playback_status to SMTC during native playback, so they overlap. The macOS loop only refreshes metadata and lets events own position/play-state. Consider doing the same here to cut redundant COM calls.
• In handle_windows_media_events, app.lock() is held across the player.play()/pause()/seek() calls. Should be fine if those are non-blocking, but worth confirming they can't block on the spirc channel under contention.
• Adding windows-media to default means every Windows user pulls smtc-tokio (new, v0.1.0, single-maintainer). Totally fine, just flagging since it's now on the default path.

One note for visibility: CI runs --no-default-features --features telemetry, so none of this Windows path is compiled there. The feature-combo issue above wouldn't be caught by CI.

[rlpratyoosh]

Thanks for the review!

1. I've successfully fixed the windows-media feature dependency in Cargo.toml
2. I kept the position and state sync in the runtime.rs loop, but gated it behind an if app.native_track_info.is_none() check. If we strip it out entirely, the timeline and play state will freeze when controlling external devices, since PlayerEvents stop firing.
3. You were right about the app.lock() in handle_windows_media_events, The player.play()/pause()/seek() calls are non-blocking; however, it's still better to not rely on them. So I scoped the app_lock tightly.

[LargeModGames]

This looks good now thanks, could you also update changelog.md?