Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[flac.rules]

I am trying to troubleshoot small "freeze-ups" on the client-side when running a server-client setup, the program becomes unresponsive for maybe 2-10 seconds. No apparant system expect it seems to happen more often on moving from palying one file to the next. CPU-load on server-side is pretty low. Although it might rise a bit on the "jrworker"-thread while it happens (could be some kind of confirmation bias though), gigabit ethernet, server runs no AV, freshly installed windows 10, clients use windows 10. Gigabit ethernet.

Any tips on logs or similar i can look at?

[JimH]

Does the client run antivirus software?

Are the files on a NAS?

[flac.rules]

Does the client run antivirus software?

Are the files on a NAS?

Client does run windows defender, but JRiver folder and all processes are in exeption list (as far as i can tell, the setup in win10 is a bit different, you only name the process, not the location of the exe)

Files are stored on a file-server (not the same machine as the one running the MC-server)

[JimH]

So you have two possible avenues to explore.  The file server and the antivirus. 

Start changing your setup.  Try changing to local files instead of the file server, for example.

[flac.rules]

So you have two possible avenues to explore.  The file server and the antivirus. 

Start changing your setup.  Try changing to local files instead of the file server, for example.

There is no problem with local files, nor with a local library (playing files from the file server over network), the problem seems to be related to the server-client setup.

[dtc]

Do you have problems with playing files on the client that are stored on the server when in client-server model? It sounds like you the delay may be the MC server going to the file server.

[JimH]

Client does run windows defender, but JRiver folder and all processes are in exeption list ...

glynor wrote a topic on how to set up antivirus.  It's on the wiki.  Search for "Taming Windows Defender".

[flac.rules]

glynor wrote a topic on how to set up antivirus.  It's on the wiki.  Search for "Taming Windows Defender".

Yeah, I have setup exceptions for MC in windows defender.

[flac.rules]

Do you have problems with playing files on the client that are stored on the server when in client-server model? It sounds like you the delay may be the MC server going to the file server.

I will try to see if that works, but I don't think that is the reason. Because i have "Play local files if available", set up, and the fileserver-drives mapped up on the client, so the server shouldn't have to pull the file at all. Do you know if there is a way to verify 100% that the files are getting pulled directly by the client?

[dtc]

You might also try turning off Play Local File and see if that makes any difference. Not sure why it would, but it is something to try.

[flac.rules]

You might also try turning off Play Local File and see if that makes any difference. Not sure why it would, but it is something to try.

I tried this, and it doesn't seem to make a difference either way (maybe the freeze-ups are less during file play, and more limited to changing of files, not sure). When this is turned off, shouldn't MC cause a bit of network-traffic on the MC-server? Seems like there is no network-traffic to speak of.

I now see my first post is a bit unclear, the freeze-ups seems to happen on the interface, that is picture and menus, if it is on the middle of the file, it continues to play. There can be  a pause while changing files though.

[flac.rules]

Any other tips on how to troubleshoot this? Is there some kind of debug-mode in the program? Some kind of network-analysisprogram i could use to get out som data? Anything else to pinpoint the reason for the problem?

[flac.rules]

Bump

[JimH]

Take a look at Arindelle's post from yesterday.

[flac.rules]

Take a look at Arindelle's post from yesterday.

You mean the one about AV? As mentioned, there is no AV running on the server, all JRiver processes and folders are in the exeption list on the client.

[AndrewFG]

You mean the one about AV? As mentioned, there is no AV running on the server, all JRiver processes and folders are in the exeption list on the client.

Putting the folders and the processes on the exception list might not be sufficient. An MC client talks to its MC server using HTTP transactions. So you need check if there is anything on the client or the server that could be specifically blocking such HTTP traffic.

Also: I am not 100% sure on the following, but AFAIK the client and the server BOTH need to be able to handle outgoing and incoming HTTP requests. This is because the MC client may sometimes act like a server, and the MC server may sometimes act like a client...

[flac.rules]

Putting the folders and the processes on the exception list might not be sufficient. An MC client talks to its MC server using HTTP transactions. So you need check if there is anything on the client or the server that could be specifically blocking such HTTP traffic.

Also: I am not 100% sure on the following, but AFAIK the client and the server BOTH need to be able to handle outgoing and incoming HTTP requests. This is because the MC client may sometimes act like a server, and the MC server may sometimes act like a client...

But would blocking cause these occasional freeze-ups? Wouldn't it be more natural to assume that a blocking would cause some kind of permanent malfunction? Any tips on what it could be? I can't think of anything of the top of my head that should block http-traffic, both the server and client are pretty close to a fresh install at the moment. Is there some kind of sniffing software that can track network traffic to look for patterns?¨

