Problems with Summer Release (2 Viewers)

[Meier]

Hmm, this is indeed a new issue. It comes from running "ClientLauncher.exe" after setup, but it should happen only for the Client part. Unfortunately it seems to happen also for server-only installs, where it is missing.
Edit: Reference for commit: https://github.com/MediaPortal/MediaPortal-2/commit/9eeb22ce343ee6fd4fe7403a2de8a9254e2ae336. Although it's defined inside client.wxs, it applies to all setup types

This can only be fixed by a new installer. You can in meantime do a full install including Client.

Well - is anything else not configured because this fails or is it only messy to see?

And do you have an idea why the Metadata Import Fails?

 

[morpheus_xx]

Well - is anything else not configured because this fails or is it only messy to see?

Keeps the MP2-Server being installed, or is it rolled back? If it is kept installed, nothing to be worry about, as this action is a "post successful install" action.

And do you have an idea why the Metadata Import Fails?

Do you mean the online scraping? No idea yet.

 

[Meier]

Well - is anything else not configured because this fails or is it only messy to see?

Keeps the MP2-Server being installed, or is it rolled back? If it is kept installed, nothing to be worry about, as this action is a "post successful install" action.

And do you have an idea why the Metadata Import Fails?

Do you mean the online scraping? No idea yet.

It keeps installed - except the mentioned erros
Yeah I mean the online scrapping - only the mentioned error occurs.

 

[morpheus_xx]

Good news, installer conditions are fixed now! I've added missing checks for both ServiceMonitor and ClientLauncher.

@Meier thanks for reporting!

 

[azzuro]

for information

 

[morpheus_xx]

2. A stop of the MP2 is still extremly slow. I disabled IPv6 on the whole Server and also created the MediaPortal.Common.Services.ResourceAccess.Settings.ServerSettings with IPv6 disabled. In the log I can see the following entries (MP2-Service-stop):
[2015-07-11 17:48:57,206] [1002592] [570 ] [ERROR] - Error: SSDPServerController.OnExpirationTimerElapsed: Cannot acquire synchronization lock. Maybe a deadlock happened.

As followup to this issue: there is an internal thread about this topic: https://forum.team-mediaportal.com/...k-maybe-a-deadlock.123787/page-3#post-1094518

Adding IP filtering to MP2 server reduced the lock ups but they still happened on my machine. I haven't found the root cause, I just disabled VPN.

Well hmmm...

The logs in the other thread seem to only show the message after TVE attempts to call SSDPClientController.Close(), whereas the logs in this thread seem to show the message while MP2 Server should be running and the SSDP controller still active. In short: I suspect the existence of two distinct causes or scenarios. TVE's Close() issue is probably much easier to resolve.

Looking at the Close() function:
https://github.com/MediaPortal/Medi...tructure/CP/SSDP/SSDPClientController.cs#L350

...it seems odd to me is that _isActive = false and the socket = null loop aren't all within the same lock. Surely an atomic/locked shutdown would be cleaner/better? The assumption seems to be that if Close() acquires the lock and is able to set _isActive false then the Receive() handling will "die" without any major problem and we should be okay to close the sockets... but I'm not so sure about that assumption.

Looking at the Receive() functions:
https://github.com/MediaPortal/Medi...tructure/CP/SSDP/SSDPClientController.cs#L111
https://github.com/MediaPortal/Medi...tructure/CP/SSDP/SSDPClientController.cs#L149

Obviously they only acquire the lock for checking _isActive and then release it immediately. Crucially: there is no locking around the socket access that happens later (eg. socket.EndReceiveFrom()).

Consider the following sequence with two threads.
1. Thread A: Receive() invoked, lock acquired, _isActive is true so processing will continue. Lock released.
2. Thread B: Close() invoked, lock acquired, _isActive is set false. Lock released.
3. Thread A: The if (socket == null) check is passed before Thread B sets the shared socket reference to null. Local socket reference acquired (so Thread B setting socket to null will not have immediate effect).
4. Thread B: Lock acquired, local socket reference acquired, shared socket reference set null. Lock released.
5. Thread A: EndReceiveFrom() invoked on local socket reference.
6. Thread B: Close() invoked on local socket reference either directly or within NetworkHelper.DisposeSSDPMulticastSocket().

What happens?
I don't know for sure, but it might not be good.
If EndReceiveFrom() unblocks on Close() and an exception is thrown in Thread A everything would be fine I think (the exception would be caught and Receive() would return).
However, if Close() waits for EndReceiveFrom() to receive and return but EndReceiveFrom() never does actually receive or time out... that could be our lovely deadlock. Close() blocks TVE forever.

It interests me to see that there is an optional timeout parameter on socket.Close() which we currently do not use.

I suspect there could potentially be other issues lurking in the Receive() processing too, simply due to the fact that _isActive is only checked at the start of Receive() and not anywhere within the processing (and Close() does not close atomically within the lock).

Plausible?
Garbage?

It means the issue is known, but not easy to fix...

 

[Meier]

Thanks for the Information - I didn't know that
But good to know that you are working on the Problem