I published a free screensaver a few years ago : BPOD
It has worked pretty flawlessly until what I believe is the Roku 12 update. Since then there has been a very weird and rare problem that I was able to capture in this screenshot:
The clock should display: "20:14" the : and 4 are missing
The screensaver displays an image (retrieved from Bing) and a clock. All the digits (and the colon) are embedded in the app. They are not fetched from the network.
The clock code is this:
<component name="Clock" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" extends="Group" xsi:noNamespaceSchemaLocation="http://rokudev.roku.com/rokudev/schema/RokuSceneGraph.xsd">
<children>
<Poster id="h0" translation="[0, 0]" width="66" height="92"/>
<Poster id="h1" translation="[56, 0]" width="66" height="92"/>
<Poster translation="[98, 0]" uri="pkg:/images/clock_separator.png" width="66" height="92"/>
<Poster id="m0" translation="[139, 0]" width="66" height="92"/>
<Poster id="m1" translation="[195, 0]" width="66" height="92"/>
<Timer id="tickTimer"
repeat="true"
duration="1" />
</children>
<script type="text/brightscript" uri="pkg:/components/Clock.brs"/>
</component>
Each digit is computed in the Clock.brs script and assigned to each poster something like:
m.top.findNode("m1").uri = "pkg:/images/clock_4.png"
I don't understand why
a) this can ever fail because the images are embedded, especially the colon which is only ever created/assigned in the xml file, never via code
b) it happens rarely: either it should always work or always fail again because the images are embedded, not relying on a server being up
I don't even know how I could detect that there was an error loading the Poster in the first place and even so what I could do to fix it.
As I pointed out earlier, this issue never happened until Roku 12.
Any help would be appreciated
Thanks
Try adding "loadSync=true" to your posters.
@renojimThank you for your response. I will give this a shot.
Unfortunately, loadSync="true" does not fix the issue.
I changed the code to display all digits so that it is easier to stop/start the screensaver and see if there is an issue. And whether I use loadSync="true" or not, the issue always pop up after a few tries (less than 20)...
The code could not be simpler:
<component name="Digits" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" extends="Group" xsi:noNamespaceSchemaLocation="http://rokudev.roku.com/rokudev/schema/RokuSceneGraph.xsd">
<children>
<Poster id="d0" translation="[0, 0]" uri="pkg:/images/clock_0.png" width="66" height="92" loadSync="true"/>
<Poster id="d1" translation="[56, 0]" uri="pkg:/images/clock_1.png" width="66" height="92" loadSync="true"/>
<Poster id="d2" translation="[112, 0]" uri="pkg:/images/clock_2.png" width="66" height="92" loadSync="true"/>
<Poster id="d3" translation="[168, 0]" uri="pkg:/images/clock_3.png" width="66" height="92" loadSync="true"/>
<Poster id="d4" translation="[224, 0]" uri="pkg:/images/clock_4.png" width="66" height="92" loadSync="true"/>
<Poster id="d5" translation="[280, 0]" uri="pkg:/images/clock_5.png" width="66" height="92" loadSync="true"/>
<Poster id="d6" translation="[336, 0]" uri="pkg:/images/clock_6.png" width="66" height="92" loadSync="true"/>
<Poster id="d7" translation="[392, 0]" uri="pkg:/images/clock_7.png" width="66" height="92" loadSync="true"/>
<Poster id="d8" translation="[448, 0]" uri="pkg:/images/clock_8.png" width="66" height="92" loadSync="true"/>
<Poster id="d9" translation="[504, 0]" uri="pkg:/images/clock_9.png" width="66" height="92" loadSync="true"/>
<Poster id="d:" translation="[560, 0]" uri="pkg:/images/clock_separator.png" width="66" height="92" loadSync="true"/>
</children>
</component>
I hate to always bug @RokuBen , but maybe he has an idea and if he reads this Scene Graph desperately needs a "redrawAll" function. I've seen all kinds of strange things like this since 12.0 or 12.5 with missing posters.
I've already been looking into this today, looks like it may be an issue with the new graphics compositor that was added in 12.0. I've been able to reproduce in 12.5, but not the in-development tree, so this may have already been fixed.