Logcat reports this error: FrameEvents: updateAcquireFence: Did not find frame.

[DaleHensley]

Describe the bug
During investigation of #634, it was noted that the following error occured 2885 time on a Pixel 5 phone running Andorid 12 during the creation on an MP4 video of the "002 Lost Coin" bloom file:

FrameEvents: updateAcquireFence: Did not find frame.

This error did not impact the video.

To Reproduce

1. Steps to reproduce the behavior:
2. Load a clean version of "002 Lost Coin.bloom" into the device.
3. Execute Story Producer app and "002 Lost Coin" should appear in the "Story Templates" list.
4. Select "002 Lost Coin" and the "002 Lost Coin" story is loaded.
5. Go to the "Accuracy Check" phase and approve all the slides.
6. Begin capture of the logcat logs from the phone
7. Go to the "Finalize" phase and enter a field in "Local Credits" and use the word "Coin" for "Text in Filename". Then select the following option: "Include Pictures". Once this data has been entered, press the "Create Video" button.
8. A status bar appears showing the progress of the creation of the video.
9. When the video has completed, stop capture of the logcat file.
10. View error messages in the logcat log file.

There were Unexpectedly 2885 "FrameEvents: updateAcquireFence: Did not find frame" error messages in the logcat log file.

Expected behavior
Rerun the above steps on a Samsung phone (SMJ720F) running Android 10 during the creation of an MP4 video of the "002 Lost Coin" story and Expectedly, there were no "FrameEvents: updateAcquireFence: Did not find frame" error messages in the logcat log file.

Versions of the software and Android
-StoryProducer Version: 3.0.6
-Android Version: Android 12/Pixel 5 phone, Android 10/Samsung phone

Additional context
For the Pixel 5 Phone running Android 12, there are two log cat files enclosed. A12Pixel5PxAllLogcatData.txt contains all the log messages that occurred during the video creation and A12Pixel5PxErrLogcatData.txt contains only the errors that occurred during the video creation.

A12Pixel5PxAllLogcatData.txt
A12Pixel5PxErrLogcatData.txt

For the Samsung phone (SMJ720F) running Android 10, there are two log cat files enclosed. A10SamsungPxAllLogcatData.txt contains all the log messages that occurred during the video creation and A10SamsungPxErrLogcatData.txt contains only the errors that occurred during the video creation.

A10SamsungPxAllLogcatData.txt
A10SamsungPxErrLogcatData.txt

The source code that produces the error can be found here:

https://android.googlesource.com/platform/frameworks/native/+/master/libs/gui/FrameTimestamps.cpp

The sections above are all that's needed for a report. The following sections are filled out and groomed by the development team before work begins...

To Do:

• Do __
• Do __

Acceptance

[steps to verify that the fix works as expected]

Testing Ideas

[Tips for the testers. If you include detailed steps, use the 'Steps to Reproduce' format.]
__

Original Report from __

indented quoted text
is good but optional

[johnml1135]

The only intelligent thing I can find on the internet is here: pedroSG94/RootEncoder#1003
There is a code commit here, claiming to resolve the issue: pedroSG94/RootEncoder@812078d
Here are a few observations:

• They have a "hardware mode" and not "hardware mode"
  • a primary difference is using surface.lockCanvas(null); vs surface.lockHardwareCanvas()
  • Setting hardwareMode to false appears to happen somewhere else in the code
• They are using 2 surfaces (I don't fully know why - they are rendered one after the other

I would look into the "surface.lockCanvas() vs. surface.lockHardwareCanvas() when using the software or hardware codecs. I think that may be the issue.

[DaleHensley]

John: Thanks for the tip. Switching to the Surface.lockCanvas() got rid of the "FrameEvents: updateAcquireFence: Did not find frame." error for API 30 & 31. The error was not present in API 28 and 29. I did an analysis of the lockCanvas vs the lockHardwareCanvas across phones/emulators and in almost all cases lockCanvas ran faster than lockHardwareCanvas. Unless you have an objection, I plan to submit a fix to change the lockHardwareCanvas to lockCanvas. I am assuming that by using lockHardwareCanvas that we are using the hardware Codec. If this is true, it doesn't seem like the hardware Codec is a good fit for us. Let me know if you have any questions or have any feedback. THANKS AGAIN In HIM Dale Below is a summary of my findings. The green hightlights are the results using lockCanvas [image: image.png]

…

On Mon, Apr 4, 2022 at 8:29 AM John Lambert ***@***.***> wrote: The only intelligent thing I can find on the internet is here: pedroSG94/RootEncoder#1003 <pedroSG94/RootEncoder#1003> There is a code commit here, claiming to resolve the issue: ***@***.*** <pedroSG94/RootEncoder@812078d> Here are a few observations: - They have a "hardware mode" and not "hardware mode" - a primary difference is using surface.lockCanvas(null); vs surface.lockHardwareCanvas() - Setting hardwareMode to false appears to happen somewhere else in the code - They are using 2 surfaces (I don't fully know why - they are rendered one after the other I would look into the "surface.lockCanvas() vs. surface.lockHardwareCanvas() on the hardware vs. software canvases. I think that may be the issue. — Reply to this email directly, view it on GitHub <#639 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ASW7JVRDKQYTD3UV6ZPY3KLVDMDFZANCNFSM5SOKQ52Q> . You are receiving this because you authored the thread.Message ID: ***@***.***>