Opened 10 years ago

Closed 9 years ago

Last modified 7 years ago

#10007 closed Bug Report - General (Fixed)

HD-PVR has bogus PTS values with latest firmware

Reported by: gdelx001@… Owned by: tralph
Priority: minor Milestone: 0.25
Component: MythTV - Video Playback Version: 0.24.1
Severity: medium Keywords: video lag sync
Cc: Ticket locked: no


My Hauppauge HD PVR 1212's output has played flawlessly on the current version of mythtv for some time, but that stopped immediately once I had to update the firmware on the device to gain stability on initiating recording with the stb to which it is attached (it either worked or didn't - there wasn't a problem with a successful recording, before now).

Now I am having a problem with MythTV 0.24.1-2 (rpmfusion distribution for Fedora 14) player audio sync on streams made by the Hauppauge HD PVR 1212. Different playback hardware has the same problem. Different recording hardware (a Hauppauge composite video recording card) which produces a different output format (MPEG) does not exhibit the problem. The audio leads the video by (typically) 400ms so you noticeably and annoyingly hear action before you see it. This can be adjusted on each playback by hand using the audio sync menu item and the delay is stable throughout the recording. But given the impermanence of the setting and applicability specifically to that device's recordings this isn't an acceptable long term solution.

I have confirmed that this sync issue doesn't occur playing the same exact streams back in VLC. Nor does going to software playback from VDPAU in MythTV appear to have any fundamental effect. There aren't always messages in the xsession log indicating the problem, although sometimes there are indications from the frontend that some expected structures are missing from the stream ("non-existing PPS referenced" or "non-existing SPS 4 referenced in buffering period" or "no frame!" or "decode_slice_header error"). Since these don't always occur and the mis-sync of audio always occurs (with h264) I'm not focusing on them.

This didn't happen before a recent firmware update on the HD PVR taking it from version 0xf to 0x17 (May 2009->July 2011 release date), leading me to _speculate_ that some assumptions made by MythTV about h264 streams are no longer met, that Hauppauge tightened or expanded their adherence to spec, which VLC can tolerate and MythTV can't.

If it's thought to be the most fruitful course, I'm willing to spellunk with a hex editor or other viewer in the files (examples before and after the firmware change) and diff'ing to help identify the problem if I'm given some direction about tools and where to focus. Alternatively if snippets of the large recording files are desired, instructions on how to do best to extract would be helpful.

Attachments (2)

mythfrontend_stutter.log (158.8 KB) - added by Raymond Wagner 9 years ago.
mythfrontend_outofsync.log (242.8 KB) - added by Raymond Wagner 9 years ago.

Download all attachments as: .zip

Change History (26)

comment:1 Changed 9 years ago by markk

Owner: markk deleted
Status: newassigned

Hopefully someone else can pick this up - not really my 'specialist subject'.

comment:2 Changed 9 years ago by danielk

Owner: set to danielk
Status: assignedaccepted

comment:3 Changed 9 years ago by danielk

Status: acceptedinfoneeded

Please attach a link to a 15 second sample video exhibiting the problem. Also, which audio input were you using? optical or front or back analog inputs? Which set top box are you using?

comment:4 Changed 9 years ago by gdelx001@…

Please instruct (or reference) how to extract the sample. Keep in mind the clear examples (mouth motions not in sync with dialog) may be some time into the recording which may not be where the problem is set up. Also do you want some sample of pre-firmware-upgrade files that don't have the problem?

Can I please share a link to what samples I get offline?

