-
Notifications
You must be signed in to change notification settings - Fork 186
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
thumbnails: extract pictures from audio files #7491
Conversation
Thanks for opening this pull request! The maintainers of this repository would appreciate it if you would create a changelog item based on your changes. |
093d4ad
to
9f4d41f
Compare
9f4d41f
to
0b88ef8
Compare
Updated and CI fixed |
Kudos, SonarCloud Quality Gate passed! |
LazyReadSeeker removed, log.Fatal removed, Changelog added. Good to merge from my end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fine for now!
The read seeker should be implemented on a higher level.
We need to support range requests because we cannot afford too much traffic on the platform.
Nice, thanks! |
thumbnails: extract pictures from audio files
Description
This PR uses https://github.com/dhowden/tag to extract pictures from audio files in the thumbnails service.
Related Issue
Motivation and Context
It would be nice to show appropriate cover images for audio files in the Web UI.
The main problem for now (which can totally be solved in another iteration is that not every audio file has embedded cover artwork, so on a page with a bunch of audio files, we would likely trigger a lot of status 500 requests.
This is my pet peeve, no company task - while reviews are personally appreciated, there is no priority.
How Has This Been Tested?
Screenshots (if appropriate):
Types of changes
Checklist:
Followup tasks
It would be nice to know in advance whether a thumbnail is available or not - via propfind or graph api. For that we likely need to store thumbnail information in the metadata - but who would be responsible for that? thumbnails service, search service, ...?
AFAICT tika does not extract image information from audio files - so we would need to duplicate some of the functionality here in the search service to write thumbnail information to the metadata. The thumbnail service does not generate images before they are requested, so we would have the information only on the second directly listing, so search service seems like a better fit actually...