ADDERLink INFINITY Manager Manual

							50
INSTALLATION
CONFIGURATION
OPERATION
FURTHERINFORMATION
INDEX
APPENDIX C - Redundant servers: Setting up and swapping out
This appendix contains two main sections related to the creation and repair of A.I.M. 
server installations that employ redundancy. 
• Setting up A.I.M. server redundancy - below 
• Swapping out an A.I.M. server - on next page
When upgrading from a 3.1 redundant system after upgrading the primary A.I.M. server 
and then the associated devices to 3.3, it is important to remember to upgrade the 
backup A.I.M. server to 3.3. Failover with mixed firmware versions is not supported. 
Please read the important advice on page 3 before attempting installation, upgrades or restoring 
backups. 
Setting  up A.I.M. server redundancy
This section details the steps required to successfully configure two A.I.M. units as 
primary and secondary servers.
1 First determine the password requirements for A.I.M. servers. Access the Dashboard > 
Settings page and click Servers button. Set the Require Authentication option as required. 
If set to No, then new servers can join the network as soon as they are plugged in. If 
set to Yes, you will need to enter a Cluster Password in the field below and this must be 
set on every A.I.M. server.  
2 Within the main Servers tab, choose the A.I.M. unit that you wish to use as the 
primary server.
3 Click  for the chosen A.I.M. server to display the Configure Server page and change 
the Rôle entry to primary and click Save. 
4 Add the new secondary A.I.M. server to the network. This unit must have its factory 
default settings in place. The new server should appear within the main Servers tab and 
be identified as being Unconfigured.
5 Wait five minutes for automatic server replication to take place. After five minutes 
the secondary server will be added to the list on the main servers tab. It is possible 
that the backup status may show a failure state before the correct status of standby is 
shown. This is because the replication of the database from the primary to the backup 
may take longer than expected.  
 Note: If the transfer of the backup database is interrupted and only a partial database is 
transferred, then the problem will be reported within the management server page. If this 
occurs, it will not be possible to log in to the backup database and the firmware version of 
the backup will be reported as V. After five minutes, you should be given the options of Reboot 
and Factory Reset. Choose the factory reset option in order to clear this issue.
6 You can now configure the secondary server in either of two ways:
• Click the  icon to configure the server remotely from the primary server.  
• Click the  icon to open a restricted page in order to configure the server 
directly from its own IP address. If you use this option, the configuration options are 
limited to: view the logs; update/reset A.I.M. and configure this server.
Operation of Redundancy
If the Primary server fails for any reason (for example, loss of power or a network 
issue) then the secondary server will failover. This will happen automatically without 
any user intervention, however it is not instantaneous. The failover time required is the 
value entered in  the primary timeout plus 30 seconds for the process to happen. The 
AdderLink Infinity extenders will start communication with the second IP address that is 
stored in their configuration and the redundant server will take control of the AdderLink 
Infinities. When the redundant server is acting as the primary it is not possible to add any 
new devices or change the configuration. If this is required then the backup server can be 
promoted to be the primary.
When the primary server comes back online then it will resume its role as the primary. 
If however the backup server has been promoted to primary, when the primary server 
comes back its role will need to be factory reset back to the backup. It is not possible to 
have two primary servers on the same network.
Both the primary and the backup server periodically synchronize their databases to 
ensure that they are identical. If for any reason the backup server is powered down then 
any changes to the system configuration will not be maintained by the backup server.   
						

							51
INSTALLATION
CONFIGURATION
OPERATION
FURTHERINFORMATION
INDEX
Swapping out an A.I.M. server
Once ALIF devices have been configured to run with an A.I.M. server, their default IP 
addresses are automatically changed as part of the installation process. In this state the 
ALIF devices become undetectable to any new A.I.M. server that does not have access to 
the database of devices. Therefore, if an existing A.I.M. server needs to be replaced within 
an installation, follow one of the basic procedures given here to smooth the transition.
The correct procedure to use depends on whether you are using a solo A.I.M. server 
(firmware versions below 3.0 can only be used as solo servers) or a pair of A.I.M. servers 
in a primary/backup redundancy arrangement: 
For solo A.I.M. servers (and those with firmware below v3.0)
1 Before connecting the new A.I.M. server to the main network, connect the new A.I.M. 
server to a network switch that is isolated from the main network.
2 Use a computer connected to the same switch to login to the new A.I.M. server 
management suite. 
3 Ensure that the new A.I.M. server is running the same firmware version as the one 
being replaced (upgrade if necessary). The firmware version is shown in the top right 
hand corner of every page of the management suite (just below the Adder logo). 
4 Set the IP address of the new A.I.M. server to match that of the original unit.
5 Restore a backup file of the original A.I.M. server database to the new device.
6 Remove the original A.I.M. server from the network. Connect the new A.I.M. server in 
its place and power up.
7 With firmware 3.3, if the solo server is replaced, you need to perform a factory 
reset on all AdderLink Infinity units. This is because the ALIF units need to inherit the 
security certificate of the new A.I.M. unit. Please read the important advice on page 3 
before attempting installation, upgrades or restoring backups. 
 The replacement unit will now work directly with the installed ALIF units.   