Now the delay of audio required I typically see is 3500ms or more!!! And (I don't have the log handy to excerpt) but in one case myth repeatedly complains about the inconsistency that it is trying desperately to advance the sound further but already 180 video frames have been buffered. Evidence at least that myth has been misled to overcompensate in the wrong direction (by firing audio play _early_), and kinda knows it.

Audio recorded is SPDIF.

STB is Motorola QIP 7100.

comment:5 Changed 9 years ago by Asher Schaffer <freedenizen@…>

It looks like the logs that were requested here:

never made it to the list due to file size, they are available for download on these two links: and

The stutter log is from a DCT6200 and the out of sync is from an RNG100, both connected via SPDIF.

Changed 9 years ago by Raymond Wagner

Attachment: mythfrontend_stutter.log added

Changed 9 years ago by Raymond Wagner

Attachment: mythfrontend_outofsync.log added

comment:6 Changed 9 years ago by danielk

To make the samples create a recording and then use the split command to extract a chunk that shows a talking head or other video where the sync issue is apparent.

comment:7 in reply to:  6 Changed 9 years ago by gdelx001@…

Replying to danielk:

To make the samples create a recording and then use the split command to extract a chunk that shows a talking head or other video where the sync issue is apparent.

OK done (20 seconds). mythavtest was helpful to visualize and confirm the result exhibited the error.

I am unable/unwilling to host general public access to the resulting file anywhere. Danielk please discuss (out-of-ticket if appropriate) on the most convenient means for you to get a copy of the file.

comment:8 Changed 9 years ago by danielk

Resolution: Invalid
Status: infoneededclosed

This is most likely a bug in the firmware, but without samples it's impossible to tell.

comment:9 Changed 9 years ago by gdelx001@…

Vlc plays it back in sync so it is possible to do so. I believe that makes a judgement on the firmware irrelevant.

As previously stated I've been waiting for a proposal on how to exchange the sample with you. I'm just not willing to host _general_ public access to the file (i.e. broadcast a URL in this venue.) Thanks.

comment:10 Changed 9 years ago by gdelx001@…

Resolution: Invalid
Status: closednew

You may now find the 17MB snippet file exhibiting the audio sync issue at

The problem with the snippet file persists in mythtv 0.24.2 (at least in mythavtest).

The source recording has the sync problem in mythtv 0.24.2 but audio is in sync in vlc 1.1.13

comment:11 Changed 9 years ago by tralph


Could you report which version of the HD-PVR firmware you are using? This is output by the driver when initialized in the kernel logs.

The reason myth has an issue is that the video contains bad pts timestamps which we prefer now. If the code is changed to use dts timestamps for AV sync then it plays properly.

It's not possible for the code to know that the pts timestamps are wrong so we'll have to decide if moving back to dts is worth the trade off. In the end it's not the fault of myth but the HD-PVR. IIRC, older firmware did produce bad pts timestamps.

And the reason vlc plays it back properly is that it uses dts timestamps.

comment:12 Changed 9 years ago by gdelx001@…

As the primary ticket text above says, the firmware version is 0x17. This is what the driver reports in the syslog. This corresponds to July 2011 release.

comment:13 Changed 9 years ago by tralph


I believe 0x18 is included with the latest windows driver. Might be worth trying.

comment:14 Changed 9 years ago by gdelx001@…

Updating firmware on this device is much easier suggested than done with this non-Windows setup: will have to get back to you. It would be really nice to have _some_ assurance that the effort will be worth it for A/V sync; the change description on their site doesn't hint (to me) that is one of the things they fixed.

comment:15 Changed 9 years ago by gdelx001@…

Turns out 0x1a is the latest firmware. Alas video recorded under it has the same out-of-sync issue. Since vlc plays it just fine, it looks like I am caught: need newer firmware to work reliably with my stb, need really old firmware to have something that plays back acceptably in Myth.

comment:16 Changed 9 years ago by tralph

Thanks for taking the time to test the latest firmware. Too bad it's still busted. So I've spoken with some other devs and I think the best course of action is to add an environment variable that will allow a user to force the use of dts timestamps. They should work fine not only for your HD-PVR recordings but everything else too.

In the meantime if you are compiling from source I can provide a patch to force the use of dts timestamps. Just let me know.

comment:17 Changed 9 years ago by danielk

Milestone: unknown0.25
Owner: changed from danielk to tralph
Status: newassigned
Summary: Video lags audio (sync) by ~400ms on hd pvr 1212 h264 recordings (only) after firmware update.HD-PVR has bogus PTS values with latest firmware

comment:18 Changed 9 years ago by tralph

Resolution: Fixed
Status: assignedclosed


Please try the new -fixes code when the packages update. You can run mythfrontend with the dts timestamps as follows:


comment:19 Changed 9 years ago by tralph

comment:20 Changed 9 years ago by gdelx001@…

Sounds good!

Haven't been compiling from source, but probably will attempt to apply patches to the RPMFusion SRPMs for Myth for consistency. Will let you know how applying it to their current v0.24.2 works out.

comment:21 Changed 9 years ago by gdelx001@…

RPMFusion mythtv-libs already patches the avformatdecoder file(s) so had to hand-backport the patch. But rebuilt and installed the patched package successfully. That plus environment variable does the trick on HD livetv and several (probably all) my old HD recordings that _were_ annoying to watch in the myth viewer.

Thanks much for the fix!

comment:22 Changed 9 years ago by greenup@…

I have a HD-PVR that was experiencing the same horrible audio sync, and thankfully, upgrading and using this environment variable fix that problem, however, when the frontend runs that way, I can't skip forward 30 seconds or back 8, it just gives a message "searching..." and then bombs out of the show back to the recorded listings.

I tell you what; once you lose skip, you really appreciate how valuable it is...

any ideas about this problem? is anyone else (gdelx001?) experiencing it?


greenup at g mail dotcom

comment:23 Changed 9 years ago by gdelx001@…

I am on rpmfusion's mythtv 0.25-6, which has the dts workaround (responds to the variable) and have had no problems with skipping forward or backward on HD recordings with it.

Doesn't seem at first blush to be related to this ticket.

Working playback is on VDPAU-enabled hardware, if that makes a difference.

comment:24 Changed 7 years ago by sean@…

I ran into this problem today with an Hauppauge HD PVR 1445 with firmware x15 (1.70 I believe) and this flag fixed it. Jumping forward and back on a VDPAU hardware also worked. Thanks!

Note: See TracTickets for help on using tickets.