Closed thiccaxe closed 9 months ago
I dont know if this is related, I added it because of #153 (RemoteControlOnly) Probably not?
lib/handlers.h line 461
plist_t req_is_remote_control_only_node = plist_dict_get_item(req_root_node, "isRemoteControlOnly");
if (req_is_remote_control_only_node) {
uint8_t bool_val = 0;
plist_get_bool_val(req_is_remote_control_only_node, &bool_val);
if (bool_val) {
logger_log(conn->raop->logger, LOGGER_ERR, "Client specified AirPlay2 \"Remote Control\" protocol\n"
" Only AirPlay v1 protocol (using NTP and timing port) is supported");
}
}
This is the server controlling audio from the client. For example, you could pause music on Iphone from the uxplay server.
This sound complex.
Probably needs pairing to client with connection id.?
Maybe could be done with a companion app that talks to the client using data from a file written by UxPlay?
Right now UxPlay accepts no user input after it starts.
I'll close this for now,
But I'll respond to any more comments in this thread.
I tested this bit of code from https://openairplay.github.io/airplay-spec/audio/remote_control.html#remote-control
it seems that all of the options except the ones relating to muting and rewind/fastforward
it is fairly simple to do. However, I don't know if this is really in scope for UxPlay? Not easy to control from a console.
Either you could have some sort of HTTP service where you can send requests to the server which will forward them on to the client. Alternatively, we could expose the DACP-ID and Active-Remote data by writing to a file. An external program could then check those files.