Sound Issues with HD PVR2

[gandalf]

Originally Posted by BobPhoenix

What you describe is similar sounding to what I get with my Colossus via HDMI. I just make sure I record a show as many times as I can and delete all the others after I find a good one.

That sounds similar to me trying to schedule SD recordings to duplicate HD ones in case they do not work. Both are certainly workarounds".

However it does not "solve" the problem - nor does it help where the program is a live sporting event that is only broadcast by Shaw on Sportsnet World. That channel is one of their "new" standard MP4 channels and I can only resolve it with the Motorola/PVR2 tuner setup. Perhaps I could try putting s-video into the old PVR250 card and recording the output of the Moto STB on two devices at once - might try that sometime.

Right now this is in the class of "irritating" - because it only really affects Sportsnet World, unless I need the extra tuner for conflicts. 99% of Shaw channels will record on the old PVR analog card or the R5000s. However the prognosis from Shaw is that they will be migrating to MP4 slowly - so the problem will get critical when they move more mainstream channels over and I need the new tuner setup on a regular basis. At a pinch you can watch a soccer game without sound and get most of the useful information from it visually. Doesn't work quite so well on drama - perhaps I should try to master lip-reading.

[gandalf]

OK - I did try further playing with Arcsoft.

It turns out that the Moto DCX3200 always produces 1080i video - even from SD channels. Thought that was configurable - but if it is I can't see how. So I am stuck with 1080i video. Arcsoft, however, shows it is seeing 720 x 480 video - not sure how, but that is what is says (as noted below 1080i was what was recorded - go figure). I selected the second of the "HDMI" audio settings, which does seem (as suggested earlier) to really be the optical audio input. With that setting we get audio that shows as 2-channel from SD sources and 6-channel from HD sources - which looks encouraging.

I tried to see if I could select MPEG2 - but, although Arcsoft shows the option, it is not selectable. So the PVR2 would seem to be fixed at H264 (which is fairly logical). Everything else is at the default settings.

I ran checks on many SD and HD channels and checked the results with MediaInfo - playing the files with Windows Media Player. Not a single problem. Audio switched between 2ch and 6ch as the source went from SD to HD. Video was always 1080i (even though Arcsoft showed 720x480).

So rebooting now and resetting the system for SageTV. Will report back on what happened tomorrow.

[KeithAbbott]

Originally Posted by gandalf

It turns out that the Moto DCX3200 always produces 1080i video - even from SD channels. Thought that was configurable - but if it is I can't see how.

Google on "DCX3200 Installation Manual". It has instructions on how to configure the video output.

[gandalf]

Originally Posted by KeithAbbott

Google on "DCX3200 Installation Manual". It has instructions on how to configure the video output.

Thanks for the suggestion.

Unfortunately it is not that easy. The manual certainly shows how to do it - but the DCX3200 is way too clever, being software configurable on the fly by the cable company. When I use the onscreen menus (the way Shaw tells you to do it), it is as I said - no option to change from one fixed setting. The manual does show a different way to hack the menu by powering off and hitting MENU immediately. Trying that with this box causes it to immediately go out of menu mode and power back on - so evidently the Shaw-specific software is set up to trap that path.

Result - what I want (ie "native mode") does not seem to be accessible on the Shaw network.

I think I tried this way in the past by disconnecting the cable service and playing with the box on its own. I did then make it do a few things that were "agaimst the rules" as set by Shaw. However as soon as I plugged the cable back in the DCX3200 irritatingly reset itself to Shaw rules.

I even talked to an expert in Shaw about this because I wanted to change its behaviour re channel mapping HD and SD channels. It will not respond to instructions to select HD channels if there is an SD equivalent - Shaw rules want you to select the SD channel and let the clever little box replace it with the HD source. I wanted to have either option (which the box can do) so I have standard channels across all my sources. No joy - the nasty Shaw server resets the choices to force the user to comply with its rules. The Shaw expert explained that the DCX3200 has a 2-way data channel open to the Shaw server so it can handle scripted channel and sub-channel mapping in a sophisticated way that they can change at will.

Unfortunately there is no other way to receive MP4 sourced channels - so I will just have to accept their rules and live with it. 1080i for SD channels is just a waste of recording space - but I can always transcode the result later.

Why do the cable companies make life so complex in their quest to
"simplify" things?

[gandalf]

No, this is not a solution - just an update on the problem, which is now REALLY starting to bug me.
Shaw recently introduced the digital version of Knowledge Network - which is good news. However, in keeping withn their policy that all new channels will be MP4, the new channel is not resolvable by my R5000 tuners. The Motorola 3200 / HD/PVR2 combo should do the job. I have fixed the tuner priority issue and now have it so that the silly HD/SD translation will work with Sage TV (on the new Moto box you have to select the SD channel number and let it convert that number to the HD channel - but that is another story altogether).
The first recording I set up produced no sound - AARGH!!
Playing the recorded file with VLC works fine - which tells me that the sound is there and that my computer must contain codecs to work with whatever is recorded.
Media-Info shows the following:
General
ID : 0 (0x0)
Complete name : P:\Sage Video\GreatCanadianRivers-TheRedDeer-13931128-0.ts
Format : MPEG-TS
File size : 2.63 GiB
Duration : 29mn 43s
Overall bit rate mode : Variable
Overall bit rate : 12.6 Mbps

Video
ID : 4113 (0x1011)
Menu ID : 1 (0x1)
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.0
Format settings, CABAC : Yes
Format settings, ReFrames : 3 frames
Codec ID : 27
Duration : 29mn 42s
Bit rate : 11.8 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 29.970 fps
Standard : Component
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Interlaced
Bits/(Pixel*Frame) : 0.190
Stream size : 2.46 GiB (93%)
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709

Audio
ID : 4352 (0x1100)
Menu ID : 1 (0x1)
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Format settings, Endianness : Big
Codec ID : 129
Duration : 64ms
Bit rate mode : Constant
Bit rate : 192 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 1.50 KiB (0%)

SageTV plays the program with no sound - as does Windows Media Player. VLC works fine - but, as commented by others earlier in the thread, that does not mean that the file is correctly formatted. I cannot correct the problem using any of the stream editors I have tried but I cannot see what it is that I am trying to correct - can anyone shed light on this?
Obviously the audio and video source get through to the PVR, so we are not looking at a Moto STB issue or a problem with the optical sound. The problem is internal to the formatting of the file - a mux or codec issue. That surely must be a problem with the PVR2.
I am tempted to go back to Hauppauge and seek their advice on how their box can clearly take input video and audio and produce a non-standard output that cannot be read by standards compliant players. I will not hold my breath though.
I cannot see any configuration options that might help me.
So, experts out there - any thoughts or pearls of wisdom to offer?

[BobPhoenix]

Originally Posted by gandalf

I cannot correct the problem using any of the stream editors I have tried but I cannot see what it is that I am trying to correct - can anyone shed light on this?

You didn't mention any but did you try VideoReDo? Did you try EAC3TO to demux the video and audio into separate files and then combine them back into an MKV for instance? Would never work for live viewing but if it was something you wanted to save it might be an acceptable workaround.

Hauppauge needs to fix their driver - still possible - and SageTV would then need to apply some fixes to it's playback - not possible - or possibly direct show in OS - still possible - to really fix this!

[gandalf]

I generally use TSDoctor to fix most stream problems. It did not fix the issues with this file, so I will take it up with them. However it is interesting that asking TSDoctor to demux the audio and video into separate files produced an audio file with a minor but probably significant difference.
MediaInfo shows the following:
General
Complete name : C:\Scratchdisk\GreatCanadianRivers-TheRedDeer-13931128-0_PID_1100_.ac3
Format : AC-3
Format/Info : Audio Coding 3
File size : 40.8 MiB
Duration : 29mn 42s
Overall bit rate mode : Constant
Overall bit rate : 192 Kbps

Audio
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Format settings, Endianness : Big
Duration : 29mn 42s
Bit rate mode : Constant
Bit rate : 192 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 40.8 MiB (100%)

If you compare this with my previous post you will see that the "duration" shows as 29:42 - as opposed to just a few ms for the audio component of the original stream. Likely that explains why standards compliant players are silent. The audio is there alright - just the header says it only lasts for a few ms.
There is an update to the Hauppauge driver, though it does not mention this problem in the fix list. I will try loading it and report back.

****

Update - no change, same problem. Reported it to Hauppauge - will see what they have to say.

[KryptoNyte]

