I would suggest trying a couple things. First, make sure that you do not have another process dumping transaction logs or doing SQL backups other than SMSQL. This can cause an interruption in the LSN numbers and make SMSQL unable to replay logs. Second,creating a clone of one of the offending databases using SMSQL and bring the database up into standby mode. Now try using SQL and manually play the .TRB files like you would a normal .TRN file against the database. This process should validate that the logs are in fact there and good.
Also, are you using a CIFS share for your T-LOG dumps, or are you using the SnapInfo directory?
Please post back and let us know if either of these fixed your issue.
I'm having the same issue as Christian with almost the same setup: jobs alternate every hour between a full snapshot (with log backup) and a log-only backup. All the log backup files are stored in a snapinfo directory, and I see one for each hour. Since this issue only affects some of our databases and not all of them, I was able to make an educated guess that this issue probably started when someone manually deleted several .TRB files when the snapinfo LUN was almost full, and so there probably was a broken log chain at some point.
I tried the scenario you suggested and cloned one of the problem databases with a snapshot from 7am this morning. Then, using the log backups in the snapinfo directory, I manually restored the 7am log backup followed by the 8am log backup, both worked fine with no issues.
I know that a regular SQL full backup will reset the log chain, I'm guessing that a SnapManager full snapshot doesn't do the same? Would creating a SQL full backup solve the issue with SnapManager not recognizing any successive log backups?