I've been using my TBS2603 with MythTV, and it's been great except for one problem.
As far as I understand, MythTV seems to rely on the duration information of each video packet (or frame?) in order to make it possible to seek back and forth accurately within a recording. Sometimes with the transport stream that comes as part of an over-the-air broadcast, the framerate will change in the middle, say from 60fps to 30fps, and then back to 60fps, especially with commercials. So the framerate of the video overall can't really be used to co-relate position in the recording file with time because of this. Hence, I think they use this packet or frame duration information within the video stream to do this accurately.
From what I can tell, the video within a transport stream produced by the TBS2603 doesn't contain any packet duration at all.
I am using the ffprobe utility (part of the ffmpeg tool suite on Linux) to examine the content of the video packets from the TBS2603, like this:
ffprobe -i tbs2603_file.ts -show_packets -select_streams v
You then get a bunch of output like this:
...
[PACKET]
codec_type=video
stream_index=0
pts=8098077717
pts_time=89978.641300
dts=8098077717
dts_time=89978.641300
duration=N/A
duration_time=N/A
convergence_duration=N/A
convergence_duration_time=N/A
size=2354
pos=14633920
flags=_
[/PACKET]
...
See how the attributes for duation are listed as N/A? On transport streams from other types of sources, these duration attributes are filled in.
Is there any chance this can be corrected with a new firmware release?
Thanks.