This reverts commit d5c4887a, reversing
changes made to 32b1a5ef.

Frodo English spelling corrections English/strings.po 

fixed: Streamdetails & resume-bookmark saving etc. for bluray folders di...

[lang] Update of language files from Transifex

fixed: We can only obtain the aspect & duration this way when the Proces...

[Frodo] Don't block waiting for EOS in audio/video players

Currently we block in OMXPlayerAudio/OMXPlayerVideo from the point we see EOF from demuxer,
until the last frame/audio sample has been played out. This can be a few seconds.
It means no more messages (such as abort) can be received during this period.
This results in a bug where if you press stop after the demuxer EOF has occurred it takes
a long time to stop. You would expect this to be the few seconds of queued data,
but it actually turns out to be 30 seconds, as the clocks get stopped by the stop message,
but the players never find out and we hit a timeout.
It also stops seek/pause working during the playout period.
It also stops (graphical) subtitles from being rendered during this time.
The fix involves not blocking for the EOS, but allowing the polling from OMXPlayer to catch it.

Allow dashes in music videos on the first pass

When the global volume has been set low, and a sequence of tracks are being played, there are complaints of occasional jumps to full volume.
This is down to a race condition where the volume request can arrive at OMXAudio before it has been initialised.
The fix is simple, don't send the volume change until m_CurrentAudio.started.

Currently, once demuxer has reached EOF, we send the EOF messages to audio/video players
and set their inited/started flags to false. But if started is false we ignore any
PLAYER_DISPLAYTIME coming back from players, which stops the elapsed time from updating.
This can affect the final ~8 seconds of the file.

The fix delays changing these flags until audio/video players have signalled EOS.