INTERACT FORUM

re-asking:

does jremote support playback of mp4/HVEC?

i have a lot of content in that container using that encoding.   audio plays fine but no video.

if not, can you add it?  ios/ipados support both

Can you check/confirm that you don't have other settings setup to change refresh rate?
For example if you set Settings -> Tree & View -> Fullscreen -> Resolution, this would apply entirely independent of the video, and also ignore the delay. I would recommend to not set this field, or rather ensure its set to "Desktop Settings" (which translates to "leave it at what it is"), so that the video-specific option can run.

If this one applies first, then the Video -> Display Settings mode doesn't need to change anymore, and also not apply its delay.

Thanks, I'll double check that and will report back, but I don;t remember evern touching this. I'll write a recap with an answer to all your questions in your last two posts as soon as I get a  chance to test, which might be in a few hours.

I understand that the wait/delay might not be triggered in that case.

Can you check/confirm that you don't have other settings setup to change refresh rate?
For example if you set Settings -> Tree & View -> Fullscreen -> Resolution, this would apply entirely independent of the video, and also ignore the delay. I would recommend to not set this field, or rather ensure its set to "Desktop Settings" (which translates to "leave it at what it is"), so that the video-specific option can run.

If this one applies first, then the Video -> Display Settings mode doesn't need to change anymore, and also not apply its delay.

Do you actually use a version of MC that already has this feature?
The screenshot shown in the first post from your JRVR settings was a too old version of MC before this feature was introduced, so it did not actually include the detected or configured SDR brightness. So if you haven't updated since then, then you wouldn't actually have this feature yet, and instead are letting Windows up-convert the video, which is known to have some issues.

And a SDR 3DLUT cannot be used, because 3DLUTs are designed to compensate for the screen response, so the original video format is much less relevant then the current screen mode - which would be HDR, and as such a SDR 3DLUT cannot be applied.

Thanks, I'll double check. I thought I had installed build 49 also on the HTPC, but if it's not a stable build it might still be on the last stable as I'm on the stable, not latest, so it might be that I only installed 49 manually on my laptop. I'll report back if I was on an older build on the HTPC I'll retest the new feature. Apologie in advance if that's the case. I'll also double check the refresh rate change, as it definitely works when MC is used as an external player.

I understand why the SDR 3D LUT can't work in HDR, that's why even if this new feature works it's only a temporary workaround, not a fix. I wouldn't have moved to JRVR if it didn't support madVR 3D LUTs, especially for SDR calibration.

If you don't want or are unable to fix this, then at least make the "SDR playback as HDR (BT2020 PQ) when OS HDR is enabled" feature introduced in build 49 work properly so that we can leave the OS HDR permanently enabled as a workaround. Currently gamma is wrong when using this new feature: as reported earlier, the picture looks washed out and I assume an SDR 3D LUT can't be used anymore as I understand it's disabled in HDR passthough (as it should be).

Do you actually use a version of MC that already has this feature?
The screenshot shown in the first post from your JRVR settings was a too old version of MC before this feature was introduced, so it did not actually include the detected or configured SDR brightness. So if you haven't updated since then, then you wouldn't actually have this feature yet, and instead are letting Windows up-convert the video, which is known to have some issues.

And a SDR 3DLUT cannot be used, because 3DLUTs are designed to compensate for the screen response, so the original video format is much less relevant then the current screen mode - which would be HDR, and as such a SDR 3DLUT cannot be applied.

The Wait only triggers if MC actually changes the refresh rate, of course. And to trigger the refresh rate change, the FPS field in the library needs to be filled appropriately. As I understood it, Manni doesn't use the library, in which case refresh rate changing would not actually work.
The library is an essential part of MC, and we rely on its metadata to be available for some of the advanced features.

Thanks for this, that would be an explanation for the behaviour I experience. I'm sure SamuriHL can easily confirm this by either using MC as an external player or simply using JRiver to play a file using "open with" if MC isn't the default for that file type. I'll do tests as well as soon as I can to confirm if this is resolved when using MC's library and MC as a front end.

However, I'm afraid the rest is incorrect.

Although I haven't made sure that there was an actual refresh rate change in my latest tests while I was testing solely the delay (I will as soon as I have a chance and I'll confirm), refresh rate change works fine even when MC is called as an external player. Everytime. It also works fine when you play a list of video files in the files section of the library (I have a selection of test files there that I use to test various things). It has worked fine for years, though I've never used the HDR metadata until recently because I was using HDR to SDR tonemapping. And HDR Metadata also works fine if you enable the OS HDR before playback.

I understand that the wait/delay might not be triggered in that case. I will check that by adding a single title in the library, but if so that's just a big bug that should be fixed. Technically, there is nothing that prevents MC from looking at the frame rate info in the file and adjust the refresh rate accordingly (which I believe is what it does anyway) and to add the specified delay when needed.

