Duplicate for standby failing on recover phase

I won't bore you with the details, but due to several kernel panics and server crashes, we had to switchover from the primary on node1 to the standby on node2 so they could address the problem on node1. DataGuard wasn't configured, so the DBA tried a manual switchover. The switchover moved the primary to node2, but node1 did not become the standby for some reason. All attempts to get it to startup as a standby failed with errors suggesting a failover was done, not a switchover. After they fixed node1, we decided to rebuild the standby on node1 from the active database on node2. The duplicate phase, which takes approximately 12 hours, worked just fine. However, the DORECOVER fails due to missing archivelogs. Kind of stuck at this point since we can copy the logs manually, but I don't know the command to use to perform recovery. It doesn't appear that the logs are being shipped during the duplicate phase. I have searched MOS as well as google for answers, but nothing has popped up which seems to offer a good solution. Due to the restricted nature of the environment, I can't post any log details. However, we do receive the following errors during the DORECOVER phase:

• RMAN-03009
• RMAN-03002
• RMAN-05501
• RMAN-03015
• ORA-19625
• ORA-27037

I have thought of two possible options to get around archivelogs not being shipped right away, although I would prefer to find out why it isn't happening and correct it.

1. Duplicate only in the script. Ships logs manually if necessary. Recover manually. (Just not sure what the commands would be to do the recovery.) Start managed recovery.
2. Since the mount where both node1 and node2 write their archivelogs is shared, use the same log_archive_dest for both the primary and standby. Make sure logs are shipping from the primary to log_archivelog_dest_2. Change the standby to log_archive_dest to the original node1 location. Start managed recovery. I'm not sure if this is a viable option or not.