TVServer connection status (3 Viewers)

[Stéphane Lenclud]

You seem to be assuming that some other process will always be running to ensure that _isRemotingConnected has the correct/true value. IMO that assumption is not necessarily correct.

Well since MiniDisplay runs in its own thread beside the rest of MP and the TVPlugin which is indeed connecting to our server through RemoteControl the assumption that some other component than MiniDisplay is indeed trying to connect to our server is true.

However am not assuming anything there. I'm just checking the server connection status without attempting to connect cause that's all I need. MiniDisplay does not need to initiate a server connection.

 

[Stéphane Lenclud]

That is why I think you should use RemoteControl.Instance.* (like the TV plugin, MP configuration etc.) if you actually need to get information from the server.

I was under the impression that RemoteControl is designed for a single client. So using it from two threads could indeed turn badly. But if it was designed for multiple clients I should indeed be using it and get connections notifications rather than pulling the connection status.

Though I'm not sure that adding a dependency on TvControl in MiniDisplay fits our current architecture. Thus the dynamic loading of TvControl implemented in MiniDisplay.

 

[Stéphane Lenclud]

If the server is not present then yes you will have the timeout delay... but if you're worried about timeouts, simply don't make the call from threads that you don't want to be blocked. Minidisplay should have its own background thread for updating the recording and timeshifting status. It should definitely not do it in the UI thread, because that would block rendering the MP UI (!!!).

You are correct using a dedicated thread for pulling information from our TV server would fix our MiniDisplay lag issue without the need to modify TVLibrary.
However we would still be using those single client API from two different threads which is definitely unsafe.

Does TVE 3.5 comes with a proper multi client API?

 

[mm1352000]

Because as you said it's an API designed for a single client so bad things could happen.

Every other plugin does this. I'm not saying it is a good thing and completely safe. Just that it works.

 

[mm1352000]

Well since MiniDisplay runs in its own thread beside the rest of MP and the TVPlugin which is indeed connecting to our server through RemoteControl the assumption that some other component than MiniDisplay is indeed trying to connect to our server is true.

Sorry I respectfully disagree. The TV plugin is not actively communicating with the server all the time. It is only actively communicating with the server when people use functions. If people are using the music, pictures, videos or other plugin... what then? Are you sure that the variable you want to access is updated in the background? I'm not.

However am not assuming anything there. I'm just checking the server connection status without attempting to connect cause that's all I need. MiniDisplay does not need to initiate a server connection.

Again I disagree. What is the point of checking the server connection status unless you want to get information from the server?
You already said that MD wants the current recording and timeshifting status from the server. For that you do need a server connection. IMO it is irrelevant whether MD initiates the connection or not.

In other words, it seems like you're telling me you want to write code like this:

while (true)
{
  if (serverConnected)
  {
    // request information from the server
  }
  else
  {
    // do nothing, sleep a little while
  }
}

This is not the normal pattern.
The normal pattern is:

try
{
  // request information from the server
}
catch
{
  // connection not available
}

The only way to really know if the server is available is to try to communicate with it.

 

[mm1352000]

I was under the impression that RemoteControl is designed for a single client. So using it from two threads could indeed turn badly. But if it was designed for multiple clients I should indeed be using it and get connections notifications rather than pulling the connection status.

All these last 5+ years the TV plugin, MP configuration and any other plugin (including MD) that wanted to has been using RemoteControl. Nobody has been worrying about multi threading and everything seems to be working okay.

Ultimately each request to the server is handled separately by the .NET remoting technology. We can let that worry about multi-threading. A few shared variables in the RemoteControl class are not going to make a big problem... unless the server is going offline and online very often (which it should not be in the normal case).

Please stop worrying about it and just use the existing code.

 

[mm1352000]

You are correct using a dedicated thread for pulling information from our TV server would fix our MiniDisplay lag issue without the need to modify TVLibrary.

So please do that.

However we would still be using those single client API from two different threads which is definitely unsafe.

The only part that is not thread safe is the handling of these variables related to the connection itself:
https://github.com/MediaPortal/Medi...ine3/TVLibrary/TvControl/RemoteControl.cs#L69

When the connection is available, the .NET remoting technology handles thread safety for sending/receiving requests.

I feel like you're worrying way too much...

Does TVE 3.5 comes with a proper multi client API?

TVE 3.5 uses WCF to communicate with the server. Yes, WCF is thread safe... but so is .NET remoting.

 

[Stéphane Lenclud]

All these last 5+ years the TV plugin, MP configuration and any other plugin (including MD) that wanted to has been using RemoteControl. Nobody has been worrying about multi threading and everything seems to be working okay.

Ultimately each request to the server is handled separately by the .NET remoting technology. We can let that worry about multi-threading. A few shared variables in the RemoteControl class are not going to make a big problem... unless the server is going offline and online very often (which it should not be in the normal case).

Please stop worrying about it and just use the existing code.

I get your point and I'm happy to use the code the way it is. That's still scary though and I think stuff like that ought to be addressed long term.

Just how many client do we have per installation? From what I can see we only have one on a typical installation and that's the TvPlugin. Add half another one for MiniDisplay users.

 

[Stéphane Lenclud]

Also I have limited experience with c# client/server architecture but I don't think concurrent access to static variables comes for free.

 

[Stéphane Lenclud]

The trouble with those sync issues is that they could cause nasty problems occasionally and compromise the stability of the system. They are also really hard to catch and debug.

You are correct though that most of the time they often end up being irrelevant.