Print

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

[mattkhan]

IMV the big new feature should be getting the jriver to work reliably in a networked setup with many clients.

The app itself, on windows at least, freezes much too often (possibly a function of the lack of segregation between the client and the server?)
The feature gap from linux (and presumably mac) to windows is too big.
As a whole home audio system, it just doesn't work reliably.
The conflation of dsp configuration with physical zones.
API inconsistency and feature patchiness

in other words, properly fill in the gaps between the existing features rather than add more features.

[JimH]

I moved this because it has a number of different problems and no details.

I know you've had some problems.  We fix what we can reproduce.  Details help.

[mattkhan]

I'll go through some previous posts over the weekend to pull together details

[JimH]

The app itself, on windows at least, freezes much too often (possibly a function of the lack of segregation between the client and the server?)

Do you have a link for any thread on this?  It's unlikely to be MC itself.

[mattkhan]

Do you have a link for any thread on this?  It's unlikely to be MC itself.

IME MC whites out on a somewhat regular basis for no obvious reason. By somewhat regular I mean a few times a week on average. Sometimes it is actually hung (and something like panel can't connect), other times it is just a UI freeze. I've logged it via a thread in the cases where there is some info available to report, in other cases it is just a question of killing it, restarting and moving on.

I get the impression it happens more often when requests come in from other clients and/or when it is doing things like ripping, i.e. my HTPC MC client is taken out by some MC server type of activity. If MC were decomposed into separate services then I would expect it to be more resilient to such events. Obviously this is pure speculation.

I don't understand why you'd say it is unlikely to be MC itself when MC itself is the only thing that is freezing. An app whiting out is not that regular an occurrence in my experience.

[bob]

IME MC whites out on a somewhat regular basis for no obvious reason. By somewhat regular I mean a few times a week on average. Sometimes it is actually hung (and something like panel can't connect), other times it is just a UI freeze. I've logged it via a thread in the cases where there is some info available to report, in other cases it is just a question of killing it, restarting and moving on.

I get the impression it happens more often when requests come in from other clients and/or when it is doing things like ripping, i.e. my HTPC MC client is taken out by some MC server type of activity. If MC were decomposed into separate services then I would expect it to be more resilient to such events. Obviously this is pure speculation.

I don't understand why you'd say it is unlikely to be MC itself when MC itself is the only thing that is freezing. An app whiting out is not that regular an occurrence in my experience.

Does it seem like you are seeing this more with recent builds?
I did run into the same just once, with the linux version.
It looks like it was waiting on a flakey DLNA device and didn't timeout for some reason.
There were some changes in that area to make MC more resilient to flakey devices and it's possible that uncovered a different issue.
We've got a ton of clients here as well as MC development PC's and Id's that are being turned on and off frequently so I'd expect to see it here more than you do.

[mwillems]

FWIW, I've definitely seen MC server hangs over the long term (both recently and for some time), that are mostly (based on my experiments) related to hardware device access on the server.  For example, my server is very likely to hang when refreshing the EPG, recording TV, ripping a CD, or syncing a mobile device.  Heavy client load (i.e. requests for transcoding) seem to exacerbate the risk of hangs, but, as an experiment, I stopped using MC for recording TV and stopped using MC to rip CDs.  My server has only hung once in the last month, and that was during an EPG load.  This is with an MC for windows server with 6+ clients (linux and windows) at all times.

Based on this, I think a little more separation between the user-facing pieces and whatever threads are accessing hardware might pay dividends in stability.  Allowing clients to do these things themselves (rip CDs locally, access networked TV cards directly, etc.) would also help as currently most hardware-access type things *must* be done on the server because MC doesn't permit clients to do them.

[mattkhan]

Does it seem like you are seeing this more with recent builds?

I think so but I can't say that with real conviction. There was certainly a period of time when my MC server was very stable but I wouldn't say that was true over the last 6 (not sure, haven't taken notes) months or so. The amount of client activity has gone up somewhat in that time too though.

Based on this, I think a little more separation between the user-facing pieces and whatever threads are accessing hardware might pay dividends in stability.  Allowing clients to do these things themselves (rip CDs locally, access networked TV cards directly, etc.) would also help as currently most hardware-access type things *must* be done on the server because MC doesn't permit clients to do them.

agree with this, particularly the bit about allowing the client to do more.

[bob]

FWIW, I've definitely seen MC server hangs over the long term (both recently and for some time), that are mostly (based on my experiments) related to hardware device access on the server.  For example, my server is very likely to hang when refreshing the EPG, recording TV, ripping a CD, or syncing a mobile device.  Heavy client load (i.e. requests for transcoding) seem to exacerbate the risk of hangs, but, as an experiment, I stopped using MC for recording TV and stopped using MC to rip CDs.  My server has only hung once in the last month, and that was during an EPG load.  This is with an MC for windows server with 6+ clients (linux and windows) at all times.

Based on this, I think a little more separation between the user-facing pieces and whatever threads are accessing hardware might pay dividends in stability.  Allowing clients to do these things themselves (rip CDs locally, access networked TV cards directly, etc.) would also help as currently most hardware-access type things *must* be done on the server because MC doesn't permit clients to do them.

Could you set up a test to turn off Media Network, then do the other activities that are giving you issues? I'm suspicious that may be where the trouble is.
That zone update is done on the main thread, it could be moved but that is a project in itself. There are timeouts on all of those functions so theoretically they shouldn't hang...

[mwillems]

Could you setup a test to turn off Media Network, then do the other activities that are giving you issues? I'm suspicious that may be where the trouble is.
That zone update is done on the main thread, it could be moved but that is a project in itself. There are timeouts on all of those functions so theoretically they shouldn't hang...

I'm not sure that networked TV devices even work at all with Media Network off (or at least they didn't used to work).  The TV recording issue is non-deterministic and usually takes a day or two to manifest.  It would be challenging to turn off media network for a few days. 

But I'll try and repro it with CD Ripping and device syncing as those are a little more "on-demand".

[bob]

I'm not sure that networked TV devices even work at all with Media Network off (or at least they didn't used to work).  The TV recording issue is non-deterministic and usually takes a day or two to manifest.  It would be challenging to turn off media network for a few days. 

But I'll try and repro it with CD Ripping and device syncing as those are a little more "on-demand".

Thanks.
I set up a few more devices here and will try to reproduce it as well.

[JimH]

What OS are the servers using?

Antivirus on the servers?

[mwillems]

What OS are the servers using?

Antivirus on the servers?

For me, my server is running windows 10.  The only antivirus is windows defender, which can't be uninstalled, but I took all the steps on the wiki for "taming" it to the extent possible (i.e. all MC's processes are exempt, etc.).