JRiver MC is one of the best players if not the best player available today, but its library and front end interface is very limited compared to what I achieve with MyMovies/CMC: no WOL to start an offline server when a title isn't available, no lights control (I use Vera lights) to switch the lights off when a film starts and on when a film stops, no network playback with an iOS app to select a title on iOS with a superb front end interface and play it on a Dune or an Oppo, the MC front end interface itself is quite dated (at least on Windows) compared to CMC though I've not looked at it recently, the search feature in the front end is extremenly limited (I have nearly 4,000 titles in my collection and use custom filters and categories, support for TV Series is poor... The list is endless and I don't mind, that's not what I use MC for.

I purchase MC solely for its amazing capabilites as an external player, especially its great full menus feature (by far its unique selling point for me), excellent JRVR renderer (actively maintained and developed), compatibility with madVR 3D LUTs that I've started using etc. For years I've purchased MC without using it (even the master license to pay more when I didn't need one as I never used any non Windows license and only realised recently that it didn't support BD Folders on Mac, so was of no use to me) simply to support your excellent work in LAV, that I've been using for years in combination with madVR even when I wasn't using MC as a player and that you kindly make available to the community for free.

MC as an external player is great, and this has nothing to do with its library. Unless you commit to bridge the gap is has with the other solution I use (which I'm sure will never happen as I assume my use case in a dedicated cinema room is an edge case in your audience), please support it as an external player. Again, it's one of the best if not the best available, and I'm certainly not the only one to use it that way. It's also a documented use, with specific features implemented so it should be supported. In fact it is supported as recently some features were added (not by you but by another developer) following a suggestion I made, for which I'm very grateful.

FYI, MC itself is perfectly capable of not having any issues with HDR Metadata in HDR passthrough, you only have to use madVR. This proves that it has nothing to do with using the library.  As I mentioned, this HDR metadata issue only happens with JRVR, which I've also started using as my primary renderer because it's not only caught up with madVR but in my opinion it's today ahead of madVR for my use (HDR to HDR tonemapping to a 1,000+nits display), in part thanks to the great work you've done in MC32 to resolve the brightness stability issues I reported in MC31 and the significant progress made over the last couple of years in HDR to SDR tonemapping. It's not quite caught up in this last area, but I use HDR to HDR tonemapping currently and JRVR works fine for that use.

If you don't want or are unable to fix this, then please make the "SDR playback as HDR (BT2020 PQ) when OS HDR is enabled" feature introduced in build 49 work properly so that we can leave the OS HDR permanently enabled as a workaround. Currently gamma is wrong when using this new feature: as reported earlier, the picture looks washed out and I assume an SDR 3D LUT can't be used anymore as I understand it's disabled in HDR passthough (as it should be).

Failing a fix or workaround for this, my only option would be to go back to madVR, which I'd rather not do as I prefer JRVR at the moment for my use (mainly because until now I thought it was maintained and supported and that bugs reported were actually fixed). If bugs occuring when MC is used as an external player with JRVR are not fixed, that's a big advantage of JRVR that goes away for me.

End of rant

The Wait only triggers if MC actually changes the refresh rate, of course. And to trigger the refresh rate change, the FPS field in the library needs to be filled appropriately. As I understood it, Manni doesn't use the library, in which case refresh rate changing would not actually work.
The library is an essential part of MC, and we rely on its metadata to be available for some of the advanced features.

JRiver for Android does run on Android TV.  You can connect to JRiver Media Center running on another machine.

Hello

Wondering if there are any plans to make a Media Center client app for Android TV. Something where the primary use is to connect to our real Media Servers for playback only of music, photo albums, and our TV/Movie collections.

I understand that the challenge is that you dont know what codecs each TV manufacturer supports for playback. I wonder if this cant be overcome? Does android allow you to check installed codecs? Or could you have a sample of the common codecs and profiles and run a check for each file type on initial install? Then this client could essentially tell the server when it needs a transcode performed and what codec to use and what to do with subtitles.

I dont understand the technical barriers, just spitballing

Just want to say thanks for all the Image work to JRiver
Its great to now be able to see my processed toned photos with pretty previews inside Media Center. Also good that hard work done tagging locations and faces in Lightroom is now reflected in Media Center.

Would be great if Media Center added a Map view that filtered the photo list down to places visible on the map, like Lightroom has.

Also, does anybody have a good way of syncing Lightroom Collections to Media Center Albums or Playlists? I am guessing that adding a Keyword group called "Collections" and then manually tagging photos with the Collection names would be one way of getting the info over to Media Center, but manual and time consuming.