INTERACT FORUM

Yes, that should work.
As Marko said above, there are some known issues when editing smartlists on remote clients, but just adding files to normal playlists is usually not a problem.

This is likely the source of your problem. If the JRemote/iPad is connecting in read-only mode then any changes will NOT be saved on the server, so they will be lost when you restart the app (crash or no crash). You should set a username+password for the read-only mode, and a different username+password for the normal Authentication on the server. Then reconnect your JRemote/iPad, it should ask for the user/pass (you may need to remove the library and add it again). Use the non-readonly credentials. After doing this you can set the read-only auth back to "everyone", as the clients will now remember to use the last authentication credentials you gave them.

I just want to be able to make changes to my library while on-the-go and I don't need read-only authentication. Can I just simplify things by disabling read-only authentication and still be able to make changes on-the-go using authentication?

I remember being very suspicious of those too when I started to use JRiver. I've never seen a description of what they do.

JRWeb is used to host the web browser for any views that show a website. Web Browsers should generally be sandboxed into their own process for security and stability - and thats what JRWeb does.
JRWorker primarily performs video import and thumbnailing, so it doesn't bog down MC itself. It has some other tasks like dealing with some handheld devices as well, but thats much more niche.
JRService is a light-weight system service that handles some remote control functions that require a system-wide component to intercept. From all those here, its probably the most niche.

Ok, interesting.  I think Manni you're on to something here about the refresh rate change causing the issue.  If I set my display to 120 and turn OFF custom refresh rate options in MC, I do indeed get metadata passed without having to enable the OS nonsense first.  IF, however, I have the refresh rate option in MC set to on, I lose all metadata unless I enable OS HDR before playback.  So I don't know if that can be improved but that's what's happening there.

Hendrick, while we're on the topic of DV and profile 7.  Any chance you could eventually include an option to convert it to profile 8 on the fly.  Kodi now has that option built in and it's useful for some people. I think for the purposes of using the DV data here it MIGHT be useful?  But I'm with Manni, please don't just shut it off for profile 7.  I definitely see improvement in MEL titles for sure.  An option would be nice.

Thanks for confirming that you're also experiencing this and that refresh rate change might be involved.

I'm still testing and trying to find a way to 100% reproduce the issue. Please can you check in your VRROOM OSD settings and report what your "ignore metadata change" box is set to? If it's checked (enabled), can you disable it and report if you see any difference in behaviour re displaying the HDR metadata info?

What is your default refresh rate in Windows (and/or the one specified in JRVR if you use custom)?

I just changed it to "Everyone" instead of "Username and Password"

This is likely the source of your problem. If the JRemote/iPad is connecting in read-only mode then any changes will NOT be saved on the server, so they will be lost when you restart the app (crash or no crash). You should set a username+password for the read-only mode, and a different username+password for the normal Authentication on the server. Then reconnect your JRemote/iPad, it should ask for the user/pass (you may need to remove the library and add it again). Use the non-readonly credentials. After doing this you can set the read-only auth back to "everyone", as the clients will now remember to use the last authentication credentials you gave them.

They arrived an hour ago and I initially had issues with lower volume from the left speaker which seems to be either caused by a flaky third-party 4.4mm to XLR balanced adapter cable or because I'm powering the DAC over USB. After messing with it for over 30 minutes I finally got the third party adapter plug in the right position to get it working with both speakers so I went ahead and just ordered both the iFi Power2 AC adapter and the iFi 4.4mm to XLR balanced adapter cable which will be here Sunday. Damn, I was hoping to get away with not having to get either, oh well. I'm also using the Cable Matters XLR cables from Amazon, but I'm also open to alternatives if there's any better ones.

As for the sound after I got both sides working? AMAZING. Applied the recommended 1516Hz EQ via parametric EQ from that topic and no issues whatsoever. I know what I'm doing the rest of the day.

It should also be noted that I see a lot of these crashes happen while I'm on my computer going through a smart playlist of mine in MC32 called "1s" which is basically a playlist of 1 star songs that I have to go through before they can be permanently deleted from my library.

Even with authentication, changing playlists on any client connected to the server is likely to cause problems. I think I have some pages bookmarked regarding this issue but am not at my PC just now. IIRC, the "playlist id" gets messed up when the client syncs back to the server which causes much weirdness...

For context, the only changes I make thru the server are on my iPad by manually adding songs to certain playlists (such as "-Cover", "-Genre", "-Title", etc.) so that I know what changes need to be made when I get home. I'm a delivery driver and add the songs that need to be fixed to these certain playlists in between deliveries. I probably add around 50 songs to these playlists in a given day.

If JRemote or MC Client is connected to the MC server with the read-only user/pass, then changes to playlists won't be saved permanently.

I just changed it to "Everyone" instead of "Username and Password"

Perfect, thanks for that.  It seems helpful to me.  Whether it's placebo or not, it's definitely not harming anything by having it.