[Derek]

Save me installing all the GitHub software etc only have that on my unix boxes.

[hannes69]

I do need Reclock for PAL speed down though, so maybe I should just stop obsessing over this.

If you are already using Reclock and it is working for you without problems, yeah, you probably could stop obesessing over this
I haven´t used Reclock for a very long time, maybe it can be a source of problems too (like your wrong values of the clock deviation, maybe there is no real problem but rather a kind of cosmetic bug showing wrong values... just guessing)

Is the same audio clock of an HTPC used for all outputs, for example?

Hm good point. I don´t really know. I have a simple setup, I have a stereo professional soundcard and I use simple analog stereo outputs, nothing digital in the chain, no receiver and so on. There may be differences depending on the audio setup i guess.

[Uoppi]

I used to have spdif out and VGA out, back then. But it was before I really started caring about smoothness in video reproduction. So I'm really in the dark regarding how that influences clock deviation measurements, sorry.

No problem, maybe someone else can chime in.

Anyway, I just watched a movie with my customized 23.97625Hz resolution. Clock deviation stabilized around ~0.00090 with a frame drop expected once in under 4 hours. Reclock was disabled but I got no drops nor repeats and everything looked super smooth. So I'm happy with the outcome though I still don't quite know what to make of the numbers.

[gotham_x]

@Derek , last compilation Wanilton , Try this link.

[Derek]

@Derek , last compilation Wanilton , Try this link.

Thanks bud its working now mucho respect!

[Uoppi]

I haven´t used Reclock for a very long time, maybe it can be a source of problems too (like your wrong values of the clock deviation, maybe there is no real problem but rather a kind of cosmetic bug showing wrong values... just guessing)

Bingo! Thanks for mentioning that, turns out it was indeed Reclock messing with the numbers. The real deviation seems to be in the -0.00085 range so now I've just got a little math to do.

(I do get problems using Reclock with certain variable frame rate home videos: I need to manually specify the refresh rate in Reclock for each file to avoid occasional audio drop outs. It's a pain in the ass obviously and I'm not sure if having PAL speed down is that necessary.)

[ashlar]

I have moved the guide for madVR and limiting frame drops/repeats to Doom9: http://forum.doom9.org/showthread.php?p=1769704

[DragonQ]

Does anyone else use this version of Kodi with MediaPortal TV-Server? I have an issue with seeking whilst watching currently-recording shows. The easiest way to explain is through an example: let's say I start watching a show that has been recorded for 10 minutes, from the beginning. I seek ahead 5 minutes and it works as expected. After 15 minutes, it's still playing fine, as expected. However, if I now try to seek (either forward or backwards), it jumps back to the 10 minute mark.

I can see an issue that seems to be describing this bug here but it is marked as being fixed in Kodi 16. Not for me, it seems.

[Warner306]

Does anyone else use this version of Kodi with MediaPortal TV-Server? I have an issue with seeking whilst watching currently-recording shows. The easiest way to explain is through an example: let's say I start watching a show that has been recorded for 10 minutes, from the beginning. I seek ahead 5 minutes and it works as expected. After 15 minutes, it's still playing fine, as expected. However, if I now try to seek (either forward or backwards), it jumps back to the 10 minute mark.

I can see an issue that seems to be describing this bug here but it is marked as being fixed in Kodi 16. Not for me, it seems.

Are you using DSPlayer or DVDPlayer for live TV?

[Warner306]

