Reply to thread

Message

<blockquote data-quote="ixian" data-source="post: 513974" data-attributes="member: 54932">Now this is interesting. I took a look at the code and saw this:[code]#region audio streams&nbsp; &nbsp; /// &lt;summary&gt;&nbsp; &nbsp; /// returns the list of available audio streams&nbsp; &nbsp; /// &lt;/summary&gt;&nbsp; &nbsp; public override List&lt;IAudioStream&gt; AvailableAudioStreams&nbsp; &nbsp; {&nbsp; &nbsp; &nbsp; get&nbsp; &nbsp; &nbsp; {&nbsp; &nbsp; &nbsp; &nbsp; return null;&nbsp; &nbsp; &nbsp; }&nbsp; &nbsp; }&nbsp; &nbsp; /// &lt;summary&gt;&nbsp; &nbsp; /// get/set the current selected audio stream&nbsp; &nbsp; /// &lt;/summary&gt;&nbsp; &nbsp; public override IAudioStream CurrentAudioStream&nbsp; &nbsp; {&nbsp; &nbsp; &nbsp; get&nbsp; &nbsp; &nbsp; {&nbsp; &nbsp; &nbsp; &nbsp; return null;&nbsp; &nbsp; &nbsp; }&nbsp; &nbsp; &nbsp; set&nbsp; &nbsp; &nbsp; {&nbsp; &nbsp; &nbsp; }&nbsp; &nbsp; }[/code]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:[code]/// &lt;summary&gt;&nbsp; &nbsp; /// Should be called when the graph is tuned to the new channel&nbsp; &nbsp; /// resets the state&nbsp; &nbsp; /// &lt;/summary&gt;&nbsp; &nbsp; public override void OnAfterTune()&nbsp; &nbsp; {&nbsp; &nbsp; &nbsp; Log.Log.WriteFile(&quot;HDPVR: subch:{0} OnAfterTune&quot;, _subChannelId);&nbsp; &nbsp; &nbsp; if (IsTimeShifting &amp;&amp; _subChannelId &gt;= 0)&nbsp; &nbsp; &nbsp; {&nbsp; &nbsp; &nbsp; &nbsp; _tsFilterInterface.TimeShiftPause(_subChannelId, 0);&nbsp; &nbsp; &nbsp; &nbsp; //hack&nbsp; &nbsp; &nbsp; &nbsp; OnNotify(PidType.Audio);&nbsp; &nbsp; &nbsp; &nbsp; OnNotify(PidType.Video);&nbsp; &nbsp; &nbsp; }&nbsp; &nbsp; }[/code]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?</blockquote>

[QUOTE="ixian, post: 513974, member: 54932"] Now this is interesting. I took a look at the code and saw this: [code] #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 { } } [/code] 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: [code] /// <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); } } [/code] 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? [/QUOTE]

Verification