Hauppauge HD-PVR & Colossus Support (6 Viewers)

[mm1352000]

Regarding the volume, I think I just found what cause this. I'm recording DD5.1 so... when I play it on my PC with only 2.1, it may make sense that the conversion to put the dialog (usually on the center channel) on both speaker is having to respect the volume of those two speakers. I'm not sure that my explanation make sense but... I just saw that if I record a station that is stereo (PCM), the volume is an order of magniture louder so... It probably is the way it is. It is just strange that the HD-PVR would record a little "louder" then the Colossus with the exact same source. (One after the other, not both connected to the same source at once).

So both connected with the SPDIF audio give the different results.
I guess it all depends on whether the Colossus and HD-PVR are doing the same processing with respect to audio decoding, mixing and encoding. I know the Colossus has much more advanced capabilities in this regard.
The only way to address this in such a way that you boost the volume for the Colossus without touching the volume for the HD-PVR is going to be auto volume leveling and compression, or mucking around with the Colossus settings in Arcsoft showbiz. I'm sorry, I'm not really able to be of much assistance in that domain.

For the last part, I think my question was not clear even if your answer will probably to be the same. I'm not looking to slow down/delay the channel changer. I would like the recording to start a few second after the channel changer is taking place. So, tune station 123, wait 2 sec, start recording. Right now, I'm seeing the channel changing in the recording so... it seems that the Colossus is starting it's job pretty close to the channel changing operation.

I do understand what you mean.
To bounce it back at you, you're saying the delay would be inserted after the blaster has sent its command. It is just a delay waiting for the STB to actually change channel and the Colossus' encoder to kick in.
I do get that.
The perfect delay would be to wait until we see the stream change, and no longer. That would be a variable delay. However that is tricky to detect. Further, TV Server's reaction speed would add an additional delay on top of the desired delay.

Are you willing to run a non-standard patch in order to get this functionality?
Can you provide your TV log files so I can take a quick peek and see if what I'm thinking is possible.

Just for clarification, the TS file generated are working but the first second or so is full of "junk" because of the resolution/audio changes. Some player don't like this and will stutter or sometime just stop playing. That said, you can start the same file with the same player just after killing it first and it may work. After doing a quickstream fix with VideoRedo, the files are cleaner and the player usually behave without stuttering or other problem.

Yup, understood.
As mentioned, our focus is on MP rather than other players (why are you using WMP by the way? Just curious...).

 

[ehfortin]

Hi,

The only way to address this in such a way that you boost the volume for the Colossus without touching the volume for the HD-PVR is going to be auto volume leveling and compression, or mucking around with the Colossus settings in Arcsoft showbiz. I'm sorry, I'm not really able to be of much assistance in that domain.

I'm replacing the HD-PVR with the Colossus so I don't need to keep the settings for the HD-PVR. Outside of the Arcsoft showbiz settings, are you saying there is something we can set somewhere in MP regarding auto-volume leveling that work with the Colossus? I've pretty much abandonned any hope to change this so I'll continue to pump up the volume at the ampli level

I do understand what you mean.
To bounce it back at you, you're saying the delay would be inserted after the blaster has sent its command. It is just a delay waiting for the STB to actually change channel and the Colossus' encoder to kick in.
I do get that.
The perfect delay would be to wait until we see the stream change, and no longer. That would be a variable delay. However that is tricky to detect. Further, TV Server's reaction speed would add an additional delay on top of the desired delay.

Are you willing to run a non-standard patch in order to get this functionality?
Can you provide your TV log files so I can take a quick peek and see if what I'm thinking is possible.

Well, it depend on what TV Server is actually doing. What I would like to try, is to start the recording after the channel has been changed. Right now, it seems that it is started about at the same time. If it is after the channel changing code, adding a delay should be simpler then if it is the other way around. I'm relying on you for that part.

I'm with you that it would be perfect if TV Server could "sense" that the stream has changed and then, start recording but it may be complex as it may be deep into the code.

I'm including both my tv log as well as the twriter log. As you will see in the tv log, I'm using IRSS to change the channel. If I read correctly, the recording is started just after the channel changing is done so that's when a delay could be useful.

Now, if you look at the tswriter log, you will see two "discontinuity" event when starting a recording. I'm not sure what it is but it was there for both recording today. I think it may be because of the format and/or audio change.

Let me know if this is something you want to pursue. I'm willing to run a non-standard patch to see if it is helping. I assume that if it actually improve the way it work, this may end up in the software so it may not stay a non-standard patch

