feat: introduce an upnp-control-point crate#623
Conversation
- maintains a hashmap of upnp media renderers (ie. TVs) keeping a unique id, a friendly name, their location url and optional rendering control url and av transport control url. - will run a background task (an endless loop) to find renderers and purge stale items. - implements play, pause, stop, seek, set_volume and get_status for the renderers.
9a0f239 to
c7fe9cc
Compare
|
a later PR¹ will expose this over the http api, and then in the end allow the frontend to control TVs and play from the web-ui to a TV directly. ¹ or I can do multiple commits to this same PR? |
|
Can you describe how it's going to be used? Why would I control my TV from rqbit web page? |
sure. this is me actually getting back to an old idea reported here #425
in short, while rqbit already is an upnp-server, which can be used by most TVs as-is, The truth is most TV upnp browsers are subpar, slow and clunky. The rqbit web-ui has much more approachable interface, and you can filter, search, sort movies, and if a person already has it open, it'd be great to also be able to just click a button and for the media to start playing. At least that's my motivation. If it doesn't make sense for rqbit, that's fine too :) |
2 participants
maintains a hashmap of upnp media renderers (ie. TVs) keeping a unique id, a friendly name, their location url and optional rendering control url and av transport control url.
will run a background task (an endless loop) to find renderers and purge stale items.
implements play, pause, stop, seek, set_volume and get_status for the renderers.