I found two solutions to this problem.

I am testing log shipping on our test server in SQL 2005. In this test environment, there are no active transactions happening. The log shipping restore job kept skipping the log shipping backups, UNTIL, I created a table in the primary DB...then when I ran the restore job it still skipped the previous backups but it restored the latest backup since there were changes to apply. So when I do this in my production environment, it probably won't be an issue, this is just an issue in the quiet testing environment. Makes sense, SQL doesn't need to restore a log backup initially until something changes.

One other work around is you can update log_shipping_monitor_secondary to a known good backup and after doing that the restore job started applying the backups:

UPDATE [msdb].[dbo].[log_shipping_monitor_secondary]

SET [last_restored_file] = 'X:\SomeLogshippingFolder\LogshippedDB_20130308222505.trn'