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
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=RTV4080K1AA5000149It 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 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=RTV4080K1AA5000149It 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
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=RTV4080K1AA5000001It 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
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=RTV5040XXXXXXXXXXXIt 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
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=0000000307D30005000D00160000000000007BAC0000001E000000020000000300000126000000000000000000000000000000007F00000000000000000000010000000000000000It 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
commands a remote DVR to schedule a recording.
A request looks like:
http://192.168.117.3/http_replay_guide-record_show?record_request=0000000307D30005000D001600000000000000000000001E000000020000000300000126000000000000000000000000000000007F00000000000000000000010000000000000000It 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
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=0000000307D30005000D001600000000000000000000001E000000020000000300000126000000000000000000000000000000007F00000000000000000000010000000000000000It 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
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=0000000307D30005000E0004001E00000000692C0000001E000000020000000300000000FFFFFFFFFFFFFFFF00000000000000007F00000000000000000000010000000000000000000000004734284361626C652900000000000000000000000000000000000000000000000000000It 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
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=000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000008000000000000001E5468652053696E67696E6720426565008008C88481F09A980000002881F09B400000000081F09B408109AC580000002849041A8B00000000000000020000000200000000000000007F00000400000000000000005468652053696E67696E67204265650000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000It 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.
192.168.117.3
is an arbitrary address used for examples only.
-- LeeThompson - 23 May 2003 (Update by HenryDonzis 15 Nov 2009)
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. |