1.11.0 No connection could be made because the target machine actively refused it (1 Viewer)

[Snoopy87]

How do I get this list and those states?[DOUBLEPOST=1431335813][/DOUBLEPOST]This?

 

[MrTechno]

There's System.Diagnostics.Process.GetCurrentProcess().Threads but I assume if the exit is called from unmanaged code this won't contain anything useful

 

[mm1352000]

Ahhhh!
Just looking at the list of threads there gave me some clues.
Most of those threads seem to be managed, and we already know that there is no Environment.Exit(1) on the C# side... but what about the C++ side.
In particular, what about here?
https://github.com/MediaPortal/Medi...wFilters/StreamingServer/Source/main.cpp#L137

There are other calls to exit(1) scattered through the live555 code too. So, I'm wondering if it is the streaming server that is bringing down the service.

 

[mm1352000]

https://github.com/MediaPortal/Medi...sageEnvironment/BasicUsageEnvironment.cpp#L35
https://github.com/MediaPortal/Medi...s/LiveMedia555/liveMedia/FramedSource.cpp#L65
https://github.com/MediaPortal/Medi...s/LiveMedia555/liveMedia/StreamParser.cpp#L82
https://github.com/MediaPortal/Medi...dia555/liveMedia/QCELPAudioRTPSource.cpp#L405
https://github.com/MediaPortal/Medi...Media555/liveMedia/AMRAudioRTPSource.cpp#L546
https://github.com/MediaPortal/Medi...LiveMedia555/liveMedia/MPEG1or2Demux.cpp#L165

I guess the next step is to try to find out which of these is the source (...and there may be other possible sources too).
I would either change the exit codes to unique values, or add OutputDebugString()... something to allow me to see which exit() is the problem...
...then recompile the streaming server, reproduce the problem, and see if you can find the source.

 

[Snoopy87]

It's sooooo strange...

I changed all "exit(1)" with different numbers: 100, 101, 102, etc. Now I always get Exit Code 255 (0xFF)! This makes no sense, because 255 is not used :-(

 

[mm1352000]

Did you use any negative values?

Perhaps try to change them back one-by-one until the exit code changes back to 1.

 

[Snoopy87]

I changed ALL back to exit(1) and still get 255... I have no c++ skills, because I am a C# developer. Maybe it's a general issue of my compiled versions? Maybe due to a newer Visual Studio versions and/or C++ Runtimes?

Could someone of you create a debug version of StreamingServer.dll which includes different exit codes and/or debug output and post this version here, so that I can use this DLL for further testings?

 

[mm1352000]

I changed ALL back to exit(1) and still get 255...

If you put the original StreamingServer.dll back, does the error code change back to 1?

Are you sure you copied the compiled DLL to the correct location etc.?
If I were you, I would add a log entry here:
https://github.com/MediaPortal/Medi...wFilters/StreamingServer/Source/main.cpp#L143

...so that you can be sure that the DLL that you compiled is actually being used.

Also, did you get the same exit code (value = 1) consistently in previous tests? ...and is the exit code consistently 255 now?
I ask this because if the value has changed due to the change of StreamingServer.dll, at least we can say that we are "on the right track" to finding the cause.

Maybe it's a general issue of my compiled versions? Maybe due to a newer Visual Studio versions and/or C++ Runtimes?

Sorry, I think this is very unlikely.

Could someone of you create a debug version of StreamingServer.dll which includes different exit codes and/or debug output and post this version here, so that I can use this DLL for further testings?

Sorry, I can't compile the latest MediaPortal code anymore. Projects have been converted to VS 2013, but I still use XP (which can't run VS 2013). Hopefully somebody else can do this for you.

 

[Snoopy87]

YEEEEEEEEEEEEES! I GOT IT!

Instead of compiling the debug version of StreamingServer I compiled the Release version and now it works!

FramedSource.cpp of LiveMedia555

void FramedSource::getNextFrame(unsigned char* to, unsigned maxSize,
                afterGettingFunc* afterGettingFunc,
                void* afterGettingClientData,
                onCloseFunc* onCloseFunc,
                void* onCloseClientData) {
  // Make sure we're not already being read:
  if (fIsCurrentlyAwaitingData) {
    envir() << "FramedSource[" << this << "]::getNextFrame(): attempting to read more than once at the same time!\n";
    exit(5); // <--- Sascha: HERE IT IS EXITING! :-)
  }

  fTo = to;
  fMaxSize = maxSize;
  fNumTruncatedBytes = 0; // by default; could be changed by doGetNextFrame()
  fDurationInMicroseconds = 0; // by default; could be changed by doGetNextFrame()
  fAfterGettingFunc = afterGettingFunc;
  fAfterGettingClientData = afterGettingClientData;
  fOnCloseFunc = onCloseFunc;
  fOnCloseClientData = onCloseClientData;
  fIsCurrentlyAwaitingData = True;

  doGetNextFrame();
}

 

[mm1352000]

That's great news!

So, the next step is to try to understand why the error is occurring, and solve it if possible.

I've been looking at this for the last half hour, but not getting far. This is 3rd party code (live555) with lots of "spaghetti" (inheritance etc.).

I should also point out that this version of the code is now more than 5 years old. The latest code may behave differently... but upgrading for TVE 3 is probably out of the question due to the risk of breaking analog tuner support, the IPTV filter, and the streaming server (all use this library).