AtmoLight - 1.18.6.0 [2016-09-21] (2 Viewers)

[Rick164]

You can try out our attached native madVR build which is currently in development, make sure to disable madVR exclusive and D3D11 (D3D9 is best) with both this and the official release
It depends on the Mediaportal madVR build and madVR version as I've seen different results but generally this build should work fine.

 

[Kotik]

Thank you this one indeed works with D3D9.

 

[kenwonders]

Hey Rick!

As I've been talking about in PM, the ratio of refresh rate to delay nearly works for me, but there must be a little more to the calculation than (configuredrefresh/currentrefresh*configureddelay). The ratio also seems to be affected by my TV settings. I have done a little test work in AtmoWin to see if it's worth setting accurate settings for each refresh, avoiding the need for the ratio unless a strange refresh is used:

Of course, for any refresh not in the list (or unconfigured), the config can base the ratio on the nearest configured value.

Are you guys interested in this? I've done the work already but don't want to force anything on you

 

[Rick164]

Like it , only thing that comes to mind is how does it handle migration from the previous delay setting?
Preferably it would fill all the delay values there with the old single delay value as to not run the risk of having a delay of 0ms.

Can do a PR if you want and will check to see if we have any merge conflicts as DEV_TargetChangeImageRework branch will be merged to DEV this week in preparation for the official release so can include it once tested

 

[kenwonders]

Like it , only thing that comes to mind is how does it handle migration from the previous delay setting?
Preferably it would fill all the delay values there with the old single delay value as to not run the risk of having a delay of 0ms.

At the moment, any 0ms is ignored as 'unconfigured', any refresh rate that occurs that does not have a matching config has a delay calculated on the nearest available configured rate.

I hadn't thought about migration, or the MP menu option

Can do a PR if you want and will check to see if we have any merge conflicts as DEV_TargetChangeImageRework branch will be merged to DEV this week in preparation for the official release so can include it once tested

Ok I'll work out a migration strategy (likely read the old config value and put its delay value where it matches with available rate, it will probably be the default 50 this will result in the same AL behaviour)
Not sure what to do about the MP menu option though. Happy to work that out (any ideas?) before I throw it over to you.

 

[Rick164]

Can do the MP menu so that's no problem, we need an additional sub menu with this (for each refresh rate) but is easy to implement

 

[kenwonders]

Ok I'll throw you a patch once I've cleaned up my code in Plugin.cs, probably tomorrow sometime.

 

[Rick164]

Take your time , if we need to delay the official release a bit so be it as we probably need to re-test a few other things as well so better to have a longer test period.

 

[Rick164]

AtmoLight 1.18.5.0 was just released and would like to welcome @kenwonders to the team , he recently reworked the delay code so that for all the most common refresh rates you can pick different delays (see below for more info)

Frame handling

Improved the way we process the video frames so that with multiple handlers / targets they get split up and no longer can affect playback as it's now an background process with a circular queue, this will mainly affects users with either slow or variable processing speeds like AmbiBox or when it's over a slow or unstable network with Hyperion.

Delay handling

This consist of 2 parts, mainly:

1. Improving the background thread
2. Improve the delay references to allow for more control

For the first part we merged the delay code into the new queue so that is no longer separate and always in sync, this also lowers resource usage and is more precise with an average 1ms offset.
Second part was done by @kenwonders as before we had 1 configurable reference rate (default 50hz) however with some setups it will be preferable to have multiple as they behave differently depending on refresh rate, so in both the AtmoLight configuration menu and its context menu you can setup multiple references for all the common ones.
If it doesn't matches like with 60hz content for instance it will use the closest one so that would be 59hz in this case.

Philips Hue

In the AtmoLight Hue tab you now have the option to still use the VU meter effect when theater mode is active and in the AtmoLight context menu you can toggle Theater mode on/off for easy switching.

MadVR support (BETA)

In the previous build we have added support for madVR and this has since been improved thanks to @Sebastiii , you now however need to install a separate AtmoLight build for it as currently this will only work with the Sebasstiii Mediaportal builds located here:

https://forum.team-mediaportal.com/threads/madvr-support-in-mp1.133972/

The AtmoLight download link for this is in the first post from this thread and it's in sync with the normal release, madVR support is no longer in the standard AtmoLight release but only in this one.

Misc improvements

• Ambibox code has undergone some small changes and will behave better although their API / Memory map still behaves differently now and again resulting in variable delay.
• Delay timings changes done in AtmoLight context menu are now stored and allow for per reference changes during playback or idle, it will highlight the correct reference during playback (if exact match)

 

[kenwonders]

Thanks for your kindness, help and hospitality Rick

Ambibox code has undergone some small changes and will behave better although their API / Memory map still behaves differently now and again resulting in variable delay.

I might not get anywhere but I am looking into this. (read: messing about looking for gains )