Ampache

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.


Tasklist

FS#129 - Multiple Database backend Support for Ampache

Attached to Project: Ampache
Opened by Rizwan Sarwar (golekipro) - Friday, 20 August 2010, 04:34 GMT-8
Last edited by Karl Vollmer (vollmerk) - Thursday, 28 April 2011, 06:03 GMT-8
Task Type Feature
Category Metadata
Status Unconfirmed
Assigned To No-one
Operating System
Severity Very Low
Priority Low
Reported Version 3.6.0-Dev
Due in Version Future
Due Date Undecided
Percent Complete 0%
Votes 2
Private No

Details

As Ampache is becoming more popular it is obvious that with wide range of feature set it has, it will be used by as a media front end by majority. The issue is that most users have lowend devices such as NAS Boxes/Media Player that can also run Linux. Ampache requires MySQL as backend which is unsuitable for most of these devices making Ampache unsuitable. However the solution is to use SQLite/BerkeleyDB as optional backend. Since PHP support ADODB, it is possible to have multiple database backends supported for same frontend. I believe a support for low resource DB's will greatly enhance performance of Ampache and make it viable choice for more people to use a centre of their media world.
This task depends upon

Comment by Elias Probst (eliasp) - Saturday, 04 December 2010, 22:23 GMT-8
I don't think support for DBs like SQLite or BerkeleyDB will actually improve performance, this might be just the case for other 'real' DBs like PostgreSQL etc.

But still, it makes IMHO a lot of sense to use a DB abstraction layer as it takes away a lot of complexity and potential trouble from the application itself.
Comment by Karl Vollmer (vollmerk) - Thursday, 28 April 2011, 06:01 GMT-8
The real issue here is that the queries would have to be abstracted to use more then one back-end database. The calls are already abstracted. Moving this to 3.6 dev not sure if it'd be added to that line, maybe something for the version after that.

Loading...