[JimH]

The only antivirus is windows defender, which can't be uninstalled, but I took all the steps on the wiki for "taming" it to the extent possible (i.e. all MC's processes are exempt, etc.).

There have been a few mysterious "hangs" lately that were found to be related to "improvements" in Windows Defender:

https://yabb.jriver.com/interact/index.php/topic,112711.msg779528.html#msg779528

[RoderickGI]

I have certainly seen more "white outs" on my server in the last six months. Rarely an actual crash, but it can take some time for MC to "catch up" and start responding again. I used to never see crashes, and very very rarely see any white outs/pauses/hangs. I suspect that Windows 10 and Microsoft's poor quality updates have a lot to do with this, but not everything.

Often when white outs do happen MC is happily recording TV in the background, and if I try to kill it Windows lets me know that a process is still running, and gives me the option to back out and wait, which I usually do. I usually only run one Client, which is my workstation, but I do all sorts of MC stuff on there. I often see the white out problem when I need to check something on the server that can't be checked on the client, and so go to the HTPC to find it stuck.

The problem with reporting these issues is that it is almost impossible to work out what was going on at the time, what may have contributed to the problem, and what likely did not. It would be great if;

1. Beta team members, and maybe everyone, had access to a tool that could help identify and diagnose these issues as they happen. I'm thinking a separate tool that isn't going to lock up with MC, but watches it. The tool should be capable of identifying when MC is waiting for some hardware, or software module, and what it is, including a virus scanner!
2. JRiver provided a tool that can analyse the logs MC produces, so that a user could note the time of a problem and use the tool to look at logs from that time, rather than trawling through huge logs with all threads and PIDs mixed in together, trying to find any actual record of the problem.

Diagnosing these sorts of intermittent problems is really hit and miss for me, and mostly I just ignore and work around them. For example, my Sony TV currently seems to refresh its screen resolution or HDMI connection occasionally during video playback. This only started after I briefly changed MC and the Desktop resolution to 4K, and then changed it back. How on earth do I diagnose that? It is so intermittent that I can't make it happen. I would need to run logging all the time and then catch the occurrence, note the time, immediately stop logging, work out where that would be in the log, and then try to find something relevant, which possibly isn't even logged, or is quite cryptic. It is a frustrating process all around.

