Thanks for your report! The behavior where frameCount differs based on the Timecode Offset is a bug. I'm seeing it happen for both in/out capture and batch capture. It's been logged with tracking #2704054.
The timecode sent to the recorder should already have the timecode offset value factored in. For example, when batch capturing a clip at 25 fps, from 10:00 to 11:00, with the timecode offset set to 10 frames, your recorder should receive recmod_PrepRecord8 with recCapParmsRec8.timeCode set to 250 + 10 = 260 frames. So the timecode offset should be factored in recCapParmsRec8.timeCode, and that should be what you need to know the adjusted timecode.
Giving a correct recCapParmsRec8.timeCode value is enough for adjusting video frames capturing, but not enough for matching timecode to the frames.
i.e. in 25 fps, capturing from xx:xx:10:00 to xx:xx:20:00, the picture in 10:00 is "ZERO", the picture in 20:00 is "Two Hundred Fifty". Due to the hardware/system error, the captured result is "ONE" in xx:xx:10:00. Therefor, you adjust the offset to -1(or 1), PPro tells the recorder to start capture at timecode xx:xx:09:24 and capture 250 frames, recorder will capture the frames from "ZERO" to "Two Hundred Fifty" (which is good), but will match them to the timecode xx:xx:09:24 to xx:xx:19:24. Writing this timecode to the meta data of the video files is not correct, and there is no way to adjust it.
Good point. I've logged this with tracking #2708838.
I suppose if you needed to get this working in 5.0.1, you could provide your own Timecode Offset entry control in your Capture Settings or Device Control dialog.