More > JRiver Media Center 23 for Windows

MC doesn't behave nicely doing resource intensive tasks

<< < (8/13) > >>

steff:
From the JRiver WiKi
"Play files from memory instead of disk (not zone-specific)
This option loads an entire file into memory so that the disk is not accessed during playback"

This is what declared by JRiver.
But is is not (always) thrue.

Switching track while playing, let the old track to be played while the new one os being loaded.

So please modify MC23 adding a switch to optionally stop playing old track when switching to a new one.

I can explain here what I noticed.
First af all: many laptops today do not have wired ethernet connectivity... just WiFi.
The two ones I am dealing today are HP: x2-10 and 1012... both have 802.11ac and I connect @ 600 Mbps with a SUSTAINED transfer rate of 40 Mbps... so really a good throughput.
I noticed that playing a high resolution file from a mapped network drive is always stuttering quite a lot, but loading it into memory in advance IS NOT!
So... memory playback is a must have for my case.
Moreover... I run the DPC Latency checker tool and I also noticed that every time my audio dropped, I have a big "spike" in the latency and at the same time there is a network burst in the data transfer
OK... then I forced the WLAN adapter to work with 802.11n
WOW!
Big improvement!
Forcing 802.11n will lower the bandwidht, the network burst are much lower, but the duration is longer (of course)
Having lower network burst ... the spike in the latency is much lower and so... less freuqent audio dropouts.
At the of the story, forcing 802.11g will lower much more the network burst and there is no more latency spikes and no more audio dropouts at all!!!

I hope this is clear and could help others.

regards.

millst:
If the rest of your applications and Windows itself are responsive when the JRiver UI becomes non-responsive, then the problem lies in the design of JRiver itself. UIs are almost exclusively single-threaded and are executed on the application's main thread. If the UI is not responsive, it's because so much work is being done on that thread that it can't service the user's requests.

The main solution is to make better use of threads/processes. I/O requests (network, disk, etc.) take time and should never be performed on the UI thread. If there is a lot of processing that must be performed on the UI thread, then another solution is to throttle that execution. It will take longer, but the UI will still be responsive.

-tm

mattkhan:
attempting to play files so large you can't stream them so you have to enforce a period of silence between tracks seems a like terrible user experience to me. The moral of the story seems more like use content your network can handle so you don't have to sit around in silence!

RoderickGI:
Steff do you get stuttering of the audio when a second file is being loaded and the MC interface becomes unresponsive? I didn't get any stuttering in my tests.

Do you hear a difference in the sound while this issue occurs?

If you don't get either stuttering or hear a change in sound, and you are only using memory playback for the reasons you gave, and not just because you believe network activity is just a bad thing during playback, then I would think that the situation is, if not desirable, at least meeting your need. The primary need you have seems to be stated clearly here:


--- Quote from: steff on February 01, 2018, 10:22:11 am ---I noticed that playing a high resolution file from a mapped network drive is always stuttering quite a lot, but loading it into memory in advance IS NOT!
--- End quote ---

MC is achieving your goal. It just isn't pretty.

As I said above, I am sure that the developers have seen this thread by now. Maybe a fix is now on the list of things to do. JRiver never makes promises about changes like this, which do not involve a bug but do impact the user experience. It really is a case of waiting to see if a fix is implemented. I have personally waited as much as two years for something that I thought was an obvious improvement that many users would want. But I've also had some issues fixed within hours. That is just the way it is. You have suggested a quick fix which would be easy to implement; A switch to stop playback while a new file is loading. A long-term and better fix for most users would be to make some changes in the threading of tasks MC does, but that would not even meet your wish to have no network activity while playback is occurring. That takes me back to my point above; Do you just want no network activity, or do you want no stuttering and clean sound all the time?

Remember, with many other applications you often have no access to developers, and even bugs can be left in place for years, let alone perceived user issues.


I do think that this is a good idea:

--- Quote from: millst on February 01, 2018, 10:49:54 am ---The main solution is to make better use of threads/processes. I/O requests (network, disk, etc.) take time and should never be performed on the UI thread. If there is a lot of processing that must be performed on the UI thread, then another solution is to throttle that execution. It will take longer, but the UI will still be responsive.
--- End quote ---

I would like to see this done, as it is a very bad user experience for the MC User Interface to effectively lock up and become unresponsive when doing normal tasks. I see it too often. Even a popup message that said. "Please Wait" would be better than MC becoming unresponsive. But I know what it is, and it often only lasts seconds, so it doesn't spoil my day.


Finally, I can confirm that I saw large spikes in network activity while a second album was loading in my tests. The network was continuously showing ~100% load, then 0% load, then ~100% load, etc. for Media Center. It would be far better if the network load was more consistent and did not consume 100% of the bandwidth at any time. This does seem like a design flaw. I don't know what is possible to manage this, but maybe some throttling of MC to 50 to 80% of available network bandwidth, rather than the current "load the file(s) as fast as possible".

steff:

--- Quote from: millst on February 01, 2018, 10:49:54 am ---If the rest of your applications and Windows itself are responsive when the JRiver UI becomes non-responsive...

--- End quote ---

YES, just MC become non-responsive.
of course, since MC's GUI expand over the Windows taskbar, I have to use Alt-Tab to switch so something else than MC GUI.
Anyway, this PC is dedicated to play music with MC, so I do not need to do something different.
It is just not so nice to have the GUI behaves in this way, it gets blurry... and if using the Theatre View, then the Windows taskbar pops up in front.
It is not nice...

Navigation

[0] Message Index

[#] Next page

[*] Previous page