I would also recommend running the files through VideoRedo's Quickstream Fix to see if it resolves the issue. It's not cheap software, but it's been invaluable for working with television recordings, and I believe you can run the software fully in evaluation mode for a couple weeks at least.

[gandalf]

Originally Posted by KryptoNyte

I would also recommend running the files through VideoRedo's Quickstream Fix to see if it resolves the issue. It's not cheap software, but it's been invaluable for working with television recordings, and I believe you can run the software fully in evaluation mode for a couple weeks at least.

Thanks for the suggestion re VideoRedo. I have passed a question to the TS Doctor support line to see why that software does not fix the problem - which it should do since stream fixing is its forte. If I can avoid the need to spend another $100 for more software I would prefer that (and only the top version of VideoRedo will handle H264).
I also have a ticket out with Hauppauge to try to see if the problem can be fixed at source so correcting streams is only a short term fix.
Incidentally, I did get TSDoctor to demux the file into separate audio and video files - the result was perfectly normal audio that had a correct duration value. If I wanted to spend the time I could re-mux the files back into a standard video format - but if going to that trouble I may as well just watch outside SageTV using VLC.

[gandalf]

I got a suggestion from the author of TS Doctor. We tried deleting the PAT and PMT entries in the stream and letting TS Doctor recreate them based on what was actually in the stream - seems like the original file contained AC3 audio but the audio stream entries showed it as AAC.

Well, did what was suggested and the recoded headers are understood by Windows Media Player. I then stopped the SageTV server and copied the new file over the old. When the SageTV server restarted the entry now plays audio.

So we have a fix and we know what is going wrong. It seems to be triggered by the source switching back and forth between AAC and AC3 - probably because the Moto STB is set by Shaw to always generate 1080i video even from SD sources.

I have some interest from a friend at Shaw who is looking at some of the STB issues I raised - and I am waiting for a response from Hauppauge to the ticket.

Keep watching - progress is being made.

[phelme]

Originally Posted by gandalf

I got a suggestion from the author of TS Doctor. We tried deleting the PAT and PMT entries in the stream and letting TS Doctor recreate them based on what was actually in the stream -

Yeah, it's the MPEG headers that are the problem. Since SageTV is a dead product , there haven't been any possibilities of the PMT/PAT scanning to be enhanced in any of its playback facilities, extenders or software. It sucks.

On the other hand, I'm not sure what Hauppague is doing differently in the 1512 vs the 1212 when writing to the stream headers, but it occasionally is something Sage and others doesn't understand. Like your STB, my DirecTV box via the 1512 usually throws my HD300 into a tizzy when the recording has a switch from 2 channel to 5.1 channel (often happens on HBO etc.). I finally gave up and went strictly to 2 channel, but even then I get the occasional recording that has header problems. For example, American Horror Story from the other night on FX was recorded in a way that even the latest Handbrake choked on. It couldn't interpret the header and find any video or audio streams. I've reset the Showbiz application to its defaults hoping it might help.

[gandalf]

I agree re the MPEG headers. However I think the issue is with Hauppauge not SageTV - so there may be hope in getting it fixed.

The problem with the new STB as Shaw have it configured is that it generates 1080i video all the time - supposedly to "simplify things". However SD sources generate AC3 audio and HD sources AAC - so the box switches audio mode a few ms after the channel change. I think that is what is upsetting the Hauppauge HD PVR - if it initially sees 1080i with AC3 then it sets up its output to that mode, however the STB promptly changes its mind and starts supplying AAC audio then we have a situation that the PVR does not cope with. According to standards it should cope with an audio codec change - which can happen in commercial breaks - perhaps it is the short time that is the problem.

What I am now going to try is to add a couple of seconds to the "wait time after tuning" so that the STB can get its act together before SageTV fires up the PVR. That just might fix the problem - however the SageTV system is busy for most of the rest of the day so it will be tomorrow before I can report back on what happened.

[gandalf]

OK - we are getting closer to solving this problem. I talked with Cypheros, who produce the TSDoctor stream editor that I use to clean up TS files. They looked over the problem stream and sent back this report:

in the log you'll find two different PMTs:
----------- PMT 0 -----------
Packet : $00000002
PacketCount : 1
PID : $0200
Table ID : 2
Section Syntax Indicator : 1
PMT Size : 37
Pointer Field : 0
Section Length : 29
Program Number : $0001
Version Number : 29
Current Next Indicator : 1
Section Number : 0
Last Section Number : 0
PCR PID : $1011

