HDHomerun, possible problem with GB-PVR TS Mux DS Filter and a bad PAT packet.

[lstepnio]

I've been working with "jafa" supporting the HDHR hardware on the HDHR forums and it seems that there might be a potential issue the GB-PVR TS-Mux DS filter inserting a bad PAT at the start of the capture. Jafa states this isn't originating from the device and most likey a DS filter.

The thread following thread on the HDHR forums has the information:
http://www.silicondust.com/forum/viewtop...ght=#16603
* Please ignore the first portion of the linked thread as the first issue was a HDHR filtering issue resolved by an update to the firmware code.

I have sample captures linked in that thread if you wish to examine them. I wouldn't consider this a major issue as I'm able to play these captures back but one of these recording had a very bad timeline that caused some issues for playback. The timeline might or not be related to the bad PAT packet that jafa noticed.

[sub]

I've been working with "jafa" supporting the HDHR hardware on the HDHR forums and it seems that there might be a potential issue the GB-PVR TS-Mux DS filter inserting a bad PAT at the start of the capture. Jafa states this isn't originating from the device and most likey a DS filter.

The thread following thread on the HDHR forums has the information:
http://www.silicondust.com/forum/viewtop...ght=#16603
* Please ignore the first portion of the linked thread as the first issue was a HDHR filtering issue resolved by an update to the firmware code.

Its certainly possible. GB-PVR does create the 188 byte PAT packets. All the rest of the audio/video packets are saved verbatim though.

I'll download your sample capture and take a look at the PAT.

I have sample captures linked in that thread if you wish to examine them. I wouldn't consider this a major issue as I'm able to play these captures back but one of these recording had a very bad timeline that caused some issues for playback. The timeline might or not be related to the bad PAT packet that jafa noticed.

Its unlikely the PAT would be the cause of any bad timeline you've encountered though. The PAT just lists the services in the transport stream. All the timing info is contained in the audio/video packets, and derived by the TS source filter you're using for playback.

[wtg]

I've seen these funky timelines when recording to DVR-MS format with the HDHR, but I've only noticed with while watching an in-progress recording. While the recording is being made the timeline gb-pvr shows might say the video is 48:34 long and 22 minutes into it, when it's only been recording for 3 minutes. However, as soon as the recording finishes, the timeline looks fine. I've just assumed this was a problem with gb-pvr.

Could this be the case with your videos too, lstepnio, or is the video's timeline messed up even after the recording is finished?

[lstepnio]

I've seen these funky timelines when recording to DVR-MS format with the HDHR, but I've only noticed with while watching an in-progress recording. While the recording is being made the timeline gb-pvr shows might say the video is 48:34 long and 22 minutes into it, when it's only been recording for 3 minutes. However, as soon as the recording finishes, the timeline looks fine. I've just assumed this was a problem with gb-pvr.

Could this be the case with your videos too, lstepnio, or is the video's timeline messed up even after the recording is finished?

The timeline issue was a single occurance so far which the capture was saved as a transport stream and the recording was complete. I still have issues when I fast forward it starts fast forwarding from 10-15 seconds before I started the fast forward but this might be a NVIDIA PureVideo DS quirk.

How is a timeline in a transport stream generated? I'm having a hard time finding information that explains how the timeline works in TS.

It does sound like the PAT packet in question is inserted by the GB-PVR DS filters and it seems to have an invalid pointer to the program number but it's not related to the timeline issue I experienced but could cause issues with some playback filters with the invalid pointer.

[sub]

Try this patch to see if helps you. It fixes a situation that can lead to a broken PAT packet in the transport stream recording.

How is a timeline in a transport stream generated? I'm having a hard time finding information that explains how the timeline works in TS.

The audio/video PES packets contained with in the transport stream packets, contain presentation timestamps, as encoded by broadcaster. This is what is used for timing. If the recording had been converted to a program stream file, then a mux filter (cyberlink, ATI etc) add an additional layer of timestamps around this, but this isnt required with a simple .TS file.

It does sound like the PAT packet in question is inserted by the GB-PVR DS filters and it seems to have an invalid pointer to the program number but it's not related to the timeline issue I experienced but could cause issues with some playback filters with the invalid pointer.

Maybe, you never know.

[lstepnio]

I'll give the patch a try today or tomorrow and I'll post feedback. Thanks for taking the time to look into this.

[lstepnio]

I just wanted to report that the patch seems to of resolved issue with the invalid packet with all recordings since the update. This along with the HDHR related bug I reported corrected with the latest firmware update goes a long way to making the GB-PVR & HDHR a very solid solution.

This being said the internal media player in GB-PVR is still the weakest link in the whole solution for HD playback. I'm still hoping for an option to allow playback in an external player to be reconsidered. Either way, I still consider GB-PVR a much better overall solution over any of the commericial PVR solututions (SageTV, BTV). This really is excellent work on your part, sub. I've dontated already recently and plan on donating again. Thanks again!

[sub]

I just wanted to report that the patch seems to of resolved issue with the invalid packet with all recordings since the update. This along with the HDHR related bug I reported corrected with the latest firmware update goes a long way to making the GB-PVR & HDHR a very solid solution.

Great.

This being said the internal media player in GB-PVR is still the weakest link in the whole solution for HD playback. I'm still hoping for an option to allow playback in an external player to be reconsidered.

Sorry, I wont be adding support for external players, but I would appreciate feedback on what is weak about the built in playback so I can improve it.

[wtg]

Sub,

Does the patch above contain the memusage.zip patches too?

Thanks.

[sub]

From memory, the memusage.zip version of NativeUtilities.dll is later, so its better to apply that one. Check the dates.