For dual A.I.M. installations using redundancy
The correct procedure depends on which A.I.M. server has failed:
Primary server failure
1 Promote the backup server to be the primary server.
2 Replace the faulty primary A.I.M. server with a replacement unit. 
 If the replacement A.I.M. server has a firmware version below 3.0 then contact it on 
the 169.254.1.3 address and upgrade to 3.0. After the upgrade, reboot the unit. 
3 The replacement server should begin communicating with primary server and 
download the database so that it can operate as the backup server.
Backup server failure
1 Replace the failed backup server with a new unit that has firmware version 3.0 or 
greater and has its default factory settings in place. 
2 The replacement server should begin communicating with primary server and 
download the database so that it can operate as the backup server.
Starting from scratch
If none of the above procedures are used, then the following will be necessary. This will 
require a certain amount of effort because each ALIF unit must be visited and reset, plus 
the A.I.M. database will need to be fully reconfigured. 
1 Place a new A.I.M. server into the network and then perform a factory reset on every 
ALIF device. This will force the ALIF units back to their default states whereupon they 
will announce themselves to the new A.I.M. server.
2 Use a computer connected to the same network to login to the new A.I.M. server 
management suite and begin to recreate the database of devices and users.   
						

							52
INSTALLATION
CONFIGURATION
OPERATION
FURTHERINFORMATION
INDEX
APPENDIX D - Glossary
Internet Group Management Protocol
Where an ALIF transmitter is required to stream video to 
two or more receivers, multicasting is the method used. 
Multicasting involves the delivery of identical data to 
multiple receivers simultaneously without the need to 
maintain individual links. When multicast data packets enter 
a subnet, the natural reaction of the switches that bind 
all the hosts together within the subnet, is to spread the 
multicast data to all of their ports. This is referred to as 
Multicast flooding and means that the hosts (or at least 
their network interfaces) are required to process plenty of 
data that they didn’t request. IGMP offers a partial solution.
The Internet Group Management Protocol (IGMP) is 
designed to prevent multicast flooding by allowing Layer 
3 switches to check whether host computers within 
their care are interested in receiving particular multicast 
transmissions. They can then direct multicast data only to 
those points that require it and can shut off a multicast 
stream if the subnet has no recipients.
There are currently three IGMP versions: 1, 2 and 3, with 
each version building upon the capabilities of the previous 
one: 
• IGMPv1 allows host computers to opt into a multicast 
transmission using a Join Group message, it is then 
incumbent on the router to discover when they no 
longer wish to receive; this is achieved by polling them 
(see IGMP Querier below) until they no longer respond.
• IGMPv2 includes the means for hosts to opt out as well 
as in, using a Leave Group message. 
• IGMPv3 encompasses the abilities of versions 1 and 2 
but also adds the ability for hosts to specify particular 
sources of multicast data. 
AdderLink Infinity units make use of IGMPv2 when 
performing multicasts to ensure that no unnecessary 
congestion is caused.
IGMP Snooping
The IGMP messages are effective but only operate at 
layer 2 - intended for routers to determine whether 
multicast data should enter a subnet. A relatively recent 
development has taken place within the switches that 
glue together all of the hosts within each subnet: IGMP 
Snooping. IGMP snooping means these layer 2 devices now 
have the ability to take a peek at the IGMP messages. As a 
result, the switches can then determine exactly which of 
their own hosts have requested to receive a multicast – 
and only pass on multicast data to those hosts. 
IGMP Querier
When IGMP is used, each subnet requires one Layer 3 
switch to act as a Querier. In this lead role, the switch 
periodically sends out IGMP Query messages and in 
response all hosts report which multicast streams they 
wish to receive. The Querier device and all snooping Layer 
2 switches, then update their lists accordingly (the lists are 
also updated when Join Group and Leave Group (IGMPv2) 
messages are received).  
IGMP Fast-Leave (aka Immediate Leave)
When a device/host no longer wishes to receive a 
multicast transmission, it can issue an IGMP Leave Group 
message as mentioned above. This causes the switch to 
issue an IGMP Group-Specific Query message on the port 
(that the Leave Group was received on) to check no other 
receivers exist on that connection that wish to remain a 
part of the multicast. This process has a cost in terms of 
switch processor activity and time. 
Where ALIF units are connected directly to the switch 
(with no other devices on the same port) then enabling 
IGMP Fast-Leave mode means that switches can 
immediately remove receivers without going through 
a full checking procedure. Where multiple units are 
regularly joining and leaving multicasts, this can speed up 
performance considerably. 
Jumbo frames (Jumbo packets)
Since its commercial introduction in 1980, the Ethernet 
standard has been successfully extended and adapted to 
keep pace with the ever improving capabilities of computer 
systems. The achievable data rates, for instance, have risen 
in ten-fold leaps from the original 10Mbit/s to a current 
maximum of 100Gbit/s. 
While data speeds have increased massively, the standard 
defining the number of bytes (known as the Payload) 
placed into each data packet has remained resolutely stuck 
at its original level of 1500 bytes. This standard was set 
during the original speed era (10Mbits/s) and offered the 
best compromise at that speed between the time taken to 
process each packet and the time required to resend faulty 
packets due to transmission errors. 
But now networks are much faster and files/data streams 
are much larger; so time for a change? Unfortunately, a 
wholesale change to the packet size is not straightforward 
as it is a fundamental standard and changing it would mean 
a loss of backward compatibility with older systems.
Larger payload options have been around for a while, 
however, they have often been vendor specific and at 
present they remain outside the official standard. There 
is, however, increased consensus on an optional ‘Jumbo’ 
payload size of 9000 bytes and this is fully supported by 
the AdderLink Infinity (ALIF) units.
Jumbo frames (or Jumbo packets) offer advantages for 
ALIF units when transmitting certain high resolution video 
signals across a network. This is because the increased data 
in each packet reduces the number of packets that need to 
be transferred and dealt with - thus reducing latency times.
The main problem is that for jumbo frames to be possible 
on a network, all of the devices on the network must 
support them.   
						

							53