Program Info Length : 0

Stream Type : 27
Description : AVC video stream as defined in ITU-T Rec. H.264 | ISO/IEC 14496-10 Video
Elementary PID : $1011
ES Info Length : 3
ES Info : $52, $01, $00
ES Info Text : R__

Stream Type : 15
Description : ISO/IEC 13818-7 Audio with ADTS transport syntax (AAC ADTS)
Elementary PID : $1100
ES Info Length : 3
ES Info : $52, $01, $10
ES Info Text : R__

CRC32 : $1FEBF2D2 = $1FEBF2D2
-----------------------------



----------- PMT 1 -----------
Packet : $000006D1
PacketCount : 1
PID : $0200
Table ID : 2
Section Syntax Indicator : 1
PMT Size : 37
Pointer Field : 0
Section Length : 29
Program Number : $0001
Version Number : 30
Current Next Indicator : 1
Section Number : 0
Last Section Number : 0
PCR PID : $1011

Program Info Length : 0

Stream Type : 27
Description : AVC video stream as defined in ITU-T Rec. H.264 | ISO/IEC 14496-10 Video
Elementary PID : $1011
ES Info Length : 3
ES Info : $52, $01, $00
ES Info Text : R__

Stream Type : 129
Description : Private stream type Audio AC3 (AC3)
Elementary PID : $1100
ES Info Length : 3
ES Info : $52, $01, $10
ES Info Text : R__

CRC32 : $7ACA5934 = $7ACA5934
-----------------------------
The first PMT found is the wrong one with AAC audio descriptor. I don't know why Haupauge put this wrong PMTs into the stream because there is no single AAC audio packet in the stream, only AC3 packets can be found.

This are the start bytes of first 20 packets audio packets I have extracted with my "special" version of TS-Doctor:
$1100 stream type AC3 Audio: 0B,77,1F,65,1C,30,E3,C7,
$1100 stream type AC3 Audio: 0B,77,46,F7,1C,30,E3,C7,
$1100 stream type AC3 Audio: 0B,77,88,90,1C,30,E3,C7,
$1100 stream type AC3 Audio: 0B,77,72,0A,1C,30,E3,C7,
$1100 stream type AC3 Audio: 0B,77,4C,BA,1C,30,E3,C7,
$1100 stream type AC3 Audio: 0B,77,C1,3C,1C,30,E3,C7,
$1100 stream type AC3 Audio: 0B,77,43,6B,1C,30,E3,C7,
$1100 stream type AC3 Audio: 0B,77,CA,99,1C,30,E3,C7,
$1100 stream type AC3 Audio: 0B,77,20,EF,1C,30,E3,C7,
$1100 stream type AC3 Audio: 0B,77,23,0A,1C,30,E3,C7,
$1100 stream type AC3 Audio: 0B,77,1D,25,1C,30,E3,C7,
$1100 stream type AC3 Audio: 0B,77,B5,1A,1C,30,E3,C7,
$1100 stream type AC3 Audio: 0B,77,7F,75,1C,30,E3,C7,
$1100 stream type AC3 Audio: 0B,77,0F,67,1C,30,E3,C7,
$1100 stream type AC3 Audio: 0B,77,B8,FD,1C,30,E3,C7,
$1100 stream type AC3 Audio: 0B,77,A6,90,1C,30,E3,C7,
$1100 stream type AC3 Audio: 0B,77,7C,12,1C,30,E3,C7,
$1100 stream type AC3 Audio: 0B,77,F8,C4,1C,30,E3,C7,
$1100 stream type AC3 Audio: 0B,77,77,97,1C,30,E3,C7,
$1100 stream type AC3 Audio: 0B,77,18,42,1C,30,E3,C7,
As you see, all elementary stream packets have the same AC3 start code.
So the first PMTs are wrong and I'm pretty sure that the Haupauge software is responsible for this failure.

All of which points the finger clearly at Hauppauge as several of you agreed. I have sent this detail to them as part of the ticket I opened. I will report back when I get a reply.

