INTERACT FORUM
More => Old Versions => JRiver Media Center 27 for Mac => Topic started by: LilyAarseth on January 10, 2021, 09:05:45 am
-
I still have major UI framerate issues even on .50 on Mac Mini M1. The only time I can get stable 60 fps scrolling is when I shrink the window to the smallest allowed, but when it is nearly fullscreen (2160p w/1440 scaling display) it becomes very choppy and is closer to 5 FPS. Like mentioned before I've noticed that it doesn't seem to use any GPU/HW accel and might be only using a single CPU thread to renderer? I would love any help to try to solve this because it's very uncomfortable to navigate like this.
Edit: Also since I came to the mac client album art gets reset back to small in the album/artist view no matter how much I scale it to the size I want, it reverts back if I press F5 or restart the client. This didn't happen on windows and the client's customization was synced to that of the libary server it was connected to.
-
I still have major UI framerate issues even on .50 on Mac Mini M1. The only time I can get stable 60 fps scrolling is when I shrink the window to the smallest allowed, but when it is nearly fullscreen (2160p w/1440 scaling display) it becomes very choppy and is closer to 5 FPS. Like mentioned before I've noticed that it doesn't seem to use any GPU/HW accel and might be only using a single CPU thread to renderer? I would love any help to try to solve this because it's very uncomfortable to navigate like this.
Edit: Also since I came to the mac client album art gets reset back to small in the album/artist view no matter how much I scale it to the size I want, it reverts back if I press F5 or restart the client. This didn't happen on windows and the client's customization was synced to that of the libary server it was connected to.
Can you explain what you mean when you are comparing scrolling to video frame rates?
You aren't going to get video frame rates when scrolling. There are dozens to hundreds of windows within the view you see while scrolling a bunch of albums, etc not one window like a video playback.
-
Compared to scrolling in a browser or other apps that syncs to the refresh rate of the monitor, jriver stutters/lags significantly. Sorry I'm not good at explaining.
-
It will never be as fast as an app with a single window.
The main standard view window in MC is a window containing many windows including every line of text.
When one is using a retina monitor with scaling, all of those windows are being scaled by MacOS in realtime simultaneously.
You can see that if you turn off retina scaling and use native mode or run on a non retina monitor.
Scrolling even tons of items (say album covers) there is very very fast.
-
I did try on non retina resolutions and it still was laggy. So the M1's hardware simply isn't powerful enough to render and there is no way to optimize it?
-
I did try on non retina resolutions and it still was laggy. So the M1's hardware simply isn't powerful enough to render and there is no way to optimize it?
I'm not seeing your issue.
Check the attached video. It's quite fast.
http://files.jriver.com/mediacenter/test/Screen Recording 2021-01-11 at 10.52.07 AM.mov (http://files.jriver.com/mediacenter/test/Screen Recording 2021-01-11 at 10.52.07 AM.mov)
Download it first before viewing it so you don't get browser lag.
-
Oh you're right, that is better than my windows pc with dGPU as far as I can tell. Also I think I probably explained a bit wrong in a previous post so I apologise for that, I meant the list view Artists, All Artists / All Albums.
-
With that view, even in retina mode and full screen it seems plenty fast to me and it's using almost no cpu.
Even during playback with the spectrum analyzers on.
http://files.jriver.com/mediacenter/test/Screen Recording 2021-01-11 at 12.02.03 PM.mov (http://files.jriver.com/mediacenter/test/Screen Recording 2021-01-11 at 12.02.03 PM.mov)
-
I must be doing something wrong then, for me it's like stop motion even with low resolution mode. I really hope I'm not being rude or come off as complaining, I do appreciate all the help. I genuinely love JRiver and that's why I want to help out any way I can and make it run as good as my hardware allows.
https://media.discordapp.net/attachments/658006776805064766/798258121738289222/2021-01-11_19-29-46.mov
Edit: Artist view with the tiles is actual stop motion on my machine, I MUST have misconfigured something, no way it should be like this. I also noticed that the window itself lags when I drag it around with the mouse.
https://media.discordapp.net/attachments/658006776805064766/798264410262994945/2021-01-11_19-56-51.mov
-
Mine is somewhat slower with the fullscreen list view you show.
I'm using a 4k monitor, not a 5k. That would make some difference.
The thing I was trying to explain earlier is that each line of those file entries consists of several windows * several lines * scaling makes for a lot of movement.
It's still pretty good on my 4k monitor even with your view.
If all of your thumbnails are created I think you are likely seeing maximum performance.
-
I'm on a 4k tv and use scaling to make it look like 1440p. When I set it to 4k with no scaling it doesn't really get much better for me same with scaling 4k to 1080p and natively running 1440p to the tv without retina at all. I've checked inside single artists with just a few albums showing at once and it still lags while scrolling just as much as when viewing all music in the All Artists view. It's so strange, it's just JRiver that has had issues like this for me. Is there any settings or anything I can do to try to improve things? Since you're not having the same performance issues that I am but have the same hardware something is up on my end.
-
Where are your media files stored?
-
I am connected to a client running on a Windows PC on the same local network. I've done this for 2 years on Windows without any notable issues before (aside from being unable to save album art on the remote client). I disconnected the client on my Mac and it is still lagging without any media loaded.
-
When I choose the 1440p size my performance looks more like yours, it works, just not as smooth.
The System Preferences menu says that those non-integer scaled sizes "may affect performance" which is clearly what it's doing.
Since the system can't simple do a /2 when it's calculating how to draw the images to scale there is a LOT more math going on in the System and as I said before MC's list view is going to have many many windows for the system to rescale on non-integer boundaries. Mine is definitely smoother when using the default for my display (which is 1080p on a 2160p 4k monitor).
This may be something Apple will optimize in the future.
-
Even when running the mac mini display output in native unscaled 1080p, the jriver window is very unresponsive and lagging, no media loaded so that should be proof it's not the retina scaling and the number of windows within windows in jriver? Restarted jriver after I disconnected from my remote media server to make sure. Still lagging. No other app/program has ever been this, even bloaty programs running poorly through rosetta 2. It has to be something with jriver itself and optimization/how it renders. Unless there is a hidden button somewhere to enable hardware acceleration.
Here is another clip showing the resolution and how much lag happens once I interact with jriver's window, and safari for comparison.
https://media.discordapp.net/attachments/658006776805064766/798334463557238815/2021-01-12_00-34-46.mov
Again sorry if I come off unpolite, I just think it isn't the OS that's causing this after all the troubleshooting I've done.
-
Even when running the mac mini display output in native unscaled 1080p, the jriver window is very unresponsive and lagging, no media loaded so that should be proof it's not the retina scaling and the number of windows within windows in jriver? Restarted jriver after I disconnected from my remote media server to make sure. Still lagging. No other app/program has ever been this, even bloaty programs running poorly through rosetta 2. It has to be something with jriver itself and optimization/how it renders. Unless there is a hidden button somewhere to enable hardware acceleration.
Here is another clip showing the resolution and how much lag happens once I interact with jriver's window, and safari for comparison.
https://media.discordapp.net/attachments/658006776805064766/798334463557238815/2021-01-12_00-34-46.mov
Again sorry if I come off unpolite, I just think it isn't the OS that's causing this after all the troubleshooting I've done.
Like I said it's not useful doing comparisons to single window apps which is what Safari is.
MC is just doing far more complex operations than that when scrolling.
-
So if I understand correctly, you're somewhat saying MC is just too heavy to run on this hardware smoothly and it can't be optimised and/or have the window/ui math be offloaded by hardware acceleration?
-
I have a late 2019 MacBook Pro with a Radeon Pro 5500m, an i9, an 16GB of RAM, and it's pretty laggy when scrolling, and especially in Retina mode.
https://youtu.be/u2NPGDP3o4c
-
I have a late 2019 MacBook Pro with a Radeon Pro 5500m, an i9, an 16GB of RAM, and it's pretty laggy when scrolling, and especially in Retina mode.
https://youtu.be/u2NPGDP3o4c
That's pretty much normal right now, and pretty sure it's known (I reported this after the first native screen rendering build). If you use any view that displays stacked cover art that way (e.g. Artists or Albums), especially in Retina Mode, scrolling will definitely lag.
I have over 1,000 artists/bands in my library, and over 9000 (lol) albums in my library so scrolling gets pretty laggy when scrolling (much worse than what's displayed in your video) through the list with all those stacked cover art images displayed, which Retina Mode makes worse, which is to be expected. But even though it still chugs pretty badly when scrolling down a list like that, it actually scrolls faster than the old builds before native screen drawing landed. The old drawing method was worse performing than this, so I'm calling it progress! :P
-
That's pretty much normal right now, and pretty sure it's known (I reported this after the first native screen rendering build). If you use any view that displays stacked cover art that way (e.g. Artists or Albums), especially in Retina Mode, scrolling will definitely lag.
I think you can turn off the stacked art.
-
That's pretty much normal right now, and pretty sure it's known (I reported this after the first native screen rendering build). If you use any view that displays stacked cover art that way (e.g. Artists or Albums), especially in Retina Mode, scrolling will definitely lag.
I have over 1,000 artists/bands in my library, and over 9000 (lol) albums in my library so scrolling gets pretty laggy when scrolling (much worse than what's displayed in your video) through the list with all those stacked cover art images displayed, which Retina Mode makes worse, which is to be expected. But even though it still chugs pretty badly when scrolling down a list like that, it actually scrolls faster than the old builds before native screen drawing landed. The old drawing method was worse performing than this, so I'm calling it progress! :P
I believe it is also skin related. On my iMac I see no discernible difference in the jumpy scrolling effect whether I turn off/on Retina or whether I turn off/on all image displays. It is always jump.
On the web interface to my Docker/Linux installation on a Synology NAS, scrolling is pretty smooth (same skin though) even though the benchmark on this one is ⅓ of the iMac (monitor is the same, as I am accessing it from the iMac).