SBE: RemoveRecorded shouldn't be sent to the Master Backend

[billmeek]

The host name below should be that of the recording host,
not the Master Backend. Sending to the MBE will not remove
the file on the Slave. Related to #198.

http://<hostname>:6544/Dvr/RemoveRecorded?ChanId=2225&StartTime=2013-05-10T17%3A46%3A00

[dmfrey]

I think we should move this to v1.30.0.

The current state of the app does not expect that you will be connecting to separately to master and secondary backends. My understanding of the services api is that the master backend will broker calls to secondary backends when appropriate.

If this is not the case, then we need to re-think our preferences for setting up a location. One thing I now see needing is for a location is a map of secondary backends as well well as frontends. I think we will also need to rework how the auto-discovery works as well. We could probably use what is broadcast on the network to determine these, but this will only be applicable for home locations. For away locations where you are ssh tunneling into your network, I don't think we will be able to make secondary backend calls without opening multiple ssh tunnels.

[dmfrey]

I think the first thing we need to do is confirm that the backend IS NOT sending requests to secondary backends where appropriate.

[dmfrey]

I can confirm that the Dvr/GetRecordedList does not indicate the url of the backend it is running on, only the hostname

[billmeek]

Right, it's a design change. And given that Android doesn't allow users
to build an /etc/hosts file, the recording hostname is only partially valuable.
I know I can fix the detection part (where the host/slave status is detected.)
This truly did fail as written. I had to use a browser to delete the recording
with RemoveRecorded and use the SBE's address. But there are some users
who don't like/use avahi and prefer to enter IPs manually.