Meanwhile I can also report that the flawed TS files can be run through TSDoctor (latest beta version) and the fixed stream can replace the flawed one in the Sage Video folder (as long as SageTV is stopped during the file replace and the name is kept the same). On restart, SageTV will then play audio on the program that was originally flawed.

[popechild]

Add me to the list of people having trouble with audio not playing back on recordings made with the HD-PVR 2. I just bought the 2 to replace a failing HD-PVR 1 (and still have a second HD-PVR 1 working alongside the 2 now.) Ever since setting up the v2, I get occasional recordings where the audio doesn't play. I've tried HDMI and component/spdif. I certainly haven't dug into it as much as you have, but it's starting to get pretty annoying.

All that to say, I'll be subscribing to this thread and hope you're able to figure out a solution.

[Evil_Attorney]

Originally Posted by popechild

Add me to the list of people having trouble with audio not playing back on recordings made with the HD-PVR 2. I just bought the 2 to replace a failing HD-PVR 1 (and still have a second HD-PVR 1 working alongside the 2 now.) Ever since setting up the v2, I get occasional recordings where the audio doesn't play. I've tried HDMI and component/spdif. I certainly haven't dug into it as much as you have, but it's starting to get pretty annoying.

All that to say, I'll be subscribing to this thread and hope you're able to figure out a solution.

Same here. I was only getting it on "live" TV on the HD300. Hauppauge took a quick look at the files I was having issues with and simply gave up on my problems. They are more focused on gamers these days, not those of us that use these units for HTPC purposes.

[gandalf]

Just a quick update on what is going on.

We now know that the problem is caused by the way that the HDPVR2 reacts to a CODEC change in the audio stream.

If the source starts with one CODEC and then immediately switches to a differnt one then the HDPVR2 will produce a PMT for the first CODEC followed by a second PMT for the correct CODEC.

The problem is that this violates standards for a contiguous stream - which can change PARAMETERS for a CODEC (2 ch to 5 ch and back) but NOT the CODEC itself. Standards compliant players see the first CODEC PMT entry and use that - ignoring the second PMT. Hence they end up with the wrong CODEC and in turn play no audio. VLC is a bit more dirty and it simply trashes and reinitializes the stream with the new CODEC - so it works.

TSDoctor will now process the stream with two PMT entries and remove the wrong one - so the "cleaned" stream can be returned to SageTV's folder (while SageTV is stopped - making sure the file name is the same) and the result will play fine .

Hauppauge admit they know about the problem - but had no clear idea why it happened or what needed fixing. They know now and there is hope they might come out with a new driver for us. I will keep fingers crossed but will not hold my breath - I need the oxygen.

I will post more when I hear back from Hauppauge.

Meanwhile - for those of you who have silent shows, you might care to either play the file with VLC or try the TSDoctor stream fix approach (http://www.cypheros.de/tsdoctor_e.html). The good news is that the sound is there - just not recorded with the first CODEC named as it should be.

[SHS]

Yup that true but it doesn't happing all time gandalf

[Evil_Attorney]

Great detective work. I guess there is hope yet.

[gandalf]

Originally Posted by SHS

Yup that true but it doesn't happing all time gandalf

Yes, unfortunately that is quite true. The engineer in me does not like situations where we cannot explain the circumstances behind a problem - it just confirms we do not fully understand the problem. I have said that to Hauppauge. I cannot predict the circumstances that cause this problem to surface - and that indeed confirms I do not fully understand the problem.

What I do understand is that, for some unexplained reason, the HD PVR2 sometimes inserts two conflicting PMT entries in the output stream. It should not do that - period. I would like to understand why it does it but the basic need is for it to stop the practice and give us clean streams all the time.

I am having some success by asking SageTV to insert a 10 sec pause after tuning to allow the STB to produce output for a time before the PVR recording process is triggered. The problem is that even that delay, which should not be needed, does not 100% solve the problem.

Hauppauge can work at solving why this happens - or, more likely, they can just update the driver software to stop the stream before changing CODEC.

As a user, I really don't care which. I just want their system to do what it was bought to do ... reliably and in conformance to standards.

The good news, even if I haven't been provided a fix yet, is that their tech people are still talking to me and are looking at the packet level detail (created by their software) that I supplied them. As of this week they admitted that they know there is a problem with sound under some circumstances but that they did not know exactly what the problem was. They know now.

There is still hope.

[SHS]

Hope they be able to solve it gandalf