INTERACT FORUM

Please login or register.

Login with username, password and session length
Advanced search  
Pages: [1] 2 3 4 5 ... 10
 1 
 on: Today at 08:20:18 pm 
Started by Manni - Last post by SamuriHL
Well that's fun.  It would seem you have some bug fixing to do, Hendrick.  :D

Here's what I can say.  Desktop set to 23.976.  Set custom res in display settings in MC to 23.976.  Set the delay to 0.5.  It doesn't give me metadata.  Now here's the fun part that's going to drive Hendrick absolutely nuts.  :)  Go set the delay to 1, play it again.  Metadata ensues like I'd expect.  BUT....if I THEN go set it back to 0.5 and play it again, it MIGHT sometimes have metadata.  LOL  The 1s delay always gives me metadata in every scenario I've tested.  But the idea that it's not doing anything with refresh rate when you have it set to custom and they match seems to be slightly untrue.  It may not be explicitly setting the refresh rate (or maybe it is and you don't see it because, well, they are the same) but it's definitely acting as though it's being set.

 2 
 on: Today at 06:44:17 pm 
Started by Manni - Last post by SamuriHL
I'm watching a movie at the moment as my long weekend is coming to a close.  However, if I get a minute before I go to bed after the movie is done I'll run a quick test and let you know.  Personally at this point I'm keeping the desktop at 120 and with the delay set to 1s everything just works.  But I'll set it to 23.976 as a test and set the delay back to 0.5.  I seriously doubt this will make any difference and I expect it'll just work but we'll know for sure later.

 3 
 on: Today at 06:37:53 pm 
Started by Manni - Last post by Manni
I don't have any more time for testing tonight.  But up until I changed that setting I had this issue and it was most definitely reproduceable.  But then I've always had the option to change refresh rate enabled since I stopped using madvr.  (And even when I switch back to madvr for, e.g. hdr testing to see how much they've improved it, I keep jriver's refresh rate changing active).  It's entirely possible I didn't have this issue when the refresh rates matched but who realistically keeps their desktop at 23.976, as an example?  It was always set to 60 on the desktop.  So I'm guessing that's why I always saw this problem.  When they match, I doubt the delay makes any difference whatsoever since it's not used but I can't confirm if that was true for me in the past at this point as, like I said, I never had the desktop at 23.976 so refresh rate changing would always happen.

I did keep my destop to 23p to limit the number of refresh rate changes, but of course I prefer to have it at 119p as it is now :)

I'm not saying that you didn't have the issue when the frame rate match, just that it's a good way to test if the delay actually makes a difference or not.

I think it would be interesting to see if you can get the issue back, because for me the delay makes zero difference, and it looks like it shouldn't make a difference either in your case if the issue doesn't come back when there is no refresh rate change, as Hendrik has explained that the delay was ignored when there was no refresh rate change.

 4 
 on: Today at 06:28:31 pm 
Started by Manni - Last post by SamuriHL
I don't have any more time for testing tonight.  But up until I changed that setting I had this issue and it was most definitely reproduceable.  But then I've always had the option to change refresh rate enabled since I stopped using madvr.  (And even when I switch back to madvr for, e.g. hdr testing to see how much they've improved it, I keep jriver's refresh rate changing active).  It's entirely possible I didn't have this issue when the refresh rates matched but who realistically keeps their desktop at 23.976, as an example?  It was always set to 60 on the desktop.  So I'm guessing that's why I always saw this problem.  When they match, I doubt the delay makes any difference whatsoever since it's not used but I can't confirm if that was true for me in the past at this point as, like I said, I never had the desktop at 23.976 so refresh rate changing would always happen.

 5 
 on: Today at 06:10:49 pm 
Started by Manni - Last post by Manni
Works fine for me.

Thank you very much for confirming. So even when there is no frame rate change and no delay, you get the correct HDR metadata when the OS HDR isn't enabled.

Then I'm wondering what has changed for you, given that increasing the delay can't be making any difference.

Have you changed anything else?

Do you get the issue again if you change the delay back to what it was before you increased it (0.5 sec if I remember correctly)?

 6 
 on: Today at 06:06:58 pm 
