ClockImpl.java/AbstractPlayer.java keeping of a 'rate' variable vs actual
ClockImpl.java/AbstractPlayer.java keeping of a 'rate' variable vs actual rate proves to be an issue with 'getRate()'.
To boil things down to its most basic elements, we have this DVR application that does some things during the course of its life that exercise certain issues that may prove to be something that could better be handle in the ri stack.
It changes state by issuing a 'new' to many classes that owe lineage to AbstractPlayer. The problem is, when a 'new' happens to a class that inherits from AbstractPlayer, it has no clue what playback rate the box/drivers is currently really at from 'getRate()', until we set it via setRate(), and the local private 'rate' variable in ClockImpl.java is updated.
For instance: Say we're playing back a recorded event at a rate of 2.0 (so 2x fast forward). Then for whatever reason, we want to completely unload the application in a manner of our choosing. Now we load it back up, query the rate via 'getRate()', and we will see that we're at a rate of 1.0---what the cache variable has been initialized to, even though the underlying layers have been busy pushing video at 2x. We call 'setRate()' to 4.0, and everything synchronizes with what we would expect until things are unloaded again.
I have no other ideas other than to query the drivers in a manner similar to how we percolate a setRate() message down to the drivers. Changing the local private rate in ClockImpl.java to 'static' works as a workaround, but the consensus is that's probably a bad idea.
The only workaround I've seen, is listening to the callback that gets called with the new rate when we call setRate(), and saving a 'current rate' locally within the application, but that isn't without its issues as well.