Hello

I'm writing a program for Satelco EasyWatch DVB-T card, that acts as a remote tuner (e.g parses commands from other programs, tunes itself, gets PIDs, and recdeives packets etc.). This program is mostly based on BDASample but I added one filter (that is based on CBaseFilter and CBaseFilterInputPin) more to the graph in order to 'catch' packets from Demux to my buffer.
Under VS. NET 2003 programs seems to work OK, but after several channel changes I've a crash in mpg2splt.ax or in ntdll.dll
If I start this program as standalone (without VS. NET debugger) I've a crash very quickly, but in this case it is in psisdecd.dll
I've no idea how to debug the program because crashes are in DLLs so I've no source code. I've already checked memory leaks and heap corruptions with MemoryValidator but it didn't find anything incorrect.
Any ideas? Thank in advance for your help.

Best regards
Chrosciu

Are you saying that the crash only happens when your custom filter is connected? Changing channel works fine otherwise?

Which pin of the demux are you connecting your filter to?

Thanks for reply. When I disconnect my filter, there is no crash. But I couldn't mean

anything, because without my filter my program receives no data from cable and in that case

doesn't control the filter (e.g. doesn't request playing or stopping PIDs)

I'm connecting my filter pin to an extra created pin of Demux (by CreateOutputPin

function)

Furthermore I have something new - I've downloaded symbols for system DLLs and filters so I

can present CallStack at the time of crash. It looks like that :

> 00000001()
mpg2splt.ax!CBufferSourceManager::CompleteCopyBuffer_()
mpg2splt.ax!CBufferSourceManager::Complete()
mpg2splt.ax!CStreamParser::Timeout()
mpg2splt.ax!CBaseParser::CheckTimeout()
mpg2splt.ax!CStreamMapper::CheckForTimeouts_()
mpg2splt.ax!CTransportStreamMapper::Process()
mpg2splt.ax!CMPEG2Controller::ProcessMediaSampleLocked()
mpg2splt.ax!CMPEG2Demultiplexer::ProcessMediaSampleLocked()
mpg2splt.ax!CMPEG2DemuxInputPin::Receive()
ksproxy.ax!CKsOutputPin::Deliver()
ksproxy.ax!CKsOutputPin::KsDeliver()
ksproxy.ax!CStandardInterfaceHandler::KsCompleteIo()
ksproxy.ax!CKsOutputPin::OutputPinBufferHandler()
ksproxy.ax!CAsyncItemHandler::AsyncItemProc()
kernel32.dll!_BaseThreadStart@8()

But I still have no idea what it could mean these function calls... :-(

I think the problem is that the network provider doesn't like it if pins on the demux that it's controlling get added, removed, or changed. I spent a fair amount of time trying to figure out how to safely add and remove pins from the demux but could never get it working.

The way i get around the problem is to insert an infinite pin tee filter before the demux filter and then connect a second demux filter. That way the Network Provider can do it's thing with the first demux and i'm free to configure the second demux to do what i need.

I'll try this way. Thanks for your advice.

[quote=chrosciu,Apr 12 2005, 02:22 PM]
[quote=nate,Apr 12 2005, 01:56 PM]I think the problem is that the network provider doesn't like it if pins on the demux that it's controlling get added, removed, or changed. I spent a fair amount of time trying to figure out how to safely add and remove pins from the demux but could never get it working.

The way i get around the problem is to insert an infinite pin tee filter before the demux filter and then connect a second demux filter. That way the Network Provider can do it's thing with the first demux and i'm free to configure the second demux to do what i need.

[/quote]



I tried to apply your advice but I gave up. It was unable to create infinite pin tee filter, because this construction :

CComPtr <IBaseFilter> m_pInfPinTeeFilter;

CoCreateInstance(CLSID_LegacyAmFilter, NULL, CLSCTX_INPROC_SERVER,IID_IBaseFilter, reinterpret_cast<void**>(&m_pInfPinTeeFilter));

assigned NULL over and over again to m_pInfPinTeeFilter. What am I doing wrong? Maybe the pin tee filter is not registered in my system? What should I do to register it if so?

I'm very sorry for that 'stupid'questions but I'm almost totally green in building filters, so thanks for your patience...

Grab the DigitalWatch 0.724 source from here and take a look in the DVBSourceBDA.cpp file.

RTFM Although admittedly it's not particularly intuitive

reinterpret_cast<void**>(&m_pInfPinTeeFilter.p)

or move completely over to the dark side CComPtr::CoCreateInstance()

Actually i'm not entirely sure that's necessary. I'm not at home so i can't check, but i'm pretty sure i use reinterpret_cast<void**>(&m_pInfPinTeeFilter) without a problem.

I think the problem is he's using CLSID_LegacyAmFilter instead of CLSID_InfTee

oops missed that one

[quote=chrosciu,Apr 12 2005, 02:22 PM]
[quote=nate,Apr 12 2005, 01:56 PM]I think the problem is that the network provider doesn't like it if pins on the demux that it's controlling get added, removed, or changed. I spent a fair amount of time trying to figure out how to safely add and remove pins from the demux but could never get it working.

The way i get around the problem is to insert an infinite pin tee filter before the demux filter and then connect a second demux filter. That way the Network Provider can do it's thing with the first demux and i'm free to configure the second demux to do what i need.

[/quote]


At last I successfully connected the InfTeePinFilter to my graph but this didn't work ... :-((( The crash is in the same place as it was.
Do you have any other ideas ?

The schema of the graph is now as follows :

Network Provider -> Tuner Device -> InfTee -> Demux -> TIF

and from InfTee is the second branch:

InfTee -> myDemux -> my Filter (CBaseFilter)

chrosciu,



Can you indicate what pin you are connecting to, if created, what is the pin type etc, and what data is flowing on the pin. This would help to identify a lot of possible problems, eg. You are not properly releasing an interface with the demux or its output pins or you are releasing a pin that the demux is still using.

Just a guess, but make sure you release the samples that your input pin is receives, and make sure that the Recieve method doesn't take too long. The stack track you provided indicates it might be a timeout issue.