This repository has been archived by the owner on Jun 10, 2020. It is now read-only.
Fast seeking [may] not be enabled for WAV files #11
Labels
Comments
atruskie
added a commit
to QutEcoacoustics/baw-server
that referenced
this issue
Oct 9, 2020
Fixes QutEcoacoustics/baw-audio-tools#11 It looks we had slow cutting speed that scaled linearly with seek time. For long files, cut speed was nearing 8 seconds! Added benchmarks as tests which should prevent future regressions. Also include various tweaks and simplifications to the workers initialization code (it was necessary for debugging). Also: - ensures workers bootsnap uses the correct tmp folder - Adds a larger test fixture needed to test these sorts of problems - Ensures ffmpeg is never interactive - Ensures ffmpeg will overwrite files in race conditions - Ensures redis communicator actually uses namespace option from config file - Adds a sanity check to the multi-logger formatter setter to see if we can track down a persistent issue of Resque overwriting our formatter. See check_resque_formatter. - ensures fixture pathnames exist by default - enabled LFS to support large fixtures
6 tasks
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
This issue is hard to track down, but recently we've seen our average cut time for media jump from 4 seconds to 10.
Our new relic histogram also indicates that a good percentage of users are seeing 15 seconds load times or worse.
There a number of factors that could be causing this, including the fact that we were moved to slower storage recently. However, users consistently report slower load times near the end of their files.
We need to make sure fast seeking is always occurring for cutting out a segment of a wav file
The text was updated successfully, but these errors were encountered: