Add structures for chapter parsing #38
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Most podcasts implement chapters inside of the media files, which are currently not parsed by Tape Drive. The more sound approach though is the use of a podcast's feed to deliver chapter information, as the feed is parsed anyway and the media files should not have to be touched to deliver metadata – the only implementation that I know of is the @podlove specification of "Podlove Simple-Chapters" which are easily parsable from the feed.
This PR implements parsing of podlove's simple-chapters into a a dedicated database structure, and basic front-end display in the episode details modal as a chapter list. Future extension will have to be implemented separately, especially considering the planned front-end restructuring via #37.
All future implementations to parse chapter implementations of other kinds will be mildly forced to comply with the simple-chapters structure of basically four parts of relevant info (as of simple-chapters spec v1.2):
To stick with the general theme of Tape Drive (moving relevant information into the database, instead of fetching it on demand), chapter imagery is downloaded at time of feed/chapter parsing and saved to the filesystem for later use.
In addition to that, the PR subtly adds Django Rest Framework as a dependency as a starting point for a new proper api implementation.