[DEPRECATED] remote control over local network(http) using inbuilt api server, with customizable "portable" frontend-only interface

[QuditWolf]

Hey folks,

I added a very simple api server which roughly gives the same functionality as the mpris plugin(used that plugin as reference) but over the web/http protocol and hence can be controlled over the network. also included an example web interface to demonstrate song fetchting and control (it's no eye candy but it's quite functional, therefore "example").

to try the web interface, run youtube-music, enable the web-interface plugin, goto localhost:9669 on your browser.

capabilities/features:

• fetch information: songInfo + volume
• controls(written as "actions in my program): play, pause, playpause, next, previous, shuffle, looptoggle, volume+10 ,-10
• the server runs locally inside youtube-music as a plugin so no 3rd party public server needed. the endpoint is a port on your localhost. your data and control remains with you!
• extremely minimal, about ~150 sparse single lines of code. that too filled with empty lines and comments. ~100 for the sample html interface.

uses:

• able to control youtube music from browser, remote devices, mobiles, tablets, other laptops on the local network and the global(using ddns?, public ip {to be implemented})
• android controller apps can be built around the api or the web interface (webview)
• can show songinfo on webpages because it looks nice! music online presence!
• add as a web source on obs to show currently playing song.

server:

• starts a server on localhost:9669 listening on all interfaces (0.0.0.0),
• localhost:9669/api is the api
• localhost:9669/ is the web interface
• fetches data almost exactly like the mpris plugin (through listeners and providers/songInfo), controls stuff exactly like mpris(using songControls)
• does not mess with any of the (win) code except for calling songControls

API Usage:

• GET /api : returns all of the fields

• GET /api?action=someaction : does that action and also return all fields

• fields: title,artist,views,uploadDate,imageSrc,isPaused,songDuration,elapsedSeconds,url,album,videoId,playlistId

• actions(have to be sent one at a time):play,pause,next,previous,shuffle,looptoggle,volumeplus10,volumeminus10

interface:

I'm not really a fan of intensive eye candy, so just plain functional html for now. if someone wants a much sophisticated plugin, they can edit index.html, it's fairly simple vanilla html+js. (screentshots at the end)

yet to implement:

• controls: finer volume and seek and position controls. like dislike etc. kind of trivial...
• queue: no idea how this is possible, can query song names in queue but I do not know how to query song links.
• lyrics? : do we really need these in the controller?
• menu.js: customizable controls for: port, interface to run on, custom html for controller interface
• webinterface: eyecandy
• shift to POST methods for payload encryption and add levels of control so that the public can access the song information but only "you" can access the song controls.

Some iNteReSTinG side notes:

• I've tested this on linux, haven't tested on windows for the lack of a windows machine.
• I'm kind of a jsphobe (framework js bloat and whatnot philosophy) and my experience with framework js is practically nil. Have done some vanilla js though. so if there's evident bad bugs/code I'm sorry and open to suggestions/improvements.
• installed and spun up an archlinux vm just to containerize and isolate yarn+nodejs (pkgs + deps + config files :skull: ) from my daily driver system(guess what? also arch, duh).
• I wrote this on an overnight-allnighter :crescent_moon: so if someone can go through the code and just canvass obvious mistakes/bad practices, I'd be very thankful.
• The code may be bad as in not neat etc. but I have taken care not to write bloated/unoptimized code.
• if anyone's wondering the choice of port, it was the closest to music related ports in /etc/services but unoccupied.

Thx

Screenshots: web interface @ ip or address:9669 web interface through mobile on the lan: api @ ip or address:9669/api widget on personal website (custom)

[itzmanish]

wondering why you need an HTTP server to achieve this you can always have a small javascript MPRIS client and you can use that client anywhere to control the music.

This also points me to think about if youtube-music should also be available to access from a web browser because the electron is just a wrapper which renders music.youtube.com in it.

[QuditWolf]

the goal is, remote song control and song info fetch

• Can control media over the network(local*) via any browser on phones or any http capable devices.
• I can display a "Now Playing" widget on personal websites, desktops etc, (see the last image on the above post)

*it'll work over the internet too, if you have a pubic ip. I have ideas for global control for everyone that don't rely a fixed 3rd party server etc. but I think I should wait for response on this one first.

though it's designed for control over the network, you can obviously use it for local control too.

mpris is cool for control/querying media, if you're on the same device.( I use mpris for local control ). I don't know how suited mpris is for network control. Though I do find a project on net-mpris, but if we want network, I think http is better...

the http api / interface can also cater to apps which support http but don't support mpris natively... (obs, browsers, Operating Systems without dbus)

[briantho]

works just fine on windows 11. Was able to control volume, play pause, skip and replay. Cool!

Any chance you could make the default web interface look better? also, maybe add a search option, and a slider for volume control? That's just my 3 recommendations.

For now this will work for my purpose of remote controlling a pc hooked up to an amp, that is elsewhere in my home. Great work.

[Destroy666x]

So, there are 4 PRs for server interface now, all deprecated. This is looking to be the most robust/ready one.

Some questions:

1. What are the expected next steps with these? Just rebasing them?
2. Any opinions or insights from current maintaners on how the feature should look in the end, for initial version?

Asking primarily because I thought on working on something similar myself, as HTTP/CLI/similar interface is very needed and quite popular request as can be seen. Going somewhere with this would be amazing.

[ArjixWasTaken]

Hi @Destroy666x

I assume you are interested in taking over this PR?

As for your questions:

1. Rebasing is not enough. Since the code is so small, a complete rewrite would make more sense.

2. Ideally the API should be versioned (eg /v1/) in order for us to freely make changes w/o worrying much.

+ The port should be configurable and not a static number. + Looking at the OP's intended usage, this may be exposed over the internet. This would require some sort of authorization, unless you want strangers to control your music player. + Would be interesting if we make it so clients on the same network can discover the backend. It may be worthwhile to look-into replying at broadcast messages within the local network. (This way we can communicate the IP and port of the backend)

---

If you need any assistance with the extra objectives I posted, I can always help :^)