BTW, I'm not using WMP to play a movie. I test the file with it just to see if everything is fine. I'm using OpenElec (XBMC) to play the file. But that said, I've seen problem with XBMC as well so since, I'm trying all the file in WMP to see if the beginning of the recording is clean. If not (stuttering), I do a quickstream fix in VideoRedo before moving it to my NAS.

Thank you.

ehfortin

 

[mm1352000]

Hello again

I'm replacing the HD-PVR with the Colossus so I don't need to keep the settings for the HD-PVR. Outside of the Arcsoft showbiz settings, are you saying there is something we can set somewhere in MP regarding auto-volume leveling that work with the Colossus? I've pretty much abandonned any hope to change this so I'll continue to pump up the volume at the ampli level

For the recording, there is probably not much you can do. I thought the Colossus had audio downmixing capabilities, but according to the screenshot -->here<-- I am mistaken. So your only solution would be at playback time, or post-processing the recordings. With MP, you can use codecs like ffdshow for post-processing to mix the channels as desired. That means your amp would not be receiving DD - it would receive LPCM... I think.
http://www.hack7mc.com/2009/02/simple-ffdshow-audio-settings.html

I don't know if that kind of stuff is possible with XBMC given that the decoders are built in.

Well, it depend on what TV Server is actually doing. What I would like to try, is to start the recording after the channel has been changed. Right now, it seems that it is started about at the same time. If it is after the channel changing code, adding a delay should be simpler then if it is the other way around. I'm relying on you for that part.

It is a little complex because things don't happen sequentially when you use a blaster.
Normally TV Server tunes, then starts the recording.
With a blaster involved, you're "tuning" and blasting the commands at roughly the same time. There is no real guarantee of which will happen or finish first.

I'll try to talk you through an example from the log files:
[collapse]2012-10-03 19:59:59.015625 [Record(27)]: TV3BlasterPlugin: Received TV Server Event "StartZapChannel"
2012-10-03 19:59:59.031250 [Record(27)]: TV3BlasterPlugin: Analog channel input source "YRYBYInput1"
2012-10-03 19:59:59.031250 [Record(27)]: TV3BlasterPlugin: Tune request - Card: 4, Channel: 1303, 1303 MFUNHD
2012-10-03 19:59:59.031250 [ProcessExternalChannel(12)]: TV3BlasterPlugin: ProcessExternalCommand("Blast: Select|Default", -1, 1303)
2012-10-03 19:59:59.031250 [ProcessExternalChannel(12)]: TV3BlasterPlugin - BlastIR(): C:\Documents and Settings\All Users\Application Data\IR Server Suite\IR Commands\Select.IR, Default [/collapse]
So first the blaster plugin is notified that TV Server is about to change channel. It starts its own process or thread for actually sending the commands to the STB. In other words, TV Server doesn't wait for the commands to be sent. It carries on tuning. TV Server has nothing to do with the blaster process after this. It effectively forgets about it and carries on tuning...

