Do not issue any bug reports against versions earlier than 3.5.4 they will be closed.
Furthermore, we cannot accept bugs about metadata or art handling in 3.5.4 due to the large number of bugs that have been fixed since then. 3.5.4 in general is becoming less supportable, and it is suggested to try to reproduce the bug in the latest nightly.
Before submitting a bug please read http://ampache.org/wiki/support:bugs failure to do so may delay resolution of your report.
Furthermore, we cannot accept bugs about metadata or art handling in 3.5.4 due to the large number of bugs that have been fixed since then. 3.5.4 in general is becoming less supportable, and it is suggested to try to reproduce the bug in the latest nightly.
Before submitting a bug please read http://ampache.org/wiki/support:bugs failure to do so may delay resolution of your report.
FS#118 - Serve album art from filesystem instead of DB
Attached to Project:
Ampache
Opened by Jesaja Everling (jeverling) - Friday, 02 July 2010, 02:31 GMT-8
Last edited by Karl Vollmer (vollmerk) - Friday, 29 October 2010, 05:48 GMT-8
Opened by Jesaja Everling (jeverling) - Friday, 02 July 2010, 02:31 GMT-8
Last edited by Karl Vollmer (vollmerk) - Friday, 29 October 2010, 05:48 GMT-8
|
DetailsI think it would be great, if there was an option to serve static image files directly from the filesystem, instead of having the files in the DB.
Art from id3 etc. could still be served from the DB, for static image files it should be possible to choose if the file should be inserted into the DB or directly retrieved from the filesystem (as other media files are). I don't really see any advantage of having image files duplicated in the DB, and with high-quality files this can eat up a lot of space unnecessarily. |
This task depends upon
Closed by Karl Vollmer (vollmerk)
Friday, 29 October 2010, 05:48 GMT-8
Reason for closing: Won't fix
Additional comments about closing: I don't see any reason to add this complexity. They are saved in the DB to avoid the need / trouble of saving to the FS and there isn't really a good argument as to why they shouldn't be stored in the DB.
Friday, 29 October 2010, 05:48 GMT-8
Reason for closing: Won't fix
Additional comments about closing: I don't see any reason to add this complexity. They are saved in the DB to avoid the need / trouble of saving to the FS and there isn't really a good argument as to why they shouldn't be stored in the DB.