@ashlar
Nice explanation of the target refresh rate! Please correct the typo "Target refresh rate = 23.97602 * 0.9999758 = 23.79544" in order to not confuse the people even more
Would be cool if you could explain in such a short compact practical oriented manner the second part of the story concerning the custom refresh rates (I´m not very good in explaining things SHORT

Unfortunately, as far as coming up with the correct (deviation compensating) refresh is concerned... there's A LOT of trial and error in my experience. Luckily CRU now includes the restart driver option which previously lacked (if I had to reboot for every check I made... I would have fallen asleep halfway through). I'm pretty sure that the trial and error stems from my lack of complete understanding of all the variables involved. I might study in the future, but I don't feel qualified to write an how to about it.

ALL THAT FOLLOWS IS WORTH A TRY AND IT SURELY GIVES A CLEARER IDEA OF WHAT GOES ON "BEHIND SCENES". I'VE HAD MIXED RESULTS WITH IT, SO FAR.

In any case, in my explorations of the web, I think that a wise combination of these three tools could help in coming up with resolution timings to try with CRU. Combining the three tools it's probably possible to limit the number of trials and errors, as DTD Calculator provides refresh rate results with many more decimal points, up to a precision that satisfies our needs:

Pixel Clock Calculator
Custom Resolution Utility (CRU)
DTD Calculator (this is meant for Intel GPUs but timings are the same for all GPUs, it's the implementation that changes)

With Pixel Clock Calculator you can come up with a bunch of settings to try in CRU.
In CRU you proceed to add a resolution, you set the refresh rate up to the third decimal (the maximum precision CRU offers) and then you try inputting the different totals that Pixel Clock Calculator offers. You are going to act on the Total and Refresh rate entries.
Some of them will not work (CRU will show the numbers you input in red, it has to do with the minimum values accepted, by playing with the Front porch and Sync width values you can solve it). Some of them will be accepted by CRU but will end up producing undesirable results (portions of the imag distorted or shifted with last pixels repeated till screen end, you'll see what I mean when and if you see them).
When you find one that works without producing a bad image and that is close enough to the refresh rate you desire, you can switch to DTD Calculator to have it calculate the refresh rate with more precision (to save the trials and errors).

But how to translate what you see in CRU to what you see in DTD Calculator?
Start off by inputting the Active entries (horizontal and vertical, 1920x1080 tipically) from CRU under the two entries "Active Pixels" (horizontal and vertical) in DTD.
You then sum the Front Porch value (from CRU) to active pixels to get the "Start of Sync Pulse" value for DTD.
Then you sum Sync Width (from CRU) to "Start of Synch Pulse" in DTD and you get the value for "End of Sync Pulse".
Then you sum Back Porch (from CRU) to "End of Sync Pulse" in DTD and you get the value for "End of Sync Pulse".
Then you input the Total value (from CRU) to "End of Blanking Interval" in DTD.
All of the above must be repeated for both horizontal and vertical values, clearly.
Lastly, take the Pixel clock value from CRU and input it in the same entry in DTD.

You will see that DTD in the bottom right corner provides the resulting refresh rate with much more precision than CRU (and if you hover on the value, with your mouse, it shows even more decimals).

You iterate the process from CRU to DTD until you come up with the closest approximation of the refresh rate you need. Then you use that in CRU and test with madVR. Hopefully it will provide you with what you need. As mentioned previously in the thread, the calculations are exact but the different graphic cards might require some offsets, which brings us back to more trial and error. With all these instruments... let's say we could be flying a little less blindly.

With all of the above I've managed to improve my 23.976 to the point where it oscillates between 6.x days and no frame-drops/repeats expected. I have no frame-drops/repeats expected for 50Hz as well and one frame drop between 3.5 and 4.2 hours at 59.94Hz. Color me impressed hannes69!

I linked to this post in the DSPlayer guide. Clean it up, add to it, or edit it. It doesn't matter. Just keep it in that post for others to read.

[DragonQ]

Does anyone else use this version of Kodi with MediaPortal TV-Server? I have an issue with seeking whilst watching currently-recording shows. The easiest way to explain is through an example: let's say I start watching a show that has been recorded for 10 minutes, from the beginning. I seek ahead 5 minutes and it works as expected. After 15 minutes, it's still playing fine, as expected. However, if I now try to seek (either forward or backwards), it jumps back to the 10 minute mark.

I can see an issue that seems to be describing this bug here but it is marked as being fixed in Kodi 16. Not for me, it seems.

Are you using DSPlayer or DVDPlayer for live TV?

DSPlayer. I don't really have any reason to use DSPlayer if not for live TV - anything else can be played via MPC-HC using MadVR anyway.

[ashlar]

I linked to this post in the DSPlayer guide. Clean it up, add to it, or edit it. It doesn't matter. Just keep it in that post for others to read.

Hi Warner, I tried to tidy it up a little, adding information so as to make it a "one stop" read for people interested.

[Warner306]

I linked to this post in the DSPlayer guide. Clean it up, add to it, or edit it. It doesn't matter. Just keep it in that post for others to read.

Hi Warner, I tried to tidy it up a little, adding information so as to make it a "one stop" read for people interested.

I discovered you shouldn't use ReClock for calculating clock deviations. It can be inaccurate (too low).

Note: ReClock is known to produce inaccurate clock deviation figures, even when bitstreaming. For an accurate clock deviation, try Sanear or the default audio renderer.

Also, the formula below may be easier to understand as it includes the conversion from percentage to decimal, which can be missed or overlooked:

movie frame rate * (1 +/- clock deviation / 100)

[ashlar]

I've added your note and formula, Warner306. Thanks.

[djoole]

Just to be sure to have fully understood.
If using reclock, there is no need to create a custom res in order to try and compensate A&V clocks deviation, because reclock is realtime synching the video to the audio, and therefore will procure a perfect A/V synchronisation.
Am I right?