initial support for Hauppuage HD-PVR (1 Viewer)

[WileECoyote]

I had no succcess as well with AC3 filter. The only thing I know is that it's timeshift related. Playing back a recording has no issues at all.
It's like the TS hit's the end of the stream. I might try a different patch where we would do 2 things: never stop the timeshift and only start playback after 'x' amount of seconds.
In theory this would help but I have a feeling that after many channel changes that the playback would once again hit the end of the timeshift.

I'll try and add to your new post to give the devs more info but I might not get the chance to do it right away as I'm in a real crunch with work.

Garry, stop me if I am way off here, but something I was experimenting with over the weekend was the audio type methods. If you notice, the audio type is always returned null "return null;". I was looking at other cards and noticed that the actual audio type is sensed and returned (DD, Stereo, etc...) Im wondering if the proper audio type was returned, if MP would be able to better handle the channel change?

what's a comskip?

You enable comskip in the TV Server to gather commercial information on recordings, so you can skip them later when you are watching the recording. If you are not aware of what it is, you probably have not enabled it...

 

[antonehenry]

also, if I enter a channel, say 402, it only lets me get to 40 before it decides that's all the numbers it will take.

 

[sjeffrey]

Comskip is a tool that marks commercials in recordings then mediaportal can automatically skip them.
You'll need to donate to the project to get the h264 version.
It's great because you can setup so that comskip runs automatically after each recording.
It's not 100% accurate but it's pretty good.

also, if I enter a channel, say 402, it only lets me get to 40 before it decides that's all the numbers it will take.

It took me a while to figure this one out. Go in MP config, in TV client I think, uncheck the user index number.
I dont remember by heart, but you should be able to find it. If not, I'll check when I get home...

 

[PABeaver]

-Any way to speed up the IRSS+TV3 Changer+Timmmoore firewire channel change?

In the TV3 plugin you can change the delay between the numbers it sends. You can lower the value to the lowest value your set top box will accept. I am at work, so I can post more detail tonight if you need it.

also, if I enter a channel, say 402, it only lets me get to 40 before it decides that's all the numbers it will take.

The above might solve this problem too, but I think I need more information. Does the MP client accept all three numbers and the STB does not? Or is it that the MP client is not taking all three numbers?

It could be that your thumb isn't quick enough

 

[PABeaver]

-Any way to speed up the IRSS+TV3 Changer+Timmmoore firewire channel change?

In the TV3 plugin you can change the delay between the numbers it sends. You can lower the value to the lowest value your set top box will accept. I am at work, so I can post more detail tonight if you need it.

Ok, I found the area to change.

Go into the TV server config.
From there click in to the TV3 Blaster Plug-in for IRSS
Click the STB Setup button
Make sure you are on the correct tab for your TV card (for me it is the first tab).
In the Options box, the first option is ms Wait Between Digits.
Lower this value as much as you want, but make sure not to go too low or your cable box may not register the digits. I went down to 400 and my cable box works fine, but I did not try anything lower. You can experiment for yourself.

 

[ixian]

Garry, stop me if I am way off here, but something I was experimenting with over the weekend was the audio type methods. If you notice, the audio type is always returned null "return null;". I was looking at other cards and noticed that the actual audio type is sensed and returned (DD, Stereo, etc...) Im wondering if the proper audio type was returned, if MP would be able to better handle the channel change?

Now this is interesting. I took a look at the code and saw this:

#region audio streams

    /// <summary>
    /// returns the list of available audio streams
    /// </summary>
    public override List<IAudioStream> AvailableAudioStreams
    {
      get
      {
        return null;
      }
    }

    /// <summary>
    /// get/set the current selected audio stream
    /// </summary>
    public override IAudioStream CurrentAudioStream
    {
      get
      {
        return null;
      }
      set
      {
      }
    }

The above is in HDPVRChannel.cs.

I looked at the crossbar code (TVCardHDPVR.cs) and it doesn't appear to be asking the card for the audio type when it creates the AudioPinMap when building the graph. In other words, the type of audio stream is never defined, and so naturally it will always return null.

Now like you say, whether this has anything to do with the jitter issues in MePo I don't know, but in looking at other devices I was struck, as you were, by the fact that they do return an audio type.

Take this snippet from HDPVRChannels.cs:

/// <summary>
    /// Should be called when the graph is tuned to the new channel
    /// resets the state
    /// </summary>
    public override void OnAfterTune()
    {
      Log.Log.WriteFile("HDPVR: subch:{0} OnAfterTune", _subChannelId);
      if (IsTimeShifting && _subChannelId >= 0)
      {
        _tsFilterInterface.TimeShiftPause(_subChannelId, 0);

        //hack
        OnNotify(PidType.Audio);
        OnNotify(PidType.Video);
      }
    }

What I'm wondering is if there's no real type that can be called; as far as I am aware the HDPVR is the only capture device supported by MePo that has DD/TOSLink capture support - if I'm wrong let me know one that does so I can look at it's code.

We may be on to something here. It could be something as simple as the codec/post processing not knowing what to do but if that were the case then recordings should have a problem too - since this is only timeshift related on channel change, I think the snippet above may have something to do with it. I'm not a good enough coder to troubleshoot it all the way but maybe we can get the attention of someone who is?

 

[sjeffrey]

I think you are right about being the only capture card that supports TOSLink as far as an analog capture card. We could look at code from internal cards and see what they do.
I'm not sure this is the right way to go though. One question is, if the stream audio is only stereo would the same graph be built then a stream with AC3/6 channels? Unless stereo means AC3/2channels, which would then be the same graph. To further prove my theory about the PVR hitting the end of stream on the timeshift buffer, we could make a patch to log timestamps on each packet and see what's going on when it stutters. The main reason why I'm convinced this is the case is because playback of recordings or pausing for a few seconds fixes the issue. I also noticed that it's NOT just channel changes. When you hit commercials and switch from 5.1 to 2 then you'll see the blue led flicker and MP starts to stutter.

If anyone knows how it behaves in Sage or MythTV (is it even supported?) then it would be interesting to know if they have the same issues. If they do, then it would point us to the actual HW or drivers.

 

[ixian]

Live Studdering/slow video after channel change with HDPVR - SageTV Community

Seems somewhat similar problem - but it points to a software error on Sages part, not a driver issue. For whatever it's worth if you watch Live TV with the TMT software the HDPVR ships with you can change channels all day without a skip or judder in sight, even while recording.

The Sage forum seems to suggest that a slight buffer helps as well, so you may well be right, it's a problem when it hits the end of the stream with the timeshift buffer. How to fix that is a better question

 

[sjeffrey]

Well this is good, this means there should something we can do.
I bet TMT has some buffer time as well because I vaguely remember that there was a noticeable delay between actual live TV and the playback in TMT.
It sounds like what Sage is doing is pretty much like the patch I tried before, add 3-4 second delay after channel change...

Just do what I do, never watch live TV! Commercials are evil and a waste of time

 

[antonehenry]

Something weird just happened. We had to move the tv/computer/hdpvr/stb. TV was on, playing live TV, froze. I restarted everything multiple times now, but in MP I only get audio and no video. Very weird. It works just dandy in TME. I'm not excited for another MP reinstall. Any ideas?

Did a light reinstall (standard/recommended uninstall) and no luck. This sucks.