[QuditWolf]

discovery over the local network could be done via avahi

The public internet access could be via personal VPNs(wireguard? needs a single public ip server) or thru some P2P thing like TOR(serverless). Both are inherently authenticated/secure(overkill?). Currently anyone on your local network can access the api. Or obviously someone could spin up a common server for all, though I'm against a centralised single point of failure. I sometimes use this thru a wireguard VPN (when devices don't share a lan). Workx!

I'm also open to helping for improvements! :)

PS: what exactly do the deprecated and rebase tag mean in context of this repo structure?

[ArjixWasTaken]

Hello @QuditWolf !

I believe the rebase tag no longer applies, because the plugin structure has entirely changed (since the tag was added).

As for deprecated, it indicates that this PR does not target the new plugin system.

Since all plugins are implemented within the app, no backwards compatible plugin system exists (we didn't need one), all plugins were migrated to the new system.

This PR also has to migrate to the new system, and a complete rewrite would make more sense (since well, it is just 200 lines of code)

PS: The project has undergone two huge refactors.

[Destroy666x]

I assume you are interested in taking over this PR?

More in opening my own, but not if e.g. one of the 4 PRs will get finished in the meantime. Hence asking what's the deal/progress here.

Ideally the API should be versioned (eg /v1/) in order for us to freely make changes w/o worrying much. The port should be configurable and not a static number.

Yeah, these were some of my obervations here also.

Also some other notes:

• this needs some endpoint documentation ofc, whether automatically generated docs or manual README. As of now the user would have to discover it in the code/PR
• more proper REST endpoints would be nice for easier extensibility, e.g. GET /player/current or /playing to get current video data, something like PATCH /player/current/stop or /controls?stop etc. for actions and so on

This would require some sort of authorization, unless you want strangers to control your music player.

Not sure why anyone would do this, but why not, could be secured in some way. Would be very low priority for me personally, though.

So are you going to work on this further @QuditWolf ?

[QuditWolf]

I'm not currently planning to work on this. Can help with global access / network discovery.

So feel free to take over this PR.

[briantho]

discovery over the local network could be done via avahi

The public internet access could be via personal VPNs(wireguard? needs a single public ip server) or thru some P2P thing like TOR(serverless). Both are inherently authenticated/secure(overkill?). Currently anyone on your local network can access the api. Or obviously someone could spin up a common server for all, though I'm against a centralised single point of failure. I sometimes use this thru a wireguard VPN (when devices don't share a lan). Workx!

I'm also open to helping for improvements! :)

PS: what exactly do the deprecated and rebase tag mean in context of this repo structure?

Personally I think that going over the Internet or port forwarding/vpn or whatnot should be up to the end user. I personally am fine using this with over my lan, and it's not that hard to just put in a ip address or mdns address in my phones browser. Some functionality I would like to see and I think should be considered, is adding stuff like a volume slider and a "thumbs up/down" button. Maybe even a search function? As for security over the Internet, why not just add password authentication? That would be good enough IMHO.

[ArjixWasTaken]

Password authentication was also what I had in mind.

I just didn't delve into implementation details since I was merely posting my thoughts

[JellyBrick]

#1909