Started by TunesTalk - Last post by TunesTalk
giving up on running the Mac version of  MC 32   and figure it will be more manageable, all around,  on my laptop...Windows

however, with some of the glitches I ran into, I do want to be sure of not fouling up the original iTunes library...
so checking in to make sure about the proper procedure  before continuing with the process ...
the simpler...the better  :-\

thanx

 7 
 on: Today at 05:40:12 pm 
Started by Manni - Last post by SamuriHL
Works fine for me.

 8 
 on: Today at 05:16:51 pm 
Started by Manni - Last post by SamuriHL
Yea I can test in probably 20 or 30 minutes.

 9 
 on: Today at 04:51:37 pm 
Started by haggis999 - Last post by haggis999
Nudge, nudge...

I would be very grateful for an answer to the question in my previous post about displaying icons in Theatre View for multiple soundtracks, e.g. both stereo and surround sound?

 10 
 on: Today at 04:16:28 pm 
Started by Manni - Last post by Manni
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.

I am still confused about this, and as far as I can see the statement above is incorrect.

I double checked and as expected, automatic frame rate change is confirmed to work fine here, as it always has, even when launching MC as an external player from CMC.

To clarify, first re MC's auto refresh rate behaviour:

My desktop default frame rate is 119p, as most of the content I play is 23p.
If I play a 23p, 29p or 59p title, there is no refresh rate change (as expected) and no delay (as expected), content plays correctly at 119p.
If I play a 24p, 30p or 60p title, refresh rate changes automatically to 120p and content plays correctly.
If I play a 25p or 50p title, refresh rate changes automatically to 100p and content plays correctly.

This is exactly as per my custom settings in MC. It has worked since I started using MC to automatically switch refresh rates (although at the time I was using native refresh rates, no 119/120), after I reported a bug in madVR auto refresh rate that would fail with 24p BD folders, as it would select the refresh rate of the first file (often a menu or short file at 50 or 60p) and would not adjust to 24p for the main title.

MC auto refresh rate doesn't have this issue, so works correctly with all titles, even when MC is used as an external player.

This works fine whether the renderer is JRVR or madVR (with madVR auto refresh change disabled).

There is no situation in which the MC auto refresh rate doesn't work for me, whether I use MC to play a single file from a folder by clicking on it, play a file or a title from the MC library, or play a folder using MC as an external player called from CMC. So I still don't understand your statement quoted above, but as far as I can see it's not correct.

Now to explain how we got there, I reported that there was no delay for me when I did my last round of testing, but I think that's because my default rate is 119p and most of the content I played was 23p. So, by design, there was no refresh rate change, hence no delay. This is normal behaviour and precisely the reason why I chose a 119p default refresh rate for the desktop.

If I had inverted this and selected a 120p refresh rate for the desktop, I would get a sync (and a delay) with every title, and I guess that's exactly what SamuriHL experiences.

I tested playing a 24.00p file and in that case I do get a 3 sec delay (my current setting in the MC video options). Again, this is normal behaviour, I'm sorry I didn't think of making sure that a refresh rate change SHOULD happen when I last tested thing.

Up to this point, all correct, and apart from a brain fart on my part, no issue with auto refresh rate or the delay with MC, with library titles or as an external program.

Now where things start to be different here is the behaviour regarding HDR metadata, because I checked and if OS HDR is disabled, I don't get the correct HDR metadata, whether there is a delay / refresh rate change or not.

For example, with my 119p default refresh and OS HDR disabled, I play a 24.00 title, there is a 3s delay, a refresh rate change to 120p and I still get no metadata.

If I play a 23p title, there is no delay, no refresh rate change and no HDR metadata.

If I enable OS HDR before playback, playing the same titles, I get the same results re refresh rate change and delay, but I get the correct HDR metadata.

If I use madVR isntead of JRVR, I get the correct HDR metadata whether OS HDR is enabled before playback or not.

@SamuriHL, please could you change your default refresh rate to 119p instead of 120p and let us know if you still get the correct HDR metadata even if there is no refresh rate change and therefore no delay? Thanks!

Pages: [1] 2 3 4 5 ... 10