EDIT: I have downloaded the PRTG network monitoring software, I will see if I am able to get something out of that.

[AndrewFG]

If something is preventing HTTP traffic it will cause the respective task thread in MC to freeze. Now MC is a multi-tasking application and it can handle some degree of frozen threads, and it even has code to detect, kill and recover from frozen threads. However if frozen threads occur very often, (perhaps a vicious circle of threads waiting on each other), then sooner or later it will cause the whole application to fail.

If it is something blocking incoming HTTP activity, you might be able to see it on a network analyzer such as WireShark, but it requires quite a lot of knowledge on TCP IP socket mechanics to understand a WireShark log. However if it is something blocking outgoing HTTP activity, you would never see it, because it never even gets as far as the LAN.

[flac.rules]

If something is preventing HTTP traffic it will cause the respective task thread in MC to freeze. Now MC is a multi-tasking application and it can handle some degree of frozen threads, and it even has code to detect, kill and recover from frozen threads. However if frozen threads occur very often, (perhaps a vicious circle of threads waiting on each other), then sooner or later it will cause the whole application to fail.

If it is something blocking incoming HTTP activity, you might be able to see it on a network analyzer such as WireShark, but it requires quite a lot of knowledge on TCP IP socket mechanics to understand a WireShark log. However if it is something blocking outgoing HTTP activity, you would never see it, because it never even gets as far as the LAN.

Ok, so I could expect the client-server functionality to work even if HTTP-traffic is blocked then? (only slower or something)

[AndrewFG]

No.

[flac.rules]

No.

Ok, then it likely is not the problem, as the client-server works per se, it only freezes up the UI at an inconsistent time interval.

[muzicman0]

You asked a question earlier in the thread about verifying if the client was playing the file directly (via mapped drive), or if the server was serving it up...I think I also read that the network files were not on the MC Server, but on a separate file server.  If you monitor the outgoing network traffic from the MC server task manager, that should tell you if it is serving the file through the MC server.

[flac.rules]

You asked a question earlier in the thread about verifying if the client was playing the file directly (via mapped drive), or if the server was serving it up...I think I also read that the network files were not on the MC Server, but on a separate file server.  If you monitor the outgoing network traffic from the MC server task manager, that should tell you if it is serving the file through the MC server.

Yeah, I actually tried that the other day, it seems based on that the it is actually playing the file directly (as expected), and not via the server. (if it streams more or less continuously, I might have been fooled if it buffers up large parts of a video file at a time, and then no network for a longer period)

[AndrewFG]

Ok, then it likely is not the problem, as the client-server works per se, it only freezes up the UI at an inconsistent time interval.

Huh?

[flac.rules]

Huh?

Maybe the first post was unclear I will try to specify a bit better:

The client can access the server library and play files from it. However the client "freezes up" on irregular intervals (the GUI is unresponsive, and turns "white", while there is a loading icon on the mouse cursor. This seems to happen more often after i file has played or during a change of files). The GUI will respond again after 5-30 seconds. (approx)

[AndrewFG]

What makes you think that that is not caused by HTTP blocking?

[flac.rules]

What makes you think that that is not caused by HTTP blocking?

I asked if I could expect the client/server functionality to work at all if http traffic was blocked. You answered no. And considering that the client/server-functionality works (but "poorly" "slow" "with hiccups" or what you want to call it), it seem unlikely that that is the problem, right? Or did I misunderstand you?

[AndrewFG]

If HTTP traffic is blocked, you cannot expect the full client-server functionality to work. So the answer is no. Because some of it won't work. And that means that sometimes its not working will cause the UI to freeze.

[flac.rules]

If HTTP traffic is blocked, you cannot expect the full client-server functionality to work. So the answer is no. Because some of it won't work. And that means that sometimes its not working will cause the UI to freeze.

Ok, I see, I will investigate this a bit and see if it generates http-traffic.

I don't know if it helpful, but the most consistent "slowness" when using the client-server setup (although its not the same type of "UI-freeze" problem, just that the process stays on "forever") is that closing the program takes a very long time, several minutes. I have attached some pictures with the threads lingering and using CPU, if that gives any additional information.

[AndrewFG]

Probably someone at JRiver needs to comment further, but the delayed thread using 12% CPU is not a symptom of being blocked on an external event (such as a disk or network access). It means that the thread is busy doing something. A blocked thread would show 0%..

[flac.rules]

Probably someone at JRiver needs to comment further, but the delayed thread using 12% CPU is not a symptom of being blocked on an external event (such as a disk or network access). It means that the thread is busy doing something. A blocked thread would show 0%..

Thanks, that is useful information that might help in the troubleshooting.

I checked the http-traffic, and it seems to be open both on server and client-side.