Define some test cases for library scanning #9
Description
We are in the process of building an integration test suite library migrations (testing the process of a user changing files between scans of the filesystem).
We will just define some test cases in natural language in this issue and check them off as the test is implemented.
- Recover from deletion: the first state has a book, second doesn't, it's back in the third state
- Book get's renamed
- Work with moved audiobooks:
- In the first state the book is called 'lol', in the second it is called 'rofl', file contents are the same
- In the first state the book is called 'lol', in the second it is called 'rofl', file contents are the same but there is a new book also called 'lol'
- The hash should probably get precedence
- Book with same name has different file contents
- Book get's deleted, shows up with different content again
- What should even happen here if we see a book with the same name but different hash? I think that when in doubt we should keep the playstates. Manually starting playback from 0 isn't exactly hard to do, but finding the time code you last listened at could be really annoying.
- Multifile book is updated.
- Make sure it's remuxed
- Multifile audiobook gets new file
- Make sure it's remuxed again