INSTALLATION
CONFIGURATION
OPERATION
FURTHERINFORMATION
INDEX
Spanning Tree Protocol (STP)
In order to build a robust network, it is necessary 
to include certain levels of redundancy within the 
interconnections between switches. This will help to 
ensure that a failure of one link does not lead to a 
complete failure of the whole network.
The danger of multiple links is that data packets, especially 
multicast packets, become involved in continual loops as 
neighboring switches use the duplicated links to send and 
resend them to each other. 
To prevent such bridging loops from occurring, the 
Spanning Tree Protocol (STP), operating at layer 2, is 
used within each switch. STP encourages all switches 
to communicate and learn about each other. It prevents 
bridging loops by blocking newly discovered links until it 
can discover the nature of the link: is it a new host or a 
new switch? 
The problem with this is that the discovery process can 
take up to 50 seconds before the block is lifted, causing 
problematic timeouts.
The answer to this issue is to enable the portfast variable 
for all host links on a switch. This will cause any new 
connection to go immediately into forwarding mode. 
However, take particular care not to enable portfast on 
any switch to switch connections as this will result in 
bridging loops.   
						

							54
INSTALLATION
CONFIGURATION
OPERATION
FURTHERINFORMATION
INDEX
Forwarding modes
In essence, the job of a layer 2 switch is to transfer as 
fast as possible, data packets arriving at one port out to 
another port as determined by the destination address. 
This is known as data forwarding and most switches offer 
a choice of methods to achieve this. Choosing the most 
appropriate forwarding method can often have a sizeable 
impact on the overall speed of switching:
• Store and forward is the original method and requires 
the switch to save each entire data packet to buffer 
memory, run an error check and then forward if no 
error is found (or otherwise discard it).
• Cut-through was developed to address the latency 
issues suffered by some store and forward switches. 
The switch begins interpreting each data packet as it 
arrives. Once the initial addressing information has been 
read, the switch immediately begins forwarding the 
data packet while the remainder is still arriving. Once 
all of the packet has been received, an error check is 
performed and, if necessary, the packet is tagged as 
being in error. This checking ‘on-the-fly’ means that 
cut-through switches cannot discard faulty packets 
themselves. However, on receipt of the marked packet, a 
host will carry out the discard process.     
• Fragment-free is a hybrid of the above two methods. 
It waits until the first 64 bits have been received before 
beginning to forward each data packet. This way the 
switch is more likely to locate and discard faulty packets 
that are fragmented due to collisions with other data 
packets.  
• Adaptive switches automatically choose between the 
above methods. Usually they start out as a cut-through 
switches and change to store and forward or fragment-
free methods if large number of errors or collisions are 
detected. 
So which one to choose? The Cut-through method has the 
least latency so is usually the best to use with AdderLink 
Infinity units. However, if the network components and/
or cabling generate a lot of errors, the Store and forward 
method should probably be used. On higher end store and 
forward switches, latency is rarely an issue.
Layer 2 and Layer 3: The OSI model
When discussing network switches, the terms Layer 2 and 
Layer 3 are very often used. These refer to parts of the 
Open System Interconnection (OSI) model, a standardised 
way to categorize the necessary functions of any standard 
network. 
There are seven layers in the OSI model and these define 
the steps needed to get the data created by you (imagine 
that you are Layer 8) reliably down onto the transmission 
medium (the cable, optical fibre, radio wave, etc.) that 
So why are Layer 2 and Layer 3 of particular importance 
when discussing AdderLink Infinity? Because the successful 
transmission of data relies upon fast and reliable passage 
through network switches – and most of these operate at 
either Layer 2 or Layer 3.
The job of any network switch is to receive each incoming 
network packet, strip away only the first few wrappers to 
discover the intended destination then rewrap the packet 
and send it in the correct direction. 
In simplified terms, the wrapper that is added at Layer 2 
(by the sending system) includes the physical address of 
the intended recipient system, i.e. the unique MAC address 
(for example, 09:f8:33:d7:66:12) that is assigned to every 
networking device at manufacture. Deciphering recipients 
at this level is more straightforward than at Layer 3, where 
the address of the recipient is represented by a logical IP 
address (e.g. 192.168.0.10) and requires greater knowledge 
of the surrounding network structure. Due to their more 
complex circuitry, Layer 3 switches are more expensive 
than Layer 2 switches of a similar build quality and are 
used more sparingly within installations.
carries the data to another user; to complete the picture, 
consider the transmission medium is Layer 0. In general, 
think of the functions carried out by the layers at the top 
as being complex, becoming less complex as you go lower 
down. 
As your data travel down from you towards the 
transmission medium (the cable), they are successively 
encapsulated at each layer within a new wrapper (along 
with a few instructions), ready for transport. Once 
transmission has been made to the intended destination, 
the reverse occurs: Each wrapper is stripped away and the 
instructions examined until finally only the original data are 
left.   
						

							55
