Hauppauge Capture - HD PVR2 Occasional Problems with Conversion

Wondering if anyone has any solutions to an occasional problem where when I record with Hauppauge Capture as a TS file and do cuts, occasionally the recording will fail to convert. The TS itself will play fine, but even if I try cutting manually with ffmpeg I’ll have problems. The typical problem is that I’ll get a file that is very short, for example a tv show that should be 40-45 mins after cuts will be 20 mins, or sometimes will just be a few seconds and only show the cover art.

When this happens the only solution is to re-record. Also occasionally happens with MP4.

I’ve tried OBS, but not been successful in getting something that looks decent. Typically have weird horizontal blurring and most suggestions are around FPS, and the device does 60fps, so tried 60, 30 (somone said use a multiple) and I think 55 but all are pretty much same.

Sounds like your tuner/recording driver is creating corrupted video during a weak signal period.

Try this:

  1. Switch your profile order to use handbrake first and then ffmpeg
  2. In the Conversion task → Expert settings enable Skip remuxing

What this will do is bypass ffmpeg which seems to be having trouble processing corrupted video and instead it should let handbrake try and handle it.

I’ll try it next failure. Don’t think I’ve kept any of the previous failed files.
I know we’ve discussed this before, and I believe I had tried handbrake and it may have also failed - but would have been a few months ago

The Brothers Celebrating The Allman Brothers Band 50th Anniversary (2024).ts-TestingAV1Conversions-2024-09-06T18-58-04.log (7.2 MB)

It’s been a few weeks but I did finally run into an example of a problem and I’ve tried looking at the logs but at least in this case I don’t think the problem is the conversion, but the cutting at least in this case. I’m using EDL files that I create with cusom cuts and the resulting video looks to be missing 2 parts. The recoring is from a PBS station that is doing fundraising so there are a few large cuts, larger than typical commercials, There were 5 cuts including start and end, so 4 ‘good’ pieces and best I can see from the resulting file is that it’s missing the last 2. Video should be around 1hr and is only about 38 mins.
Any thoughts?

I do see 5 cuts identified

2024-09-06T18:58:56 MCEBuddy.CommercialScan.Remover → ParseEDL: Cut Segment Start:0.000 End:61.301 Action:0
2024-09-06T18:58:56 MCEBuddy.CommercialScan.Remover → ParseEDL: Cut Segment Start:1212.502 End:1753.003 Action:0
2024-09-06T18:58:56 MCEBuddy.CommercialScan.Remover → ParseEDL: Cut Segment Start:2920.505 End:3536.006 Action:0
2024-09-06T18:58:56 MCEBuddy.CommercialScan.Remover → ParseEDL: Cut Segment Start:4776.211 End:5307.011 Action:0
2024-09-06T18:58:56 MCEBuddy.CommercialScan.Remover → ParseEDL: Cut Segment Start:5414.414 End:6543.000 Action:0

Then I see a failure when trying to cut the 3rd segment

2024-09-06T18:59:26 MCEBuddy.AppWrapper.FFmpeg → Conversion failed!
→ Process exited with code -1094995529
→ FFMpeg output file size [KB] → 34.00

Thereafter it stops and doesn’t cut the remaining segments (it shouldn’t so it may be a bug there) but it appears the original file may be corrupted.

2024-09-06T18:59:26 MCEBuddy.AppWrapper.FFmpeg → [mpegts @ 0000019b322f5e00] Invalid timestamps stream=0, pts=9216112, dts=9216113, size=14338
2024-09-06T18:59:26 MCEBuddy.AppWrapper.FFmpeg → [mpegts @ 0000019b322f5e00] Invalid timestamps stream=0, pts=9492388, dts=9492389, size=38037
2024-09-06T18:59:26 MCEBuddy.AppWrapper.FFmpeg → [mpegts @ 0000019b322f5e00] PES packet size mismatch
2024-09-06T18:59:26 MCEBuddy.AppWrapper.FFmpeg → [mpegts @ 0000019b322f5e00] Packet corrupt (stream = 0, dts = 594041354).
2024-09-06T18:59:26 MCEBuddy.AppWrapper.FFmpeg → [mpegts @ 0000019b322f5e00] PES packet size mismatch
2024-09-06T18:59:26 MCEBuddy.AppWrapper.FFmpeg → [mpegts @ 0000019b322f5e00] Packet corrupt (stream = 0, dts = 594041354).

Can you upload the original TS file and your .EDL file so we can replicate the issue and see what’s going on.

uploaded under jsam01

Thanks for the sample. It appears that the original video has a lot of timestamp corruption (likely caused either by a bad OTA signal or a tv tuner driver issue which could be addressed if it’s a problem by trying a different tv tuner driver version or amping up the OTA signal).

There was a bug in MCEBuddy where it failed to properly detect the corruption and so it would end up ignoring the corrupted video. We’ve fixed that in the latest 2.6.5 beta version. Now it will detect the corrupted video and if it can’t make the cuts prior to conversion, it will try to correct the video issues during the conversion and then try to cut the commercials out after conversion. When this happens it will take longer to process the conversion but it should be able to recover the video and cut the commercials successfully.

Try out the latest beta build and let me know how it goes.

I gave 2.6.5 a try and it does seem to work, I saw it cut the 2nd time at the end. Cuts are slightly off compared to say the original - at least the start of the video with 2.65 included a bit of what I was trying to cut.

I’ll see if I can do something with the device - it’s not a tuner it’s a video recording device technically for gaming, but it hdmi and component inputs, so I’m using component from my cable box. I do see the driver appears to be a higher number than is available on their website which is a bit odd, and it’s a bit long of a usb cable so I might try moving the box and getting a shorter newer cable.

I ran the video file you uploaded along the EDL cuts file through MCEBuddy 2.6.5 beta using the MP4 Unprocessed profile. It cut exactly as per the EDL file which matches the original file. I didn’t notice any difference in the cut points (no more than about 1 sec sync which happens because cuts are always on GOP boundaries otherwise you’ll see video tearing).

What profile are you using?