Right, this appears to be a bug.
To manifest this apparent bug, first ensure that you are running a Shoutcast server, and that the system is configured for autoDJ Failsafe.
Now set up a playlist in AutoDJ and ensure that it plays out correctly.
Monitor the audio and metadata at the stream output with a player. Check that the autoDJ playlist metada is displayed.
Now deactivate the autoDJ and begin live streaming from a remote source with metadata. You should see the remote metadata displayed on the player (restart player if necessary).
At some point you will see the remote metadata replaced by the metadata from an item in the autoDJ playlist.
The audio from the remote source will not be affected - only the metadata.
When the remote source moves to the next track in its own playlist, the metadata display on the player will change and display the correct remote metadata.
EXACTLY FIVE MINUTES after the autoDJ metadata was displayed you will see it again, displaying another track's metadata from the autoDJ playlist.
You can also see the rogue metadata appear in the CentovaCast "recent tracks" display list and also as it occurs, at the bottom of the CentovaCast screen.
I hypothesise that the cron job is kicking in the autoDJ failsafe mechanism which tries to start up and issues metadata. It immediately fails and goes back to sleep, until the cron job kicks it into action again 5 minutes later.
If you require your metadata record to be accurate, eg for licensing purposes, this may render the autoDJ failsafe mechanism unusable.