FIX: Allow "Scan for new content" on folders
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.
[lang] update of internal addon language files
[lang] update of core language files
[lang] update of skin.confluence language files
[lang] added langinfo.xml for new language Latvian
[lang] added langinfo.xml for new language Faroese
[lang] added langinfo.xml for new language Welsh
correct date formats. fixes #14286
sync scrapers with repo
fixed: The db check for streamdetails was wrong
fixed: Streamdetails & resume-bookmark saving etc. for bluray folders didn't work (fixes #14288)
fixed: Freezing when player fails to queue the next song (fixes #14297 #14231 #14229 #13919)
fixed: DVDPlayer GUI display time not updating near the end of file (fixes #14299)
[vda] disable use of cvBufferRef for 12.2+
bump version to 12.2
ADD: [droid] libstagefright dvdplayer hw codec
fix EGLWrapper
[stagefright] backport fixes]
[droid] bump librtmp to 2.4

Conflicts:

	tools/android/depends/samba/Makefile