INSTALLATION
CONFIGURATION
OPERATION
FURTHERINFORMATION
INDEX
APPENDIX E - A.I.M. API
The A.I.M. API provides access for external applications to key routines used within the 
A.I.M. server. This appendix provides a reference to the available methods. 
API version: 3
Changelog
• v3 (A.I.M. v3.2) - added create_preset, delete_preset.
• v2 (A.I.M. v2.3) - added get_devices, get_channels, connect_channel, disconnect_
channel. Updated version compatibility information.
• v1 (A.I.M. v1.3) - added login, logout, get_presets, connect_preset, disconnect_preset
Methods
login   (http:///api/#login)
info (http:///api/#info)
logout  (http:///api/#logout)
get_devices (http:///api/#get_devices)
get_channels (http:///api/#get_channels)
get_presets (http:///api/#get_presets)
connect_channel (http:///api/#connect_channel)
connect_preset (http:///api/#connect_preset)
disconnect_channel (http:///api/#disconnect_channel)
disconnect_preset (http:///api/#disconnect_preset)
create_preset (http:///api/#create_preset)
delete_preset (http:///api/#delete_preset)
login
This method was last updated in API version 1, and is compatible with API requests from version 
1 onwards.
The API will require a valid A.I.M. user’s login credentials to be presented in the first 
request. The API will return an authentication code, which must be passed in all future 
requests. This authentication code can be re-used until a logout request is made, at which 
point the authentication code will no longer be valid.
The concept of an ‘anonymous user’ can apply to the API. If no login username and 
password are provided, the API will return an authentication token for the anonymous 
user (either the same one as for the OSD, or else an ‘anonymous API user’ account can 
be created).
Input parameters:
- username
- password
- v (the A.I.M. API version this request is designed for)
Output values:
- timestamp - the current server time
- version - the current API version number
- token - an authentication code for future API requests
- success
Examples
Input:
/api/?v=1&method=login&username=xxxxx&password=xxxxx
Output:

   1
   2012-12-14 12:12:12
   1
   5cf494a71c29e9465a57a81e0a2d602c

or

   1
   2012-12-14 12:12:12
   0
   
      
         2
         Invalid username or password
      
   
   
						

							56
INSTALLATION
CONFIGURATION
OPERATION
FURTHERINFORMATION
INDEX
logout
This method was last updated in API version 1, and is compatible with API requests from 
version 1 onwards.
The authentication token provided by the Login function can be used until the logout 
function is called.
Input parameters:
- token
- v (the A.I.M. API version this request is designed for)
Output values:
- timestamp - the current server time
- success - 0 = fail, 1 = success
Examples
Input:
/api/?method=logout&token=xxxxx&v=1
Output:

   1
   2011-02-04 15:24:15
   1

or

   1
   2012-12-12 12:12:12
   0
   
      
         3
         Error logging out (you may already have logged out)
      
   

get_devices
This method was last updated in API version 2, and is compatible with API requests from 
version 2 onwards.
This function returns a list of devices.
Input parameters:
- token
- v (the A.I.M. API version this request is designed for)
- device_type (‘rx’ = receivers, ‘tx’ = transmitters. Default = ‘rx’)
- filter_d_name (Optional. Device name search string)
- filter_d_description (Optional. Device description search string)
- filter_d_location (Optional. Device location search string)
- sort (Optional. Sort results by ‘name’/’description’/’location’. Default = ‘name’)
- sort_dir (Optional. Sort direction for results ‘asc’/’desc’. Default = ‘asc’)
- status (Optional. ‘’,’outdated_A.I.M._ip’,’rebooting’,’offline’,’outdated_firmware’,’invalid_
backup_firmware’,’rebooting’,’upgrading_firmware’,’backup_mode’)
- show_all (Optional. If set and not blank, shows all receivers, not just those the logged-in 
user is permitted to use)
- page (page number to start showing results for, default = 1)
- results_per_page (number of results per page, default = 1000)
Output values:
- version - the current API version number
- timestamp - the current server time
- success
- page (page number)
- results_per_page (number of results per page, default = unlimited)
- total_devices - the total number of devices
- count_devices - the number of devices on this page
continued   
						

							57
INSTALLATION
CONFIGURATION
OPERATION
FURTHERINFORMATION
INDEX
get_devices (continued)
- for each device:
   - attribute: item (e.g. 17th device)
   - d_id (device id)
   - d_mac_address (MAC address for interface 1)
   - d_mac_address2 (MAC address for interface 2)
   - d_name (device name)
   - d_online (0 = interface 1 offline, 1 = interface 1 online)
   - d_online2 (0 = interface 2 offline, 1 = interface 2 online)
   - d_type (rx, tx)
   - d_version (1 = ALIF1000R/ALIF1000T, 2 = all other devices)
   - d_variant (‘b’ = ALIF2002T, ‘v’ = ALIF2112T, ‘s’ = ALIF1002R/ALIF1002T,  
 ‘t’ = ALIF2020R/ALIF2020T)
   - d_ip_address (IP address for interface 1)
   - d_ip_address2 (IP address for interface 2)
   - d_description (device description)
   - d_location (device location)
   - d_configured (0 = no, 1 = yes)
   - d_valid_firmware (0 = no, 1 = yes)
   - d_valid_backup_firmware (0 = no, 1 = yes)
   - d_firmware (firmware version, e.g. 2.5.17879)
   - d_backup_firmware (backup firmware version)
   - d_date_added (Date device added to A.I.M. network e.g. 2012-07-13 22:17:22)
   - d_status (0 = device offline, 1 = device online, 2 = rebooting, 4 = firmware_upgrading,   
   6 = running backup firmware)
The following property is only returned for transmitters:
   - count_transmitter_channels (the number of channels containing this transmitter)
The following properties are only returned for receivers:
   - con_exclusive (0/1 - if the last connection is/was in exclusive mode)
   - con_control (0/1 - if the last connection has/had USB enabled)
   - con_start_time (start time of last connection e.g. 2012-09-07 13:33:17)
   - con_end_time (empty if connection still active, else date/time the connection was    
 ended e.g. 2012-09-07 13:33:17)
   - u_username (username of the user who initiated the last connection)
   - u_id (user ID of the user who initiated the last connection)
   - c_name (name of the channel last connected)
   - count_receiver_groups (the number of receiver groups this receiver is a part of)
   - count_receiver_presets (the number of presets this receiver is a part of)
   - count_users (the number of users who have access to this receiver)
Examples
Input:
/api/?v=2&method=get_devices&token=xxxxx
/api/?v=2&method=get_devices&device_type=tx&page=2&results_per_
page=3&token=xxxxx
Output:

   2
   2012-09-12 14:56:11
   1
   2
   3
   12
   3
   
      
         170
         00:0F:58:01:6E:3D
         00:0F:58:5B:6E:3D
         RX 123
         1
         0
         rx
         2
         
         10.10.10.66
         10.10.10.67
         
         Server Rack 3
         1
         1
         1
         2.3.16682
         2.3.16682
         2012-07-14 01:37:07
continued   
						

							58
INSTALLATION
CONFIGURATION
OPERATION
FURTHERINFORMATION
INDEX
get_devices (continued)        
         1
         0
         1
         2012-09-07 13:33:19
         
         admin
         1
         Channel 1
         1
         2
         1
      
   


   2
   2012-09-12 14:56:11
   1
   1
   1
   1
   1
   
      
         64
         00:0F:58:01:56:85
         00:0F:58:5B:56:85
         TX 456
         0
         0
         tx
         1
         
         1.1.201.31
         1.1.201.32
         
         
         1
         1
         1
         2.1.15747
         2.1.15747
         2012-07-13 17:50:04
         0
         3
      
   

get_channels
This method was last updated in API version 2, and is compatible with API requests from 
version 2 onwards.
This simple function returns a list of channels available to the authenticated user, for a 
specific receiver.
Input parameters:
- token
- v (the A.I.M. API version this request is designed for)
- page (page number to start showing results for, default = 1)
- results_per_page (number of results per page, default = 1000)
- device_id (ID of the receiver that this channel will be connected to. Recommended to 
ensure full checks for connection mode availability.
- filter_c_name (channel name search string)
- filter_c_description (channel description search string)
- filter_c_location (channel location search string)
- filter_favourites (set this non-empty to only show a user’s favourites)
Output values:
- version - the current API version number
- timestamp - the current server time
- success
- page (page number)
- results_per_page (number of results per page, default = unlimited)
- count_channels - the number of channels on this page, available to the authenticated user
continued   
						

							59
INSTALLATION
CONFIGURATION
OPERATION
FURTHERINFORMATION
INDEX
get_channels (continued)
- for each channel:
   - attribute: item (e.g. 17th channel)
   - c_id (channel id)
 - c_name (channel name)
 - c_description (channel description)
 - c_location (channel location)
 - c_favourite (true if this channel is in the user’s favourites, 0-9 if it’s a      
 numbered shortcut)
   - view_button (disabled/enabled/hidden - whether the user can connect to the    
 preset in view-only mode.
     disabled = no, because something is in use by someone else.  
 hidden = never. enabled = yes
     If the device_id of the proposed receiver to be used in the connection is not    
 provided, this will not necessarily be an accurate indication of whether other    
 connections may actually interfere)
   - shared_button (disabled/enabled/hidden - as above, but in shared mode)
   - exclusive_button (disabled/enabled/hidden - as above, but in exclusive mode)
Examples
Input:
/api/?v=2&method=get_channels&token=xxxxx
Output:

   2
   2012-12-14 12:12:12
   1
   1
   10
   2
   
      3
      Channel 1
      Description for Channel 1
      Location of Channel 1
      false
      disabled
      disabled
      disabled
   
   
      5
      Channel 2
      Description for Channel 2
      Location of Channel 2
      2
      disabled
      enabled
      hidden