Print

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

[scrutinizer]

I'm using JRiver in audio-only mode.

My library is quite large, at about 9000 albums in separate tracks (no cue), each track has the album cover art embedded.
So far, JRemote can't seem to handle the amount of files (or cover art).
First, it takes quite a while to connect (the Panel web interface connection using a browser is immediate).
When it starts loading and caching(?) the covers, after a minute or two of browsing it becomes unresponsive.
It starts by showing a dark spinning windmill on an album when I press it and not responding.
After a few attempts, it crashes.
This happens 100% of the times on an iPhone 16 with iOS 18.2.1 and also with an older iPhone running iOS 15.

The web-based "Panel" interface works flawlessly (within its limitations) on the same device. So there's no network issue. And of course the old Android running Gizmo is just fine.

I also can't seem to find an option to remove a server once added, there's no delete option. Am I missing it?

[JimH]

It's probably a problem with setup, not JRemote.

Is your server running Windows?   Try power cycling both sides, and the network.

[scrutinizer]

It's probably a problem with setup, not JRemote.

Is your server running Windows?   Try power cycling both sides, and the network.

As I wrote in my post, the problem is consistent, and the Panel web interface works flawlessly from the SAME device.
The problem isn't just performance, it slows down & eventually crashes.
You can easily launch the Panel web interface or Gizmo on another device and use JRiver just fine.
The problem is not the host. Music plays fine & both Panel and Gizmo are working.
This only happens on JRemote iOS.

[JimH]

You seem to know what the problem is. Why ask for help?

[scrutinizer]

You seem to know what the problem is. Why ask for help?

What do you mean?
The problem is somewhere in the iOS version of JRemote. Perhaps my use case is unique (amount of tracks?) I don't know.

I've ruled out a problem on the host since it's working perfectly fine with every remote including Panel from the same iOS devices that JRemote doesn't function well on.

[JimH]

JRemote works with much larger libraries.  That's not the problem.

What is the OS?

[scrutinizer]

JRemote works with much larger libraries.  That's not the problem.

What is the OS?

The host runs on Windows 10 LTSC (x64)
The iOS devices are running iOS 18.2.1 (iPhone 16) and 15.8.3 (iPhone 7 Plus)
both exhibit the same issue (slowing down/freezing/crashing) in JRemote while working fine in Panel using Safari.

[scrutinizer]

I also tried removing JRemote and reinstalling it.
Problem returns.

[scrutinizer]

Also, JRemote is configured to connect directly to the local IP:port.
Not using the access key mechanism.
Still, it's very slow to connect and sometimes simply crashes while trying.
While connecting to the same ip:port from Safari on the same device is working fast and reliably.

[scrutinizer]

JRemote works with much larger libraries.  That's not the problem.

Ok, I've managed to narrow the issue down a bit more.
I'm using the thumbnail view on JRemote, and I had my zoom level up to display two albums per row.
Once I zoom out all the way to display four albums per row, the issue improves (still hesitant to say completely) significantly.
Again, it seems to be somehow related to cover art loading.
It still takes an awfully long time to connect to the server (using direct ip:port) compared to Panel.

I hope it helps.

[JimH]

Try the Access Key method.  You may be trying to connect to the outside address.  See Network Access on the wiki.

[scrutinizer]

Try the Access Key method.  You may be trying to connect to the outside address.  See [url=http://wiki.jriver.com/index.php/Network_Access]Network Access[/url] on the wiki.

I'm connecting directly to my static local IP. Not an outside address.
And of course it connects instantly using Safari to the Panel interface.
The initial connection slowness is a bit annoying, but I can live with it.
The major issue remains the lockups & crashes, which now appears to only be happening when thumbnail view is zoomed in to two covers per row.

[scrutinizer]

Unfortunately, the issue persists in the just-released version 3.43.
I can now confirm that it happens only when zoomed all the way in to two thumbnails per row.
The cover loading becomes slower and slower until JRemote becomes completely unresponsive loses connection to the server, and eventually crashes.
This happens after a few minutes of using the app. Not immediately.

When zoomed out even one step to display three thumbnails per row, the issue does not seem to happen.

[JimH]

Please describe the image format and size of the embedded cover art.

[scrutinizer]

Please describe the image format and size of the embedded cover art.

They're all JPGs embedded in Flacs, the vast majority of which are 864x864px in size,
H - 12 in
W - 12 in
Resolution - 72 Pixels/Inch

Most embedded files around 100-200kb
Only one (front) image is embedded, in each track/file.

[Awesome Donkey]

How large is your music library? How many tracks overall? How many artists? How many albums? Does it slow down worse when using an Album view instead of the Artist view (assuming there's more albums than artists)? I don't own any iOS devices currently (thought about getting a cheap 10th gen iPad for my birthday, maybe) so I can't test this with my large music library however as you mentioned it doesn't happen on Android.

I typically would recommend to avoid using the thumbnail view in all the remotes (JRemote, MO 4Media, Panel, Gizmo, etc.) as if I recall correctly for each entry in the list it overlays multiple images in a stack (e.g. multiple album art covers) versus using the list view which displays one album cover per artist.

[JimH]

They're all JPGs embedded in Flacs, the vast majority of which are 864x864px in size,
H - 12 in
W - 12 in
Resolution - 72 Pixels/Inch

Most embedded files around 100-200kb
Only one (front) image is embedded, in each track/file.

Should not be a problem.

[scrutinizer]

How large is your music library? How many tracks overall? How many artists? How many albums? Does it slow down worse when using an Album view instead of the Artist view (assuming there's more albums than artists)? I don't own any iOS devices currently (thought about getting a cheap 10th gen iPad for my birthday, maybe) so I can't test this with my large music library however as you mentioned it doesn't happen on Android.

I typically would recommend to avoid using the thumbnail view in all the remotes (JRemote, MO 4Media, Panel, Gizmo, etc.) as if I recall correctly for each entry in the list it overlays multiple images in a stack (e.g. multiple album art covers) versus using the list view which displays one album cover per artist.

About 90,000 tracks/8000 albums.
It slows down, becomes less and less responsive, stops loading covers and eventually crashes -  only when browsing/using the app fully zoomed in for a few minutes.
zooming out even one step seems to solve the issue & cover loading becomes quite fast.
This happens on two iPhones with two iOS versions. (18.2.1 & 15.8.3). Browsing with the Panel web interface from the same devices works fine.

[scrutinizer]

Should not be a problem.

Not arguing with that. :-)
It's working fine in Panel & Gizmo. But JRemote doesn't handle it for some reason when fully zoomed-in. On two different devices.
So something is up. I'm trying to be as detailed as I can.

[scrutinizer]

Issue still present in the latest version - 3.44.