Description of Feature
A way to send link to server such that it raises an intent popup to play the video natively on the server (using youtube, newpipe, kodi or a browser and so on)
- Client device (e.g., Smartphone or a laptop) searches for a video using the server's HTTP endpoint
- Client then sends that link to the server (specifically, Smart TV running on Android). Probably using new endpoint such as
/send-link or /play and preferably integrated into client device UI itself
- The Android server plays the video/link (instead of client device) by raising an INTENT popup to let another app (natively installed on the server) to handle playback
This keeps search history on client's browser while playback happens on the server and would bypass the need to have a player built into the server app itself or have accessibility permissions granted
many stock android TV lack a lot of features (like accessibility permission; cannot install something like droidVNC-NG) on top of worst TV remotes imaginable to control an android app UI
Specifically the idea is to turn a smartphone with a standard browser into a remote for the android TV playing youtube videos or soundcloud music and remove the need to be in front of TV to play something altogether (especially music or podcast-esque youtube videos)
When multiple clients try to send links or play on server
if multiple client devices on same network are using the server and trying to send links that would cause problems/interruptions
I believe the simplest approach for handling this would require an additional endpoint in HTTP server that releases a lock to send-link/play endpoint which will only be granted to the first client device sending a link
- When a client device sends link to the server, a button (say, Stop or Disconnect) should be visible to that client device to release the play lock granted by server
- Upon receiving a send-link/play request, server would put up a lock in place and send a release code to client. Without codes just hitting an endpoint would release locks and start remote wars. Use cookie or localStorage or something along those lines on client device to maintain lock state and release code.
- When a lock is in effect (on server) any other client devices trying to send link to server would be told the server is busy. Effectively a first come, first served - server playing rights
- A button on the server app itself to forcefully release server-play lock would be great for when the client device that had lock granted to it had left the room without releasing. No checks for client being active, just clicking button on server will release lock.
IMHO, complexity that arises from breakdown of communication and/or cooperation between people in the same room shouldn't be handled by an app. I'd say simple lock and key is enough.
Description of Feature
A way to send link to server such that it raises an intent popup to play the video natively on the server (using youtube, newpipe, kodi or a browser and so on)
/send-linkor/playand preferably integrated into client device UI itselfThis keeps search history on client's browser while playback happens on the server and would bypass the need to have a player built into the server app itself or have accessibility permissions granted
many stock android TV lack a lot of features (like accessibility permission; cannot install something like droidVNC-NG) on top of worst TV remotes imaginable to control an android app UI
Specifically the idea is to turn a smartphone with a standard browser into a remote for the android TV playing youtube videos or soundcloud music and remove the need to be in front of TV to play something altogether (especially music or podcast-esque youtube videos)
When multiple clients try to send links or play on server
if multiple client devices on same network are using the server and trying to send links that would cause problems/interruptions
I believe the simplest approach for handling this would require an additional endpoint in HTTP server that releases a lock to send-link/play endpoint which will only be granted to the first client device sending a link
IMHO, complexity that arises from breakdown of communication and/or cooperation between people in the same room shouldn't be handled by an app. I'd say simple lock and key is enough.