[collapse]2012-10-03 19:59:59.031250 [Record(27)]: TVServerXBMC: OnTvServerEvent: StartZapChannel
2012-10-03 19:59:59.031250 [Record(27)]: card: Tune 4 to 1303 MFUNHD
2012-10-03 19:59:59.046875 [Record(27)]: card: user: ForTheRecord27:4:-1 tune tv:1303 MFUNHD Freq:0 Channel:1303 Country:Canada Tuner:Cable Video:YRYBYInput1 AudioPDIFInput2
2012-10-03 19:59:59.046875 [Record(27)]: HDPVR: Tune:-1, tv:1303 MFUNHD Freq:0 Channel:1303 Country:Canada Tuner:Cable Video:YRYBYInput1 AudioPDIFInput2
2012-10-03 19:59:59.046875 [Record(27)]: HDPVR: GetNewSubChannel:0 #0
2012-10-03 19:59:59.062500 [Record(27)]: subch:0 OnBeforeTune
2012-10-03 19:59:59.062500 [Record(27)]: HDPVR: Tune
2012-10-03 19:59:59.062500 [Record(27)]: HDPVR: Tuned to channel 1303 MFUNHD
2012-10-03 19:59:59.062500 [Record(27)]: subch:0 OnAfterTune
2012-10-03 19:59:59.062500 [Record(27)]: subch:0 OnGraphStart
2012-10-03 19:59:59.062500 [Record(27)]: HDPVR: RunGraph
2012-10-03 19:59:59.109375 [Record(27)]: HDPVR: Graph running
2012-10-03 19:59:59.109375 [Record(27)]: subch:0 OnGraphStarted
2012-10-03 19:59:59.109375 [Record(27)]: subch:0 SetupPmtGrabberid 100 sid:1
2012-10-03 19:59:59.109375 [Record(27)]: subch:0 set pmt grabber pmt:100 sid:1
2012-10-03 19:59:59.218750 [(19)]: HDPVR: OnPMTReceived() subch:0 pid 0x100
2012-10-03 19:59:59.234375 [Record(27)]: HDPVR: found PMT after 0.109375 seconds
2012-10-03 19:59:59.234375 [Record(27)]: HDPVR: PMT sid=0x1 pid=0x100 version=0x0
2012-10-03 19:59:59.234375 [Record(27)]: Decode pmt
2012-10-03 19:59:59.234375 [Record(27)]: subch:0 SetMpegPidMapping
2012-10-03 19:59:59.234375 [Record(27)]: subch:0 pid:1001 pcr
2012-10-03 19:59:59.234375 [Record(27)]: subch:0 pid:100 pmt
2012-10-03 19:59:59.234375 [Record(27)]: subch:0 pid:1011 video type:H.264
2012-10-03 19:59:59.234375 [Record(27)]: subch:0 map pid:1011 video type:H.264
2012-10-03 19:59:59.234375 [Record(27)]: subch:0 pid:1100 audio lang: type:AAC
2012-10-03 19:59:59.234375 [Record(27)]: subch:0 map pid:1100 audio lang: type:AAC
2012-10-03 19:59:59.234375 [Record(27)]: card: Tuner locked: True
2012-10-03 19:59:59.234375 [Record(27)]: **************************************************
2012-10-03 19:59:59.234375 [Record(27)]: ***** SIGNAL LEVEL: 100, SIGNAL QUALITY: 100 *****
2012-10-03 19:59:59.234375 [Record(27)]: **************************************************
2012-10-03 19:59:59.234375 [Record(27)]: card: tuned user: ForTheRecord27 subchannel: 0
2012-10-03 19:59:59.234375 [Record(27)]: user:ForTheRecord27 add
2012-10-03 19:59:59.234375 [Record(27)]: TV3BlasterPlugin: Received TV Server Event "EndZapChannel"
2012-10-03 19:59:59.234375 [Record(27)]: TVServerXBMC: OnTvServerEvent: EndZapChannel
2012-10-03 19:59:59.250000 [Record(27)]: Recorder.start add audioVideoEventHandler
2012-10-03 19:59:59.250000 [Record(27)]: card: StartRecording 4 C:\Recorded\Movies\The Rum Diary\The Rum Diary.ts
2012-10-03 19:59:59.250000 [Record(27)]: StartRecording to C:\Recorded\Movies\The Rum Diary\The Rum Diary.ts
2012-10-03 19:59:59.250000 [Record(27)]: analog: Encoder mode setting to VariableBitRateAverage
2012-10-03 19:59:59.250000 [Record(27)]: analog: Encoder mode setTo FAILresult: -2147024865
2012-10-03 19:59:59.250000 [Record(27)]: analog: Encoder BitRate setting to Low
2012-10-03 19:59:59.250000 [Record(27)]: analog: Encoder BitRate Min 100000 Max 20000000 Delta 100000
2012-10-03 19:59:59.250000 [Record(27)]: analog: Range SetEncoder(BitRate) FAILresult: 0x8007001f
2012-10-03 19:59:59.250000 [Record(27)]: subch:0 StartRecord(C:\Recorded\Movies\The Rum Diary\The Rum Diary.ts)
2012-10-03 19:59:59.250000 [Record(27)]: subch:0-0 tswriter StartRecording...
2012-10-03 19:59:59.250000 [Record(27)]: SetRecorderPids
2012-10-03 19:59:59.250000 [Record(27)]: Set video / audio observer
2012-10-03 19:59:59.250000 [Record(27)]: HDPVR subch:0 Started recording
2012-10-03 19:59:59.250000 [Record(27)]: card: WaitForRecordingFile - waiting _eventAudio & _eventVideo
2012-10-03 19:59:59.281250 [GenericPCQueue(13)]: TV3BlasterPlugin: Received Message "BlastIR"
2012-10-03 19:59:59.281250 [GenericPCQueue(13)]: TV3BlasterPlugin: Blast successful
2012-10-03 19:59:59.296875 [(19)]: PID seen - type = Video
2012-10-03 19:59:59.296875 [(19)]: Recorder audioVideoEventHandler Video
2012-10-03 19:59:59.296875 [(19)]: PID seen - type = Audio
2012-10-03 19:59:59.296875 [(19)]: Recorder audioVideoEventHandler Audio
2012-10-03 19:59:59.296875 [Record(27)]: card: WaitForRecordingFile - video and audio are seen after 0.046875 seconds [/collapse]
Here we have a typical tuning process. TV Server:
1. Ensures that the Colossus is switched to receive video and audio from the correct physical inputs (eg. HDMI, component etc.).
2. Starts the stream from the Colossus.
3. Waits for PMT, which contains the details about which audio and video streams are present in the stream.
4. Tells TsWriter to start recording.
5. Waits until TsWriter sees video and audio.

If you were timeshifting, at this point TV Server would tell MP (XBMC in your case) that the channel is tuned and timeshifting can be started.

The blaster process is running in parallel to all of that, but it ends up completing after TV Server:
[collapse]2012-10-03 19:59:59.406250 [Record(27)]: RecordingThread [The Rum Diary]: Calling AddNewRecording()
2012-10-03 19:59:59.750000 [ProcessExternalChannel(12)]: TV3BlasterPlugin: ProcessExternalCommand("Blast: Digit 1|Default", 1, 1303)
2012-10-03 19:59:59.750000 [ProcessExternalChannel(12)]: TV3BlasterPlugin - BlastIR(): C:\Documents and Settings\All Users\Application Data\IR Server Suite\IR Commands\Digit 1.IR, Default
2012-10-03 20:00:00.203125 [GenericPCQueue(13)]: TV3BlasterPlugin: Received Message "BlastIR"
2012-10-03 20:00:00.203125 [GenericPCQueue(13)]: TV3BlasterPlugin: Blast successful
2012-10-03 20:00:00.453125 [ProcessExternalChannel(12)]: TV3BlasterPlugin: ProcessExternalCommand("Blast: Digit 3|Default", 3, 1303)
2012-10-03 20:00:00.453125 [ProcessExternalChannel(12)]: TV3BlasterPlugin - BlastIR(): C:\Documents and Settings\All Users\Application Data\IR Server Suite\IR Commands\Digit 3.IR, Default
2012-10-03 20:00:00.781250 [GenericPCQueue(13)]: TV3BlasterPlugin: Received Message "BlastIR"
2012-10-03 20:00:00.781250 [GenericPCQueue(13)]: TV3BlasterPlugin: Blast successful
2012-10-03 20:00:01.156250 [ProcessExternalChannel(12)]: TV3BlasterPlugin: ProcessExternalCommand("Blast: Digit 0|Default", 0, 1303)
2012-10-03 20:00:01.156250 [ProcessExternalChannel(12)]: TV3BlasterPlugin - BlastIR(): C:\Documents and Settings\All Users\Application Data\IR Server Suite\IR Commands\Digit 0.IR, Default
2012-10-03 20:00:01.406250 [GenericPCQueue(13)]: TV3BlasterPlugin: Received Message "BlastIR"
2012-10-03 20:00:01.406250 [GenericPCQueue(13)]: TV3BlasterPlugin: Blast successful
2012-10-03 20:00:01.843750 [ProcessExternalChannel(12)]: TV3BlasterPlugin: ProcessExternalCommand("Blast: Digit 3|Default", 3, 1303)
2012-10-03 20:00:01.843750 [ProcessExternalChannel(12)]: TV3BlasterPlugin - BlastIR(): C:\Documents and Settings\All Users\Application Data\IR Server Suite\IR Commands\Digit 3.IR, Default
2012-10-03 20:00:02.328125 [GenericPCQueue(13)]: TV3BlasterPlugin: Received Message "BlastIR"
2012-10-03 20:00:02.328125 [GenericPCQueue(13)]: TV3BlasterPlugin: Blast successful [/collapse]
Pretty standard for a blaster: send each of the digits in the channel number to the STB.

A second or so later, the STB actually changes channel and TsWriter notices that the stream has changed. It notifies the TV Server:

