Resolve text corruption by using a local StringBuilder and storing the formatter in a ThreadLocal.

Description

This is a modification of the medialibrary interface to use a local StringBuilder for constructing the human readable string of the length field, instead of a static StringBuilder. It also moves the static NumberFormat into a ThreadLocal, as formatters are not thread safe. The ThreadLocal is a good compromise because it provides a thread-safe, cached object which can be repeatedly re-used.

Motivation and Context

On occasion, I have observed the timeline jump between millisToText and millisToString. This is a result of re-using the same buffer across two different threads, not two different pieces of code invoking a different method bound to the same variable.

How Has This Been Tested?

This has been tested both deployed on a device with a long playlist, and reproduced in unit testing. After fixing the objects with shared internal buffers, corruption no longer occurs. A unit test was written to confirm the behavior is now corrected.

During debugging, I observed the method being invoked on the "main" and "DefaultDispatcher-worker-#" threads back to back, so it's just a race condition waiting to clash at runtime.

Types of changes

• Bug fix (non-breaking change which fixes an issue)

Checklist

• I have read the CONTRIBUTING section of the README document.