In Log-shipping what is load delay period on secondary server - Skipping log backup file since load delay period has not expired ....

Question

During logshipping, job on secondary server is ran successfully BUT give this information
"Skipping log backup file since load delay period has not expired ...."
What is this "Load delay period" ? Can we configure this somehow, somewhere ?
NOTE : The value on "Restore Transasction Log tab", Delay Restoring backups at least = Default (zero minutes)
Thanks
Think BIG but Positive, may be GLOBAL better UNIVERSAL.

Answer 1

How to get the LSBackup, LSCopy, and LSRestore jobs back in sync...
Last I posted the issue was that my trn backups were not being copied from Primary to Secondary. 
I found upon further inspection of the LS related tables  in MSDB the following likely candidates for adjustment:
1) dbo.log_shipping_monitor_secondary, column  last_copied_file 
change last copied file column to something older than the file that is stuck. For example, the value in the table was 
E:\SQLLogShip\myDB_20140527150001.trn
I changed last_copied_file to E:\SQLLogShip\myDB_20140525235000.trn. Note that this is just a made up file name that is a few minutes before the actual file that I would like to restore (myDB_2014525235428.trn). 4 mins and 28 seconds before, to
be exact.
LSCOPY runs and voila! now it is copied from primary to secondary. That appears to be the only change needed to get the copy going again.
2) For LSRestore, see the MSDB table dbo.log_shipping_monitor_secondary, change
last_restored_file
again I used the made up file E:\SQLLogShip\myDB_20140525235000.trn
LSRESTORE runs and my just copied myDB_2014525235428.trn is restored
** note that
dbo.log_shipping_secondary_databases also has a last_restored_file column - this did not seem to have any effect, though I see that it updates after completing the above and LSRestore has run successfully, so now it is correct as well
3) LSBackup job is still not running, the job still has a last run date in the future. Could just leave it and eventually it will come right, but I made a fairly significant time change, plus it's all an experiment....back to MSDB.
look at dbo.sysjobs, get the job_id of your LSBackup job
edit dbo.sysjobschedules - change next_run_date  next_run_time as needed to a datetime before the current time, or when you would like the job to start running. 
I wouldn't be so cavalier with data that was important, but that's the benefit of being in Test, and it appears that these time comparisons are very rudimentary - a value in the relevant log shipping table and the name of the trn file. That said, if you
were facing a problem of this nature due to lost trn files, corrupted, or some similar scenario, this wouldn't fix your problem, though it _might_ allow you to continue? But in my case I know I have all the trn files, it's just the time that changed, in this
case on my Primary server, and thus the names of the trn logs got out sync.