Just a bump to let you guys know we're still looking into this issue.
Our tests show the iPod does return to the main menu when playing Mark's most recent sample file. The file is 12 hours in length, encoded at 64Kbps, 22.05kHz, stereo. The issue is very easy to duplicate with Mark's file by pausing at 1:38:44, playing a Podcast for a few seconds, pausing and playing Mark's file again. It reliably fails at 1:39:02.
Since we received Mark's file we followed through on a couple of hunches about the ftyp and stik atom values in the moov header - neither panned out. So we created a test file to match Mark's in audio configuration (64Kbps/22.05kHz/stereo) and length and verified it also exhibits the same symptoms. Like Mark's file our 12-hour test fails at 1:39:02 after pausing at 1:38:44. Interestingly, a 4-hour file at the same audio configuration (64Kbps/22.05kHz/stereo) does not fail in the same way at the same point in the 12-hour file. The 4-hour test keeps trucking - and we haven't seen it fail at all yet. Also, several reports in our research indicate 5 hours is the max for reliable bookmarks. We'll test 5-hour output soon.
We haven't seen a pattern that indicates stereo fails sooner than mono. Have you?
While the issue is not exclusively caused by interacting with Podcasts, the play Audiobook/pause Audiobook/play Podcast/pause Podcast/play Audiobook method is the most efficient way we've found to duplicate the issue. Any time we can save while testing for this issue is a good thing