I also agree with this sentiment.

in other words, properly fill in the gaps between the existing features rather than add more features.

MC is a great product, but it might be time to fill the gaps and polish some of the features.

[JimH]

The problem with reporting these issues is that it is almost impossible to work out what was going on at the time, what may have contributed to the problem, and what likely did not.

If you can do that, we can fix it.  If not, we wait.

I'm thinking a separate tool that isn't going to lock up with MC, but watches it. The tool should be capable of identifying when MC is waiting for some hardware, or software module, and what it is, including a virus scanner!

Now you're dreaming.   Antivirus software is a little defensive about being watched.

2. JRiver provided a tool that can analyse the logs MC produces, so that a user could note the time of a problem and use the tool to look at logs from that time, rather than trawling through huge logs with all threads and PIDs mixed in together, trying to find any actual record of the problem.

Good idea, but I don't think it would catch the Weird Problems.  They're the toughest.  They require brute force triage.

Diagnosing these sorts of intermittent problems is really hit and miss for me, and mostly I just ignore and work around them. For example, my Sony TV currently seems to refresh its screen resolution or HDMI connection occasionally during video playback. This only started after I briefly changed MC and the Desktop resolution to 4K, and then changed it back. How on earth do I diagnose that? It is so intermittent that I can't make it happen. I would need to run logging all the time and then catch the occurrence, note the time, immediately stop logging, work out where that would be in the log, and then try to find something relevant, which possibly isn't even logged, or is quite cryptic. It is a frustrating process all around.

Yes.

MC is a great product, but it might be time to fill the gaps and polish some of the features.

That's more or less how we spend our lives.  I wish we had more magic wands.  It's a treacherous environment.

[mattkhan]

network use causes problems
- playback on a client interrupted the server - https://yabb.jriver.com/interact/index.php/topic,111061.msg767629.html#msg767629

- errors on the server aren't visible on the client - I think this particular example was fixed (https://yabb.jriver.com/interact/index.php/topic,112182.msg775560.html#msg775560) but the problem is more generic than this in that remotes (inc clients) seem to receive little feedback from the server if something goes wrong

- DLNA - https://yabb.jriver.com/interact/index.php/topic,107711.msg747645.html#msg747645 - this one also seems to have a variety of workarounds and/or inconsistent behaviour so it's hard to reproduce.

- clients don't keep the server awake and/or don't wake a sleeping client except on startup - this has been mentioned a few times, e.g. https://yabb.jriver.com/interact/index.php/topic,111597.msg771486.html#msg771486 or https://yabb.jriver.com/interact/index.php/topic,109823.msg759607.html#msg759607, workaround is leave server on 24/7... note that this one can combine with the "errors on server aren't visible on the client" in a particularly annoying way (i.e. the fix is to know that you might have to shutdown the client and open it again if a client appears to do nothing when you ask it to play something

mc server instability and/or mc server/client separation
- changes in video stream via a capture card causes jriver hang - https://yabb.jriver.com/interact/index.php/topic,112566.msg778546.html#msg778546

[JimH]

That you have had a lot of problems doesn't prove what the cause is.  Computers can be complicated beasts.

Why don't you choose one problem and pursue it in a single thread?  If it's an MC problem, we'll find it.

Have you read the thread on Windows Defender?  https://yabb.jriver.com/interact/index.php?topic=112750.msg780310#msg780310  It's a recent problem (last few months) but it looks real.

Would you mind editing and removing the feature requests?

[mattkhan]

Why don't you choose one problem and pursue it in a single thread?  If it's an MC problem, we'll find it.

I think all of the actual problems have their own threads and I've linked to them in my previous post. I've broken out a separate thread for each feature request and put them in the windows or linux board as appropriate.

re windows defender, I am running win 8.1 pro and actually have that disabled via group policy now so I'm quite sure that is not a factor.

[JimH]

Please don't assume anything about Windows Defender.  Something has changed in the last few weeks.  Please read Awesome Donkey's post carefully:  https://yabb.jriver.com/interact/index.php/topic,112750.msg779794.html#msg779794

I edited your list for formatting and to remove the feature requests. 

Now choose one of the above and we'll try to help.  I believe Yaobing has spent some time helping with the capture device problem.  It's not clear to me that that one is a problem with JRiver.