Wegener Communications 6420 User Manual
iPump 6420 User’s Manual
www.wegener.com
800070-01 Rev B
Chapter 3, Page 74
Note that files may be placed on the iPump6420 by any of several methods. One is
WEGENER’s Assured File Delivery (AFD), performed in an MPE/IP channel from Compel,
over the satellite. Another is Kencast FAZZT, a 3
over the satellite. Another is Kencast FAZZT, a 3
rd
party satellite-based file distribution system.
Another is HTTP file download over internet. Other methods are also available to the local user:
FTP or SMB upload, and file recording. In the cases of FTP or SMB upload, be aware that the
file management database must still be given time to locate and “register” all newly placed files.
Those files must be located somewhere in the /u/user/ file structure, though the /u/user/assets
directory is strongly recommended for all files placed on, and not recorded by, the i6420.
FTP or SMB upload, and file recording. In the cases of FTP or SMB upload, be aware that the
file management database must still be given time to locate and “register” all newly placed files.
Those files must be located somewhere in the /u/user/ file structure, though the /u/user/assets
directory is strongly recommended for all files placed on, and not recorded by, the i6420.
Automatic File and Asset Deletion
If an asset is downloaded to the i6420 with an Expiration Date showing in its
If an asset is downloaded to the i6420 with an Expiration Date showing in its
metadata.xml file, then the file management database will schedule that entire asset for
automatic deletion one calendar day after the Expiration Date. Just after midnight, on the day
following that Date, all files and the asset folder itself are quietly deleted, if they still exist.*
automatic deletion one calendar day after the Expiration Date. Just after midnight, on the day
following that Date, all files and the asset folder itself are quietly deleted, if they still exist.*
* Advanced users may verify this using logs in the web diagnostics page.
Another method whereby files in the /u/user folder structure may be automatically deleted
is under those conditions where the HDD storage appears to be insufficient for new asset/file
downloads. In this case, the i6420 performs a TBS algorithm to find candidate files for deletion.
As new downloads are made, the candidate files are deleted to make room.
downloads. In this case, the i6420 performs a TBS algorithm to find candidate files for deletion.
As new downloads are made, the candidate files are deleted to make room.
User Controls:
The user controls are:
The user controls are:
1. Delete individual files, by name or by using wildcard (Compel only)
2. Move, copy, or rename folders and file (local user only)
3. Delete entire assets
4. Register all new files in database (debugging command only)
2. Move, copy, or rename folders and file (local user only)
3. Delete entire assets
4. Register all new files in database (debugging command only)
3.3.2.
Assured File Delivery over satellite
Assured File Delivery (AFD) over satellite is the premier method for file distribution in
WEGENER MediaPlan-based Store/Forward networks. In those networks, AFD distributes the
files to the edge receivers, the iPump6420s. It does this by breaking those files into fixed-size
frames, and then using a special “ghost” PID in the Transport stream as the “pipe” to convey
those frames to the waiting i6420s. The protocol used to send the frames of data to the i6420s is
MPE/UDP/IP (usually called just “MPE/IP”). The data is sent from Compel CSM, by UDP, to
the “satellite” IP address used in WEGENER S/F systems (173.16.200.222). Uplink equipment
called an IP Encapsulator then “forwards” those UDP packets, encapsulated per MPE protocol,
within a small Transport stream. This small stream is then multiplexed within the main Satellite
Transport by the main uplink MPEG Multiplexer. Thence, it goes out over the satellite to the
waiting iPump6420s. Meanwhile, if any of those i6420s has been set to use an MPE PID which
is correct, then that data stream is demultiplexed and fed to the IP stack at the satellite IP address,
which is assigned to the virtual “DVB adaptor” in all iPump6420s. Those UDP packets, of
course, are sent to a specific port number. As part of AFD, before the file is sent out as UDP
packets, Compel had instructed the target i6420s with a command to listen on that port. If it is
listening, and the packets are received, the i6420 reads the very first packet, a “control” packet,
to get the file name, its size, destination path, and its checksum. Then, if all the other packets are
received OK, the file is re-assembled and checksummed, said checksum then compared to that
files to the edge receivers, the iPump6420s. It does this by breaking those files into fixed-size
frames, and then using a special “ghost” PID in the Transport stream as the “pipe” to convey
those frames to the waiting i6420s. The protocol used to send the frames of data to the i6420s is
MPE/UDP/IP (usually called just “MPE/IP”). The data is sent from Compel CSM, by UDP, to
the “satellite” IP address used in WEGENER S/F systems (173.16.200.222). Uplink equipment
called an IP Encapsulator then “forwards” those UDP packets, encapsulated per MPE protocol,
within a small Transport stream. This small stream is then multiplexed within the main Satellite
Transport by the main uplink MPEG Multiplexer. Thence, it goes out over the satellite to the
waiting iPump6420s. Meanwhile, if any of those i6420s has been set to use an MPE PID which
is correct, then that data stream is demultiplexed and fed to the IP stack at the satellite IP address,
which is assigned to the virtual “DVB adaptor” in all iPump6420s. Those UDP packets, of
course, are sent to a specific port number. As part of AFD, before the file is sent out as UDP
packets, Compel had instructed the target i6420s with a command to listen on that port. If it is
listening, and the packets are received, the i6420 reads the very first packet, a “control” packet,
to get the file name, its size, destination path, and its checksum. Then, if all the other packets are
received OK, the file is re-assembled and checksummed, said checksum then compared to that