Free the mouse Replay HttpReplayGuide
Home | Changes | Index | Search | Go
The HttpReplayGuide protocol is an over-HTTP interface to the ReplayGuide?.

HttpReplayGuide URLs are in the form http://address/http_replay_guide-command?arguments.

There are three commands in the HttpReplayGuide protocol common to 4.1, 4.3, 4.5 and 5.0: get_snapshot, is_show_in_use and delete_show.

In addition HttpReplayGuide protocol is extended to nine commands with 5.0 which adds: get_play_position, record_show, change_record_options, get_manual_record_slots, update_replay_channel, and get_record_slots.

get_snapshot

get_snapshot is used to retrieve a GuideSnapshot.

A sample request looks like:

    http://192.168.117.3/http_replay_guide-get_snapshot?guide_file_name=1018602286&serial_no=RTV4080K1AA5000149

It takes two arguments: guide_file_name and serial_no. guide_file_name is actually a TimeT timestamp of the latest version of the GuideSnapshot already retrieved; use 0 if there isn't one already on-hand. serial_no is the serial number of the Replay making the request.

The response, content-type text-plain, consists of a protocol single status line, followed by a body. The status line is a hexadecimal number, followed by a newline; if no errors are encountered, the value will be 0.

The body consists of either the single line guide_file_name=upToDate, or an ASCII header, a GuideSnapshot, an an ASCII footer.

The ASCII header is a series of tag=value lines, terminated by newlines, and the string #####ATTACHED_FILE_START#####. The current tags are guide_file_name, RemoteFileName and FileLength; presumably the guide_file_name value is the value to use in future guide_file_name arguments; the RemoteFileName value seems to always be the same. The FileLength value is the actual length of the GuideSnapshot.

The GuideSnapshot is sent straight, no encoding -- the text/plain claimed content-type is incorrect.

The ASCII footer is simply the string #####ATTACHED_FILE_END#####.

is_show_in_use

is_show_in_use is used to determine if a show is in use, prior to deleting it; it's used both for local shows and remote shows.

A sample request looks like:

   http://192.168.117.3/http_replay_guide-is_show_in_use?channel_id=0x3cae9a91&show_id=0x3cae9d29&serial_no=RTV4080K1AA5000149

It takes three arguments: show_id, channel_id and serial_no. show_id and channel_id are hex-encoded ReplayShow and ReplayChannel IDs, preceeded by 0x; these arguments must be hex-encoded, as shown. serial_no is the serial number of the Replay where the show is stored; it may not be either the serial number of the Replay making the request, or the Replay being asked. Together, the three arguments uniquely identify a show.

The response has content-type text-plain.

The first newline-terminated line is a hexadecimal status code, 0 for success. If successful, the second and final line is a string either show_in_use=0x0 or show_in_use=0x1. 0x0 means not in use, and 0x1 means in use.

delete_show

delete_show is used to delete a show.

A request looks like:

   http://192.168.117.3/http_replay_guide-delete_show?channel_id=0x3ca92713&show_id=0x3ca93ace&serial_no=RTV4080K1AA5000001

It takes three arguments: show_id, channel_id and serial_no. show_id and channel_id are hex-encoded ReplayShow and ReplayChannel IDs, preceeded by 0x; these arguments must be hex-encoded, as shown. serial_no is the serial number of the Replay making the request (this differs from is_show_in_use); the request should only be made to the Replay actually holding the show, so the serial number isn't required to uniquely identify a show.

The response has content-type text-plain.

The first newline-terminated line is a hexadecimal status code, 0 for success. If successful, the second line is an empty string; the success code is the only indication of success. A show being in use counts as an error (error code 94780008).

Deletes are done asynchronously. That is, you'll immediatly get a response code back indicating whether the show is deletable (exists, not in use, etc). But upon return of that code, it may be from 1 to 10 seconds before the show is actually deleted (depending on what the ReplayTV is doing). If you fetch a guide immediatly after a successful delete show request, you'll likely find the show still listed. A few seconds later, it'll be gone. Presumably, this is because of the guide housekeeping the ReplayTV must do. This appears to have started with the 4.3 firmware.

get_play_position

get_play_position is used to get the GOP position of a given recording from another networked units to allow the user to resume playback from any networked unit.

