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

[Rick164]

Was just going thru the Lightpack help topic because this is where we troubleshooted the previous bugs which resulted in a running setup for some at least and that was with 2.1.7 as that has Mediaportal Direct (thought 2.1.6 had it as well)
Can you send me the Mediaportal.log and Mediaportal-error.log from C:\ProgramData\Team MediaPortal\MediaPortal\log just after having running into the errors (10-20s lag)?

/ edit

Hmm no errors most likely means it's at the Lightpack / Ambibox end, can you try Ambibox with the following settings:

- FPS 10
- FPS 24
- FPS 50
- FPS 60

And see if the lag interval changes at all.

 

[Lightning303]

Hm, I see, but I don't know how to configure AmbiBox 2.1.6 to work with AtmoLight. It only comes with the XBMC option - or is that sufficient?

With AmbiBox 2.1.7 the MediaPortal logs show no errors whatsoever.

Yes, XBMC option is actually the same as MediaPortal option. The problem with 2.1.6 is that AmbiBox had a bug in their API server that will crash AmbiBox if you send commands that are too long. This however has nothing to do with the live mode. As I mentioned before, its a bit strage . Rick is handling AmbiBox atm, as he worked on it last and is up to date on the code, just fyi .

 

[Spooky]

Ok, thank you, I will try again with AmbiBox 2.1.6 and the different FPS settings in AmbiBox

 

[Spooky]

Hmm no errors most likely means it's at the Lightpack / Ambibox end, can you try Ambibox with the following settings:

- FPS 10
- FPS 24
- FPS 50
- FPS 60

And see if the lag interval changes at all.

Ok, I have now tried AmbiBox 2.1.6 with the following Settings:

• FPS 10
• FPS 30
  
• FPS 60
• FPS MAX

Nothing changed unfortunately, the problem stayed the same, regardless of the settings and the AmbiBox version (2.1.6 or 2.1.7). The only difference was, that with FPS 10, the LEDs always lagged a little bit behind obviously - but other than that even with FPS 10 there were these "freezes" where the LEDs do not update to the current frame's colors at all for about 2 or 3 seconds.

Could it be that AtmoLight is simply not sending anything to AmiBox for that period of time for some reason? Or it keeps sending an old frame. Without creating an error in the log.

 

[Rick164]

Some errors do get suppressed at it would otherwise flood the logs, on every frame error would result in max 60 log lines per second for instance.
Attached test build with a minor tweak which might help reduce lag and also logs every frame error so this can create large log files so recommend only running this for debugging.

Old frames right now can happen as we have to wait for the AmbiBox header from the memory stream method, with the last fixes from the official release I added a wait timer (2.5s) where after we discard the frame (while accepting new ones at the same time) because sometimes AmbiBox failed and we would wait forever.
Most of it are workarounds which we don't usually need but are because AmbiBox acts up now and again without any way of knowing why.

Do have something on my todo-list and that is queuing for all targets where we always use the newest frame and discard old/expired ones so that we never get an old frame (FIFO queue)
Just needs a bit more work and testing before that is ready

 

[Spooky]

Some errors do get suppressed at it would otherwise flood the logs, on every frame error would result in max 60 log lines per second for instance.
Attached test build with a minor tweak which might help reduce lag and also logs every frame error so this can create large log files so recommend only running this for debugging.

Thank you, I have attached the logs while using this version. However, there are still no errors, as far as I can see :|. Also with this version it felt like this error was happening a lot more. Every ~4 seconds the LEDs are "frozen" on the last frame for 2 to 3 seconds.

Old frames right now can happen as we have to wait for the AmbiBox header from the memory stream method, with the last fixes from the official release I added a wait timer (2.5s) where after we discard the frame (while accepting new ones at the same time) because sometimes AmbiBox failed and we would wait forever.
Most of it are workarounds which we don't usually need but are because AmbiBox acts up now and again without any way of knowing why.

Hm, that actually sounds like this is what's happening on this system - since the amount of time where the last frame is visible is about 2.5 seconds.

Too bad it's so difficult to send the frames to AmbiBox, do you think you can work around this issue?

Well, may be we end up using a RaspberryPi Zero + Hyperion after all . I am guessing that will be a more stable solution.

 

[Rick164]

Attached new test build which reduces the wait time to 50ms, might help a bit as it will discard obsolete frames more often or overload AmbiBox
Hyperion is definitely a better option and Lightpack leds can work with it so only need Raspberry + Hyperion installation.

 

[Spooky]

Attached new test build which reduces the wait time to 50ms, might help a bit as it will discard obsolete frames more often or overload AmbiBox

Yep, that alleviated the problem, to some degree. Of course you still notice it, since it will take 50ms until the LEDs are updated again when this problem occurs, but it's of course a lot less noticeable than the 2500ms from before .

Hyperion is definitely a better option and Lightpack leds can work with it so only need Raspberry + Hyperion installation.

Yep, I know, I use it myself as well (RaspberryPi with Kodi + Hyperion + Lightpack). Do you think the new RaspberryPi Zero has enough power for this task?

 

[Rick164]

That's at least some good news, let's try 1ms and see if it can still run for extended periods without flickering

Yep, I know, I use it myself as well (RaspberryPi with Kodi + Hyperion + Lightpack). Do you think the new RaspberryPi Zero has enough power for this task?

40% faster than rPI1 so cpu wise it's fine, usb uart needs to support > 115200 baud rate (not sure if Lightpack needs it but Arduino solution does) so if it does that it will work so long as OpenElec + Hyperion support it.

 

[Spooky]

That's at least some good news, let's try 1ms and see if it can still run for extended periods without flickering

So far it runs without problems. How would I actually notice, if it starts to fail? Will AmbiBox crash and/or the LEDs go black?

40% faster than rPI1 so cpu wise it's fine, usb uart needs to support > 115200 baud rate (not sure if Lightpack needs it but Arduino solution does) so if it does that it will work so long as OpenElec + Hyperion support it.

Ah I see. Well we'll simply test, it's very cheap anyway