More > JRiver Media Center 23 for Windows

MC doesn't behave nicely doing resource intensive tasks

<< < (10/13) > >>

RoderickGI:
Well, I didn't say it was, Jim. Just that it appeared that way.  :D

Mainly because I could easily get MC to become unresponsive, although I did need to limit my network to 10Mbps to do that. But I never heard any stuttering or audio issues even when MC was unresponsive, and nor did other users who have commented, so obviously something else is going on in Steff's environment.

You are also correct that we haven't investigated the antivirus solution Steff is using, or whether exclusions for MC have been implemented. It is quite possible that an antivirus solution is causing the stuttering as it scans the large inbound audio files, even though they are going to memory rather than disk.

flac.rules:
I am not running AV, and the ui issue is not just a memory playback thing. It seems to be a more general problem, possibly related to tasks that takes a while and access the network (all the examples in the thread seems to be of that nature).

steff:
I DO CONFIRM, as already explained:
it is not a AV matter. Out of the box, HP laptops are equipped with Win10 and McAfee.
I first disabled McAfee, then uninstalled completely McAfee, so Win10 switched activating Defender... no changes in the behaviour
Now Defender is DISABLED, but still installed (no easy way to remove from the system) and moreover the JRiver program folder, the JRiver library folder and the netowkr folder where music is stored all of them are excluded from scan.

I remark the previous consuderation:
If I keep open the windows taskmanager and the DPC Latency Checker, I can easily demonstrate that:
1) CPU is always low \ very low; I disabled almost everything from Windows and during playback the CPU is below 10%
2) I see HUGE network spikes... the process is not smooth... but the file is being read piece by piece with spike up to 100% of the network capacity
3) During the network spikes, I can notice a spike also in the DCP Latency and audio dropouts

So I can demostrate that it is because of the network activity that I get audio dropouts.
Audio dropouts are mitigated lowering from 802.11ac to 802.11n and no audio droputs at all using 802.11g
It is not because of the ac\n\g protcols, but because of the huge amount of data being transferred in the time unit.
A huge but very short spike produces a spike in the DCP latency and audio dropout
Using 802.11g produces longer network spikes but less intense and no DCP latency spikes at all and therefore... no audio dropouts.

steff:
Dear JRiver team
here you can find an old post regarding an annoying problem on the MC interface.

https://yabb.jriver.com/interact/index.php/topic,114167.msg789771.html#msg789771

Even if I initially bought the licence for MC23, then upgrded to MC24 and finally to MC25, I never used MC because of such problem.

Is this problem finally solved?

Awesome Donkey:
I might be wrong, but I don't think they ever could reliably reproduce those type of issues (at least the very long "lock ups"). And that's the big gotcha about software development; if the developers can't reliably reproduce an issue (or reproduce it at all) they can't really fix it, assuming of course, it's actually a bug with the software and not a bug with something else (e.g. the OS itself). Could even be caused by other software like antivirus apps, which is why the antivirus question is asked a lot here. In the case you mention, that suggests to me something like slow network response (or a NAS or whatnot spinning up discs) type of deal. Doing anything over the network with spinning discs that need to wake up is always going to have issues appearing to "lock up" the app when they're spinning up. It's not really a bug per-say, it's more of a condition where MC is trying to read the files on a sleeping NAS/drive(s) and is waiting for the NAS/drive(s) to wake up before resuming operation. Pretty sure that part of the waking drives is handled by the OS itself, and not MC. Doing this over the network, depending on your network and how fast it is, can also cause the operation to be pretty slow.

That said, I believe they made some tweaks at some point during the development in MC25 to somewhat help with the "locking up" of the UI. You might give the latest MC25 build a try and see if it's improved any. Matt also made performance improvements when dealing with a large library with a huge amount of files as well. Other than that, how I'd probably deal with that issue is get NAS hard drives that's meant for 24/7 use, disable sleep on the NAS and let it run that way all the time. And I'd probably do this with a network setup that uses hardware that supports at least 1 gigabit (hardwired ethernet for the most important things, of course).

Navigation

[0] Message Index

[#] Next page

[*] Previous page