A request looks like:

    http://192.168.117.3/http_replay_guide-get_play_position?show_id=0x3ecc837e&channel_id=0x3e8cbbb2&serial_no=RTV5040XXXXXXXXXXX

It takes three arguments: show_id, channel_id and serial_no. show_id and channel_id are hex-encoded ReplayShow and ReplayChannel IDs, preceeded by 0x; these arguments must be hex-encoded, as shown. serial_no is the serial number of the Replay making the request (this differs from is_show_in_use).

For more detailed information, please see GetPlayPosition.

Introduced in 5.0.

get_record_slots

get_record_slots is used to query a remote DVR to determine if a time slot is available for scheduling.

A request looks like:

    http://192.168.117.3/http_replay_guide-get_record_slots?time_based=0x1&program=00000110000000010000000100000126000010003EC16AE000004703001E225C6300006C0A012C010115010154656368204C69766500004175746F6D6174696320737072696E6B6C6572732061646A75737420746F2074686520776561746865722E00000032372C36342C313430342C353030322C3530313700000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000&record_request=0000000307D30005000D00160000000000007BAC0000001E000000020000000300000126000000000000000000000000000000007F00000000000000000000010000000000000000

It takes three arguments: time_based, program and record_request. time_based seems to always be 0x1; program is a hex-encoded Program structure; record_request is a hex-encoded record_request structure which is documented on the RemoteScheduling page.

Introduced in 5.0.

record_show

record_show commands a remote DVR to schedule a recording.

A request looks like:

    http://192.168.117.3/http_replay_guide-record_show?record_request=0000000307D30005000D001600000000000000000000001E000000020000000300000126000000000000000000000000000000007F00000000000000000000010000000000000000

It takes one argument: record_request is a hex-encoded record_request structure which is documented on the RemoteScheduling page.

Introduced in 5.0.

change_record_options

change_record_options sends an asynchronous command to a remote DVR to change recording options for a given ReplayChannel.

A request looks like:

    http://192.168.117.3/http_replay_guide-change_record_options?channel_id=0x3ece80d2&record_request=0000000307D30005000D001600000000000000000000001E000000020000000300000126000000000000000000000000000000007F00000000000000000000010000000000000000

It takes two arguments: channel_id and record_request. channel_id is a hex-encoded ReplayChannel ID, preceeded by 0x; this argument must be hex-encoded, as shown. record_request is a hex-encoded record_request structure which is documented on the RemoteScheduling page.

Introduced in 5.0.

get_manual_record_slots

get_manual_record_slots makes a request to a remote DVR to check the availability for a manual record slot.

A request looks like:

http://192.168.117.3/http_replay_guide-get_manual_record_slots?slot_data=0000000307D30005000E0004001E00000000692C0000001E000000020000000300000000FFFFFFFFFFFFFFFF00000000000000007F00000000000000000000010000000000000000000000004734284361626C652900000000000000000000000000000000000000000000000000000

It takes one arguments: slot_data. slot_data is a hex-encoded slot_data structure which is documented on the RemoteScheduling page.

Introduced in 5.0.

update_replay_channel

update_replay_channel sends an asynchronous command to a remote DVR to change theme recording options for a given ReplayChannel.

A request looks like:

/http_replay_guide-update_replay_channel?channel_id=0x49041a8b&replay_channel=000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000008000000000000001E5468652053696E67696E6720426565008008C88481F09A980000002881F09B400000000081F09B408109AC580000002849041A8B00000000000000020000000200000000000000007F00000400000000000000005468652053696E67696E67204265650000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

It takes two arguments: channel_id and replay_channel. channel_id is a hex-encoded ReplayChannel ID, preceeded by 0x; this argument must be hex-encoded, as shown. replay_channel is a hex-encoded ReplayChannel structure and is further documented on the RemoteScheduling page.

Introduced in 5.0.


NOTE: 192.168.117.3 is an arbitrary address used for examples only.

-- LeeThompson - 23 May 2003 (Update by HenryDonzis 15 Nov 2009)



Your post will appear before this form in chronological order (newest at bottom)

Topic HttpReplayGuide . { Edit | Attach | Ref-By | Printable | Diffs | r1.4 | > | r1.3 | > | r1.2 | More }
Revision r1.4 - 23 May 2003 - 21:03 GMT - LeeThompson
Parents: LanVideoSharing
Copyright © 2001 by the contributing authors. All material on this collaboration tool is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback.