Hauppauge HD-PVR & Colossus Support (1 Viewer)

[WileECoyote]

Hi again

I figured that could be a problem, and it has been an awkward one to work around. Please could you try this build...

Much closer... it tunes the first channel, but when it trys the second it gets a no PMT.

Logs attached...

Hmm, okay. I'll have to take a look at that this evening (6 hours) because I'm at work now. I'd also like to know why a retune is done - technically it shouldn't be necessary with the HDPVR...

mm

Okay, no worries.

Thats actually a great point! There is NO need to retune, just blast to the STB the new channel. Can that be done?

 

[mm1352000]

Okay, no worries.

Thats actually a great point! There is NO need to retune, just blast to the STB the new channel. Can that be done?

I think the issue there is the IsSameTransponder() code (or something like it). The evidence for that is in the logs:

2011-04-12 19:21:25.606445 [(10)]: card: to different transponder

Without having looked at that code in particular I think that the reason a retune is being forced right now is that each of your channels has a different channel number. I'm not sure whether we can cleanly modify the AnalogChannel class to avoid that behaviour. We'd have to be careful that we don't break switching between channels on different physical inputs too... not that I'd imagine too many people would be doing that, but still...

I'll look into that this evening as well.

 

[WileECoyote]

Yea, I noticed you pulled most of the Start() and Stop() methods out of the HDPVRChannel class and use the methods in the inherited class TvDvbChannel. Will that limit what you can do?

Have a good day at work, Im headed to bed soon

Thanks again!
Wile E.

 

[mm1352000]

Yea, I noticed you pulled most of the Start() and Stop() methods out of the HDPVRChannel class and use the methods in the inherited class TvDvbChannel. Will that limit what you can do?

No it won't limit us for the IsSameTransponder() thing - that relates to the TVCardHDPVR class and its use of the AnalogChannel class. I don't think it will limit us too much for other things either. The way I see it, the HDPVR is like an analog tuner that tunes DVB channels. There are *major* code overlaps with the analog tuner and DVB subchannel code that can be taken advantage of.

From a maintenance standpoint, reusing as much of the TvDvbChannel code makes perfect sense. Almost all the development and testing effort for hardware is focussed on DVB tuners because those are the tuners that we as developers own, and because most MP users use DVB tuners too. The whole reason the HDPVR support was broken in the first place is that someone made some major changes to the DVB and general code and either wasn't able or didn't bother to check the analog, hybrid, and HDPVR code. If the HDPVR was already reusing code then I think it would have been far less likely to happen.

The loss of flexibility is definitely a downside to code reuse. Combining analog tuner code with DVB subchannel code can also be awkward (as I've already proved). If the HDPVR subchannel code was more different then I don't think I'd have done what I've done, but actually it was almost identical apart from the conditional access support and the fixed service ID and PMT PID. Those haven't been hard to work around, and in my opinion the benefits from code reuse will outweigh the drawbacks over time...

 

[elconejito]

Just thought I'd throw in my $0.02... I was one of those that downloaded SVN 27557 but I just got a chance to test it today. I had to go through downloading and installing all the software from the wiki page first. So far, in a few quick tests it seems to work OK. I have 2 Avermedia combo cards which each have an ATSC/QAM & NTSC tuner so I can record 2 QAM channels and 2 channels via S-Video from my STBs (up to 4 channels at a time). So I hooked up the Colossus to one of the STBs and managed to tune a few channels and record one channel and so far so good. I have to see if anything else broke (IRSS for remote is one) updating to this SVN from 1.1RC3 which is what I was one before. As long as things work reasonably well I'll leave this SVN on here for awhile. If things go awry I'll restore the image I took right before this experiment

I would have tried the newer SVN but I think that's just too much for me for one night

If you guys need any guinea pigs to test stuff just let me know. In the meantime I'll continue to test and let you know if I find anything that hasn't already been brought up.

 

[mm1352000]

wilee

Okay, I think this build should work.
Regarding the retuning: my guess was correct. The issue is that the channel number is different, which makes TV Server think that it is a different channel. It seems that analog tuners use the channel number as an alternative to specifying a frequency (ie. the channel number is a frequency band number). For that reason it is not going to be possible to take the channel number out of AnalogChannel.IsDifferentTransponder() check. As an alternative you could try setting some of your channel numbers to a single number and see what happens. Obviously that isn't going to be possible if you blast based on the channel number though - maybe you could blast based on channel index (which is what I do).

 

[WileECoyote]

@WileE

Okay, I think this build should work.
Regarding the retuning: my guess was correct. The issue is that the channel number is different, which makes TV Server think that it is a different channel. It seems that analog tuners use the channel number as an alternative to specifying a frequency (ie. the channel number is a frequency band number). For that reason it is not going to be possible to take the channel number out of AnalogChannel.IsDifferentTransponder() check. As an alternative you could try setting some of your channel numbers to a single number and see what happens. Obviously that isn't going to be possible if you blast based on the channel number though - maybe you could blast based on channel index (which is what I do).

Cool, I will try it when I get home tonight and let you know (I just got to work.)

As long as it works and the blast times are short, it should be okay. Right now my main focus is trying to get support for the HD-PVR & Colossus in the 1.2 Beta build All the other changes we can attempt later on...

Thanks!
Wile E.

 

[mm1352000]

Cool, I will try it when I get home tonight and let you know (I just got to work.)

As long as it works and the blast times are short, it should be okay. Right now my main focus is trying to get support for the HD-PVR & Colossus in the 1.2 Beta build All the other changes we can attempt later on...

Thanks!
Wile E.

Sounds fine to me.
Just out of interest: how different is the support code for the Colossus? I've had a good look at the patch and the code looks identical to the HDPVR. Of course we'd need to add the code in DetectDevices(), but aside from that... ???

 

[WileECoyote]

Sounds fine to me.
Just out of interest: how different is the support code for the Colossus? I've had a good look at the patch and the code looks identical to the HDPVR. Of course we'd need to add the code in DetectDevices(), but aside from that... ???

To be honest there are only 4 lines that are different...

In the ColossusChannel Class
private const int Colossus_PMT_PID = 0x20;

In the TVCardColossus Class
private const string _captureDeviceName = "Hauppauge Colossus Capture 0";
private const string _encoderDeviceName = "Hauppauge Colossus TS Encoder 0";
private const string _crossbarDeviceName = "Hauppauge Colossus Crossbar 0";

I have attached the latest patch, based on your latest patch files.

Maybe we can add a parameter to the constructor to differenciate between the two cards, that way we can use one class for both? I agree on your reuse of code, it seems a shame to have to create a whole new class for the Colossus...

Thanks,
Wile E.

Edit: The changes above would be needed plus the addition to the DetectCards() method of course...

 

[WileECoyote]

@WileE

Okay, I think this build should work.
Regarding the retuning: my guess was correct. The issue is that the channel number is different, which makes TV Server think that it is a different channel. It seems that analog tuners use the channel number as an alternative to specifying a frequency (ie. the channel number is a frequency band number). For that reason it is not going to be possible to take the channel number out of AnalogChannel.IsDifferentTransponder() check. As an alternative you could try setting some of your channel numbers to a single number and see what happens. Obviously that isn't going to be possible if you blast based on the channel number though - maybe you could blast based on channel index (which is what I do).

Getting closer, now it cant see audio-video after 15 seconds

Logs attached...

Thanks!
Wile E.