[collapse]2012-10-03 20:00:02.390625 [(19)]: HDPVR: OnPMTReceived() subch:0 pid 0x100
2012-10-03 20:00:02.390625 [(19)]: HDPVR: PMT sid=0x1 pid=0x100 version=0x1
2012-10-03 20:00:02.390625 [(19)]: Decode pmt
2012-10-03 20:00:02.390625 [(19)]: subch:0 SetMpegPidMapping
2012-10-03 20:00:02.390625 [(19)]: subch:0 pid:1001 pcr
2012-10-03 20:00:02.390625 [(19)]: subch:0 pid:100 pmt
2012-10-03 20:00:02.390625 [(19)]: subch:0 pid:1011 video type:H.264
2012-10-03 20:00:02.390625 [(19)]: subch:0 map pid:1011 video type:H.264
2012-10-03 20:00:02.390625 [(19)]: subch:0 pid:1100 audio lang: type:AC3
2012-10-03 20:00:02.390625 [(19)]: subch:0 map pid:1100 audio lang: type:AC3
2012-10-03 20:00:02.390625 [(19)]: SetRecorderPids
2012-10-03 20:00:02.390625 [(19)]: PID seen - type = Audio
2012-10-03 20:00:02.406250 [(19)]: PID seen - type = Video [/collapse]
Note the change from AAC when the channel was originally "tuned" to AC3 audio, which is the actual audio type of the new channel.

The blaster is actually still doing its thing at this point.

[collapse][2012-10-03 20:00:02.546875 [ProcessExternalChannel(12)]: TV3BlasterPlugin: ProcessExternalCommand("Blast: Select|Default", -1, 1303)
2012-10-03 20:00:02.546875 [ProcessExternalChannel(12)]: TV3BlasterPlugin - BlastIR(): C:\Documents and Settings\All Users\Application Data\IR Server Suite\IR Commands\Select.IR, Default
2012-10-03 20:00:02.906250 [GenericPCQueue(13)]: TV3BlasterPlugin: Received Message "BlastIR"
2012-10-03 20:00:02.906250 [GenericPCQueue(13)]: TV3BlasterPlugin: Blast successful
2012-10-03 20:00:03.250000 [ProcessExternalChannel(12)]: TV3BlasterPlugin: ProcessExternalCommand("Blast: Select|Default", -1, 1303)
2012-10-03 20:00:03.250000 [ProcessExternalChannel(12)]: TV3BlasterPlugin - BlastIR(): C:\Documents and Settings\All Users\Application Data\IR Server Suite\IR Commands\Select.IR, Default
2012-10-03 20:00:03.484375 [GenericPCQueue(13)]: TV3BlasterPlugin: Received Message "BlastIR"
2012-10-03 20:00:03.484375 [GenericPCQueue(13)]: TV3BlasterPlugin: Blast successful[/collapse]

Finally the blaster completes. Note again that TV Server doesn't know that the blaster is done now. It is logged, and that is it.

...and that is tuning for you.

I'm with you that it would be perfect if TV Server could "sense" that the stream has changed and then, start recording but it may be complex as it may be deep into the code.

TV Server (well TsWriter actually) does sense that the stream changes. TsWriter notifies the TV Server when this happens if (and only if) the stream types or PIDs change. In this case, the audio stream type changed from AAC -> AC3, so TV Server got a notification. However if the audio stream type hadn't changed, TsWriter wouldn't have notified TV Server at all... and that is essentially the crux of the problem that prevents me from saying "I can do that for you easy peasy".

There are technical reasons why TsWriter ignores certain stream changes. In some places in the world, irrelevant stream changes occur every few seconds. If TsWriter notified TV Server about all of them it would cause disruptions in the stream - ie. stuttering.

Let me know if this is something you want to pursue. I'm willing to run a non-standard patch to see if it is helping. I assume that if it actually improve the way it work, this may end up in the software so it may not stay a non-standard patch

I could try to provide you and other HD-PVR and Colossus owners with a patch, but it would almost certainly never be included in our standard distribution because of the compatibility issues with broadcast TV in other countries mentioned above.

mm

 

[mm1352000]

Hello again

You can try this patch for MP 1.2.3. Please provide the tv.log and TsWriter.log regardless of whether it is successful or not.

mm

 

[ehfortin]

Hello,

Here are the logs. It just keep recognizing new PMT. No .TS was ever created until I stopped it, 5 minutes later. So, I guess you tried the fully automatic signal recognition, right?

ehfortin

[DOUBLEPOST=1349400397][/DOUBLEPOST]I have lost a few recording in the last few days because of unsync between the sound and the video. Today I recorded one movie and one episod of a serie and both where having about 1 second of delay. Yesterday I recorded a movie and everything was fine.

I'm always recording from the same source over the same SPDIF and component and on the same few station. My logs are included below. To test these file, I'm using WMP on my desktop. As some are perfectly fine (and all of those that I created in the past with a HD-PVR and SageTV are also perfectly normal), it seems that the suspects are the colossus board, the driver, TV Server or a combination of any of those.

Any known fix to this?

Thank you.

ehfortin

Edit: the 2012-10-03 logs are the one related to the audio problem. The other two are related to mm patch. Sorry but the system just keep merging my reply so... it is a 2 for 1 post.

 

[mm1352000]

Hello again ehfortin

Thanks for testing.
Yes, I tried to get clever, but obviously I wasn't quite clever/careful enough.

On a more positive note, I think I was wrong when I said it may not be possible to integrate this patch. Lets see how we go...

Obviously I need to provide you with a new patch. However, this first patch raises an interesting question. In the sequence of PMTs I see audio type changing as follows:
1. AC3
2. AAC
3. AC3
4. <consistently AC3>

So it looks like we may need to wait for the 3rd PMT to be sure that the STB has changed, not the 2nd as I had previously thought.

Do you agree, or do you think that I should still just go with the 2nd and treat other PMT changes as normal?

Waiting for the second PMT effectively added a delay of ~3.3 seconds.
Waiting for the third PMT will bump that delay up to ~4.5 seconds.

Alternatively, should I wait until the PMT version number is stable?
This would probably be the most fool-proof, but it would bump the delay up another second or so.

<Everyone else>
Do you like the idea of this modification?
Effectively what it would mean is cleaner channel changes. In other words, you wouldn't get the (1) enter ch# on the remote, (2) MP channel change completes, (3) channel actually changes sequence. However, channel changes might appear slightly slower.

mm

 

[ehfortin]

Hum, I know the recording was using AC3 so I'm not even sure why it switched to AAC from AC3 and then back. May this be the reason why my recording had nearly one second of delay between audio and video?

Just because it may be related, I would go with waiting for the third PMT for now and see how it react on numerous recordings on SD, HD, AAC and AC3 channels and see if it is constant, at least for my setup.

Thank you.

ehfortin

 

[mm1352000]

Hum, I know the recording was using AC3 so I'm not even sure why it switched to AAC from AC3 and then back. May this be the reason why my recording had nearly one second of delay between audio and video?

Do you mean a constant delay throughout the recording?

Just because it may be related, I would go with waiting for the third PMT for now and see how it react on numerous recordings on SD, HD, AAC and AC3 channels and see if it is constant, at least for my setup.

Okay. I have some other priorities to focus on this weekend but I'll do my best to provide you a patch this evening before I get too involved with other things.

 

[David Abineri]

I wonder if someone can help on the following questions concerning Colossus?

1. The chart showing the audio and video settings refers to pin0, pin1,pin 2 etc. To what do these pins refer?

2. I received a remote (43 buttons) and a blaster with my Colossus but no USB IR device. Do I need a USB IR input in order to control MP or can I do it with what I have? Where does one get an appropriate IR USB input device if I do need one?

Thanks for any help or for apush in the right direction, perhaps this is discussed somewhere already but I have not found it. Dave

 

[mm1352000]

1. The chart showing the audio and video settings refers to pin0, pin1,pin 2 etc. To what do these pins refer?

Format = <pin #> <input type> <label in MP TV Server configuration and the SchedulesDirect plugin> <description of the physical connector>

You can ignore the pin numbers - they're only really relevant from a development perspective or unless you wanted to do something really advanced.
The relevant things are the <label...> and the <description...>. This is for when you know you've connected your video source to certain physical inputs but you need to know which video/audio source to select in TV Server configuration and/or SD when setting up your channels.

In other words, say you connect the Colossus to an STB via HDMI. You look at the description column in the table and see "HDMI #1 = HDMI video" and "SPDIF In #1 = HDMI audio". This means you should select HDMI #1 and SPDIF In #1 when configuring your channels.

2. I received a remote (43 buttons) and a blaster with my Colossus but no USB IR device. Do I need a USB IR input in order to control MP or can I do it with what I have? Where does one get an appropriate IR USB input device if I do need one?

It would seem unusual for Hauppauge to supply a remote without a receiver for the remote. Are you sure about that?
If the blaster looks like this:
http://store.hauppauge.com/images/ir_learn_blast_l.jpg
... then the receiver is the black round end and the blaster is the other beige end.
You might be able to buy an alternate receiver but I have no information about that. Take care as receivers can operate on different frequencies.

mm