41
User_Manual_RP3001k.doc
Fetching scripts remotely as in the above example is the key to updating remote frames using “pull” mode. Any
remotely-referenced text file with an extension of “.txt” is treated as a nested script, i.e. it executes like a
subroutine. For example, if you have several DF-1710s that are at various locations and have unknown IP
addresses, you could control them remotely by initially loading to each one with the simple one-line “pull”
script file shown above, i.e.:
http://www.myserver.com/remote.txt
On your server www.myserver.com, you would put the actual media-playing script, “remote.txt”, which might
look something like this:
picture1.jpg
picture2.jpg,nocache
picture3.jpg
The remote script follows the path specification conventions described above for script files, i.e. it assumes that
files referenced in it reside in its directory unless other paths are explicitly defined. In the example just
presented, picture1.jpg, picture2.jpg, and picture3.jpg must reside in the same directory on the remote server
as the remote script file “remote.txt”.
By merely changing the single script file “remote.txt” and/or the media files referenced by it on your server you
will be updating the content on all the remotely-deployed frames that you originally initialized with the one-line
“pull” script.
An alternative method of referencing a remote script file is to use an “dfos.ini” text file to set the default
slideshow to a remote script (see “Advanced Networking Topics”). Using dfos.ini to set the default slideshow to
a script file on a remote server is a more robust way of implementing “pull” mode remote control of slideshows
in slow network situations. Another way to ensure that a slow network connection will never result in a
“Slideshow or Media Error” message due to a network timeout is to always include at least one local playable
item in your script.
Media items are cached by default unless the “nocache” option is specified. Caching minimizes network traffic
and speeds playback by eliminating unnecessary downloads. Since the DF-1710 stores, or “caches” copies of
fetched media and scripts, modifications made to remote media items on the server will not be seen on a
remote unit unless a) the unit is rebooted, b) the “nocache” option is specified in the script, which tells the DF-
1710 not to cache that particular item, or c) a “clearchache” directive is encountered in a script file. If you want
changes made to media files to be seen immediately on remote units you must use the nocache option or have
the frame execute a script containing a “clearchache” directive. If a script file calls a
different
media file (or the
same file with a different name), the changes will be seen immediately since the new file has not been
previously cached.
Even if “nocache” is specified, cached copies of media items will be displayed in the event the network
connection is lost, ensuring continuous playback.
Local controls such as pause, resume, previous, next, etc. continue to work with remote scripts and media
items.
