Data Handling

Perhaps the most important controls for any Burli system are those governing how data is handled — where it is stored, how long it is displayed, when (or if) it is deleted and where and how it is mirrored for redundancy.

Data Settings

The controls are found in the main Burli program. With Burli running, press Shift-F8, or choose ‘Config’ then ‘Program Setup’ on the menu bar. A tabbed dialogue box gives you access to all configuration options.

Primary root path

Burli stores its networked data in sub-directories under a single directory, or root path. If you are running Burli in a stand-alone environment, the root directory is set by default to “C:\Burli”. In a network environment, the root data directory resides on a commonly-accessible network drive, as in \\News1\Burli. As long as each workstation is pointing the same root path, you will be able to share all data, including newswire stories, audio feeds, faxes, e-mail and other features. All workstations should have full read and write access to this directory and its subdirectories.
The primary root path is normally set as part of the software install process.

Alternate root path

This setting is rarely used in version 195 and higher. Alternate (redundant) data storage locations are now managed by Burli’s separate mirroring and redundancy utility, BurliSync.

Mirror audio

Play-to-air workstations should enable this feature, which automatically mirrors (copies) in-queue audio to the local hard disk so that when the workstation plays audio, it does so from a file on the local hard disk. This feature eliminates audio dropouts in the unlikely event of network congestion or failure during a news bulletin. The decay value, in minutes, determines how long mirrored audio files should remain on the local hard disk after they were last referenced on the server. A value of 120 minutes, or two hours, is usually adequate. More information can be found here.

In-queue buffer

The in-queue buffer determines the maximum number of stories that are available at any given Burli workstation. Burli uses a ‘first in, last out’ buffer; when a new story is received, the oldest story in the buffer is removed. Typically, the buffer size is between 1000 and 20,000 stories, depending on your needs. Try to have all workstations use the same size buffer as workstations with smaller In-Queue buffers will see fewer stories in their In-queue, filters and search results which can be confusing. There is a MAIN.INI setting which can set all workstations to the same value so all workstations will see exactly the same stories and overrides any local buffer settings.
Where ### is the number of stories shown in the In-queue

Event Logs

Pressing this button brings up a list of relevant diagnostic logs that Burli can create to help with troubleshooting. You will not normally need to turn these on, but may be asked to activate one or more when you contact Burli’s technical support department. Logs files that are created are stored in the \Burli\Logs directory on the machine where they were turned on. Logs are always machine-specific. All event logs are automatically deleted after 7 days by default so there is no harm in turning them on.

Diskspace Advisories

This feature monitors free disk space on the root path (file server) and issues warnings if it falls below a certain level. The button only becomes active when you turn on the Purging features (see below). Only one workstation on the network (the one responsible for purging) monitors server disk space. By default Burli issues warnings when fewer than 200MB of disk space remain, but pressing this button lets you set the warning threshold to any value you like.

Purging data

You should have only one Burli workstation on your network as the one responsible for purging your data files. Chose the Burli workstation that you wish to make responsible for data purging system-wide and on that machine click the check-box labeled ‘This workstation purges data files’.
Note — If more than one workstation purges data or users change any of these settings, important newsroom data can easily be lost.
To prevent more that one machine from purging your data, you can specify the HASP ID of the one machine you want to do that. We recommend that you make this one of your main Burli Server or Capture machines. The MAIN.INI setting is:
PurgeDongle=[HASP ID]
For example:
This will grey out the Purge settings on all but the one machine specified.


The In-queue files contain the data for all material in the In-queue. Burli creates a new In-queue file for each day. Set the number of days before purging to a large value (e.g. 90) if you wish to periodically conduct a keyword search of outdated newswire stories; set it to a small value (e.g. 4 days) if you do not require archival searching. Technical note — For the first weeks after installation you should monitor the average size of the Burli data files (\In-queue directory off root data path) to determine if you have sufficient hard disk space for long-term storage of log files. You may be able to adjust the settings depending on how much data your  newsroom handles. For all workstaitions, this setting is in relation to the In-queue buffer size setting since Burli will only be able to show as many stories as you have days of In-Queue data.


As with the data files, you need to determine how long to keep your newscast script files, based both on your archival search needs as well as available hard disk space. Newscast script files are stored in date-specific subdirectories in the \Burli\scripts directory off the network root path. By default this setting is 0 which means never delete the script files. They are usually quite small so there is no harm in keeping them.

In-house posted audio

Audio posted locally to the in-queue is purged after a certain number of hours, according to the hold and decay values. The hold value determines the minimum number of hours since the story was posted to the In-queue that the system should keep the audio. The decay value takes into account the last time an audio file was referenced in a newscast script. This ensures that often-used audio clips are not deleted prematurely. For more information, see the discussion about hold and decay values on the Audio Capture page.

Note that audio will likely be deleted from your system long before the rest of your in-queue material. Audio is often deleted after a few hours but In-queue purging usually happens after a few days. The result is some In-house posted audio items further down the In-queue may get deleted from disk while they are still visible to users. Users trying to work with these files will get a message saying the file is no longer available. In this case, you may want to adjust you settings to minimise this issue. If you have enough hard-drive space, the simplest method is to increase the In-house posted audio value to cover the same amount of days.