It’s been suggested that the “Previous volume not finished” error is sometimes a red herring - something else is blowing up but not interrupting the job when it should thus allowing the previous volume error to happen.
If you don’t do a repair and re-run the backup does it work?
As a test only, does it work if you enable the --no-backend-verification parameter?
As far as the speed of the file counter, it’s possible you’re seeing the difference between new files / changes being backed up (slower) and already backed up files being verified as un-changed (faster) or having matching blocks to already backed up files.
For example, if your raw images were all of a solid red wall then it’s possible many of them have 500KB chunks of matching data so the first file would be slow as it’s processed and written to the database while the following ones would be faster since the block doesn’t need to be written anywhere.
Granted that’s a very unlikely scenario with photos…
If you look at the main Log -> Live -> Profiling section when the faster file count is going, what sorts of items do you see being logged? Alternatively, you could try running with --log-file=<path> and --log-level=profiling parameters to generate a text file of the log of a run.