Project still alive?

[nakinigit]

Just curious.

[a7medo778]

As i understood there is a change in leadership that happened just 2 weeks ago

The project in general is due for some updates in terms of library updates, subsonic catchup and fixes But personaly i cant complain since i am not a developer and i havnt been contributing, that being said i really do hope the project catch up in popularity with the prev devs to push it ahead, now even projects like madsonic are getting way ahaead

[vollmerk]

I'll likely never have time to give this project what it deserves so I'm looking for someone to take the reins, I have enough free time to keep it's head above water but that's likely it.

[wagnered]

@vollmerk and @Afterster,

I am considering "taking the reigns". I have been working with Ampache for the last 3 years, Mostly with the video section.

I have taken the liberty of checking out the Laravel branch out of curiosity. I have gained a more than moderate understanding of Laravel. and have attempted to follow up on Afterster's work: fixing typos, and implementing Admin=>User Tools.

Granted, I don't have a whole picture of Ampache-3.83-develop, primarily because of it's disorganisation and lack of documentation, but Laravel's Architecture Concepts lead to an understandable organization of the project.

Last but not least, I am retired, so I will have time for development of Laravel Ampache.

I am a bit reserved about jumping right in because I don't know what I don't know, such as managing the github project and other oversight tasks.

Regards,

Ernie

[nakinigit]

Well, I have seen a lot of progress since about mid 2013, when @Afterster & @Psy-Virus got involved. If you think documentation is scant now, you should have seen it back then!

Anyway, hate to see the project die, seems just as it was coming into it's prime. For Android, anyway, I'm seeing a slight uptick in the number of apps that utilize the Ampache api.

I wish I could offer more other than testing & pointing out issues, but I hope the right candidate ( @wagnered?) comes along to breath new life into this project.

[Psy-Virus]

Well, I'm still here and will further handle the translation stuff and maybe further work it out to a more automated system. But to be honest, I didn't have the motivation yet. Maybe if the project comes to new life I'll have it again. :-)

To take over the project I wouldn't be the right one. I'm still - more or less - freshly in PHP and have still a lot to learn, what I also do as a hobby and not professional. But I will support everyone who takes the helm.

:-)

[a7medo778]

Guys as a user who is worthless when it comes to dev, i suggest to go the freemium way Maybe the plugins and the api section to be enabled with a small monthly fee that goes to the dev team

I know its never about the money, but anything to keep the project alive

Regards Ahmed

On May 21, 2017, at 3:56 AM, Manuel notifications@github.com wrote:

Well, I'm still here and will further handle the translation stuff and maybe further work it out to a more automated system. But to be honest, I didn't have the motivation yet. Maybe if the project comes to new life I'll have it again. :-)

To take over the project I wouldn't be the right one. I'm still freshly in PHP and have still a lot to learn, what I also do as a hobby and not professional. But I will support everyone who takes the helm.

:-)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[Psy-Virus]

I don't think it's possible. If I see it right, the user base is not big enough for something like this. I already tried to spread it and wrote to some software portals to write about Ampache but they mostly didn't react or didn't have any interest in it...

[gryphonmyers]

IMO, users of ampache are too savvy to sap money out of them with a monthly fee, unless monetization was reserved for highly non-essential features. Personally, I specifically avoid Subsonic / Madsonic because of their aggressive monetization model. I think it's wildly inappropriate to demand a monthly fee for a self-hosted product. Ampache is not a service, it's code. Yes, it takes time (money) to develop and maintain code, but there is no real overhead associated with user acquisition.

The problem is Ampache and similar products are targeting a niche within a niche market: web developers who care SO MUCH about managing their own music libraries that their willing to configure and maintain a web server to do it. I happen to fall within that category, but I think we're a pretty rare breed - most people are content with Spotify, apparently. Those who aren't can use Google Play Music, leaving pretty much only the most anal retentive power users to Ampache.

I would love to see this project thrive because it is far from perfect, but I'm not very surprised by the relative lack of activity here.

[lachlan-00]

Are there links to where all this is going on? I only use github for ampache so i wasn't aware of anything happening!!

If people are dropping out it's probably time to work on a 3.8.3 release as it's been a while since a stable release. Then work out how to move on from there.

I use ampache every day and would never want this to die. when you compare to subsonic/et al ampache is pretty much the only choice for free software users.

[Phyks]

Are there links to where all this is going on? I only use github for ampache so i wasn't aware of anything happening!!

I guess the mailing list is where most of the infos pass.

If people are dropping out it's probably time to work on a 3.8.3 release as it's been a while since a stable release. Then work out how to move on from there.

That is something that has been discussed a few times lately, as far as I know. Problem is that develop branch still has a quite large number of blocking bugs to tag a new stable release. I think the plan, about a year ago was to fix these bugs, tag a new stable release and then completely drop the actual architecture for something cleaner, more flexible and more modern. Problem was (and still is I think), Ampache really lacks "pro" developers with quite a lot of free time :/

[a7medo778]

Well the issues are piling up, unless the project gains traction with devs, its dead i am afraid :( Most libraries are already outdated

Regards Ahmed

On May 29, 2017, at 3:14 AM, Lucas Verney notifications@github.com wrote:

Are there links to where all this is going on? I only use github for ampache so i wasn't aware of anything happening!!

I guess the mailing list is where most of the infos pass.

If people are dropping out it's probably time to work on a 3.8.3 release as it's been a while since a stable release. Then work out how to move on from there.

That is something that has been discussed a few times lately, as far as I know. Problem is that develop branch still has a quite large number of blocking bugs to tag a new stable release. I think the plan, about a year ago was to fix these bugs, tag a new stable release and then completely drop the actual architecture for something cleaner, more flexible and more modern. Problem was (and still is I think), Ampache really lacks "pro" developers with quite a lot of free time :/

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[gryphonmyers]

then completely drop the actual architecture for something cleaner, more flexible and more modern

@Phyks Have any decisions been made as to what technologies a "more modern" ampache might utilize? I would be interested to get involved in a rebuild, though I fall into that category of devs who don't have much free time :(

[Phyks]

The idea was too build something on top of Laravel/Lumen (there is a dedicated branch on the repo, but quite empty I fear) and expose some clean standardized API and eventually build the front on top. There is an attempt of a new frontend using React and Ampache API here : https://github.com/Phyks/ampache_react.

It features basic stuff to browse the library and play music and is already working.

Last year, Koel (https://github.com/phanan/koel) gained some exposure. It is basically what the new Ampache should be, except that it lacks a lot of features from Ampache, and has no public API. Not sure also about the number of developers involved and the stability over time. -- Phyks

Le 29 mai 2017 03:20:36 UTC-04:00, Gryphon Myers notifications@github.com a écrit :

then completely drop the actual architecture for something cleaner, more flexible and more modern

@Phyks Have any decisions been made as to what technologies a "more modern" ampache might utilize? I would be interested to get involved in a rebuild, though I fall into that category of devs who don't have much free time :(

[vollmerk]

I don't want to see it die, but I also do not have personal time to devote to it... keep looking for alternatives, and whoever is willing to pick it up get in touch and I'll get you write access.

[Phyks]

Sure, same for me :/ Ampache is so featurefull, it would be a pity to see it disappears.

My impression as a former (sadly, I no longer have enough spare time at the moment for Ampache :/) contributor is that Ampache codebase is quite huge and legacy. There was a discussion some time ago about splitting most of Ampache features in dedicated plugins, and maintaining them separately. My opinion on this is that for instance most of catalogs and localplay code can really easily be split in a separate repo as plugins (it is actually almost handled this way already https://github.com/ampache/ampache/tree/develop/modules/localplay), which would largely reduce the size of the codebase and ease maintainance (as their could be dedicated maintainers for each feature more easily than in the current case).

Still, a major refactoring might not happen soon :/ I was wondering at some point if Ampache should not take profit of the gain Koel exposure to backport most of the features as Koel plugins, as Koel is alraedy stable and has basic features and uses the stack that was planned for the refactor. Problems are Koel does not yet have a plugin mechanism and it is mainly the work of a single contributor, so there might be same issues as with Ampache concerning long term maintainance. :/

[lachlan-00]

If the quality of the replacement options is anything to go by it's not looking great.

Koel has 7 times the stars that ampache has but i can't even scan my music library successfully. It also took well over 12 hours to do the initial library scan!

If ampache_react is basically working would we be able to separate ampache into a core and UI? The core of ampache is very solid and has the features that others are missing.

There are a lot of commandline options available so it could be possible to manage a server from cli in some way.

[a7medo778]

I think a mobile friendly UI as a start will attract many new users and perhaps dev's in the mix I do love the idea of using the plugins to separate the core functions, but again we need to have something rolling first.

I am looking at madsonic as a replacment but reluctant since its a single guy closed sourced project, non the less hes doing some awesome job http://beta.madsonic.org/pages/changelog.jsp The libraries upgrades alone says something

Regards Ahmed

On Jun 1, 2017, at 3:02 AM, lachlan notifications@github.com wrote:

If the quality of the replacement options is anything to go by it's not looking great.

Koel has 7 times the stars that ampache has but i can't even scan my music library successfully. It also took well over 12 hours to do the initial library scan!

If ampache_react is basically working would we be able to separate ampache into a core and UI? The core of ampache is very solid and has the features that others are missing.

There are a lot of commandline options available so it could be possible to manage a server from cli in some way.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[Phyks]

Koel has 7 times the stars that ampache has but i can't even scan my music library successfully. It also took well over 12 hours to do the initial library scan!

Thanks for the feedback, I was aware of such issues at the beginning of Koel but was thinking it had been solved in the meantime. I could never tried it extensively yet, just looked at it and heard about it and thought it could be a good starting point.

I was very busy lately, but hopefuly I should have some time to put back my (large) music library online at some point. It will be the occasion to deeper test Koel and see how it goes and if anything is possible to backport Ampache features, or try to find people motivated to refactor Ampache together. :)

If ampache_react is basically working would we be able to separate ampache into a core and UI? The core of ampache is very solid and has the features that others are missing.

It should be working for basic stuff, although I could not touch it for some time now. You can try it from the Github hosted demo provided you have a working Ampache instance somewhere. Have a look also at the opened issues to have an idea of possible bugs.

If ampache_react is basically working would we be able to separate ampache into a core and UI? The core of ampache is very solid and has the features that others are missing. There are a lot of commandline options available so it could be possible to manage a server from cli in some way.

We could, but ampache_react (really bad name actually :/) does not yet cover all Ampache features. That mean that the server will have more features than the client exposes. For this reason, a split is not viable in my opinion. But one may use this alternative UI (which is still very much beta, I should emphasize).

I think a mobile friendly UI as a start will attract many new users and perhaps dev's in the mix I do love the idea of using the plugins to separate the core functions, but again we need to have something rolling first.

:+1: Another idea might be to have a look at "modern" UIs for music, and adapt it to Ampache. Typically, Koel UI can be used provided that we implement its API in Ampache, or that we adapt the webapp to use Ampache API, and we can also find some alternatives UIs.

I am looking at madsonic as a replacment but reluctant since its a single guy closed sourced project, non the less hes doing some awesome job

I don't think madsonic can be considered as a replacement, especially since it is closed source.

[gryphonmyers]

So I'm not the only one! I installed koel and cannot successfully scan any of my music.

I have also considered writing a new front end for ampache as a way of significantly improving the product without having to touch the backend, so picking up the ampache react work may be a good path forward. The reality is that there are no good desktop clients for ampache or subsonic. They're all feature incomplete, usually ugly abandonware. And the current ampache frontend is pretty hideous

On Thu, Jun 1, 2017, 8:02 AM lachlan notifications@github.com wrote:

If the quality of the replacement options is anything to go by it's not looking great.

Koel has 7 times the stars that ampache has but i can't even scan my music library successfully. It also took well over 12 hours to do the initial library scan!

If ampache_react is basically working would we be able to separate ampache into a core and UI? The core of ampache is very solid and has the features that others are missing.

There are a lot of commandline options available so it could be possible to manage a server from cli in some way.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ampache/ampache/issues/1537#issuecomment-305351557, or mute the thread https://github.com/notifications/unsubscribe-auth/AFhG2C7dTuqOGdFT40XSu2bw6eCbZJ84ks5r_f-XgaJpZM4NdNiD .

[lachlan-00]

I think i'll start looking at ampache_react then; Koel wasn't good enough for a large library.

I agree that all the desktop/client apps aren't paid enough attention although power ampache on android is quite nice and even though the server is proprietary now the subsonic app on android is really solid.

I guess by focusing on an electron/html5 style app you can use them as desktop clients as well?

[gryphonmyers]

Does anyone know if any thought was put into designing a new client? The existing ampache interface is very... Organic. I might suggest wholesale ripping off an existing interface like koel did. I personally like Google play music's interface and have thought if I ever got around to making a web client I'd model it after that, material design and all.

On Thu, Jun 1, 2017, 2:29 PM lachlan notifications@github.com wrote:

I think i'll start looking at ampache_react then; Koel wasn't good enough for a large library.

I agree that all the desktop/client apps aren't paid enough attention although power ampache on android is quite nice and even though the server is proprietary now the subsonic app on android is really solid.

I guess by focusing on an electron/html5 style app you can use them as desktop clients as well?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ampache/ampache/issues/1537#issuecomment-305401160, or mute the thread https://github.com/notifications/unsubscribe-auth/AFhG2H2vAsH4PybOti7KqDK-eQkSdi-Bks5r_lpNgaJpZM4NdNiD .

[vollmerk]

So whoever wants to take some-what of the reigns e-mail me at karl.vollmer@gmail.com, I can help to a limited about, I just don't really have the time to code/answer questions etc etc

[Phyks]

The reality is that there are no good desktop clients for ampache or subsonic.

Yes, this was the idea in rewriting Ampache UI on top of the API and using "modern" web technologies such as React / Vue.JS etc. You can easily have some web app, go responsive for the model (and even package it into a real app with React Native / Cordova and so on), and eventually get a desktop app using Electron (although Electron is super heavy :/).

Basically the UI discussion was located here and Ampache_react was an attempt at writing some PoC for a new UI. I should emphasize that it is still really beta, and was one of my first code using React, so I am not 100% satisfied about the way stuff is done (typically, store etc are not optimal, and I might go with Vue now if I was to start it again).

@gryphonmyers see supra and linked issues.

[lachlan-00]

I really like the whole drop in aspect of ampache_react although i see what you mean about how basic it is. But at least for me this is the way to go so i'm going to pull the source and start learning about it.

I could live with a simplified php-based server package that is used to configure ampache and a UI/player like react to focus on the actual playing.

[Afterster]

Hi Guys. First, thanks for the motivation :smile:.

In my opinion, new UI, business model (I don't like it, Ampache is not a business), architecture and clients shouldn't be the discussion here. There is already dedicated topics for it, and it can be done on branches. Here we are more looking for a maintainer who would maintains and improve the current codebase, keeping Ampache goals in mind. There could be two maintainers, one on current codebase, another on Laravel branch if someone want to continue the work.

@wagnered, I will add you to the team just as @Phyks is already. Please focus on making a release before making any major changes.

[wagnered]

@Afterster,

Thanks. I'll start working on the 3.8.3 release. I don't think that I will be making any major changes to the current development code. Over the last several months, I've been working with and continuing the Laravel framework version with the coding you started. I'll look into implementing new features into the new framework as it is much more efficient.

73 From AA1AD Ernie D Federal Way, WA | CN87ug

On 14/06/17 22:00, Afterster wrote:

Hi Guys. First, thanks for the motivation 😄.

In my opinion, new UI, business model (I don't like it, Ampache is not a business), architecture and clients shouldn't be the discussion here. There is already dedicated topics for it, and it can be done on branches. Here we are more looking for a maintainer who would maintains and improve the current codebase, keeping Ampache goals in mind. There could be two maintainers, one on current codebase, another on Laravel branch if someone want to continue the work.

@wagnered https://github.com/wagnered, I will add you to the team just as @Phyks https://github.com/phyks is already. Please focus on making a release before making any major changes.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ampache/ampache/issues/1537#issuecomment-308629187, or mute the thread https://github.com/notifications/unsubscribe-auth/AF1QbqWMqG7FT_Ncak75CJXAOLSEFHDIks5sELqCgaJpZM4NdNiD.

[wagnered]

Version 3.8.3 has been released. @Afterster I would like to pin a notice in the Ampache Google forum. Could I have elevated privileges to add a notice to that group

[wagnered]

I published a pre-release (preview) of Ampache/Laravel with very limited functionality. There are only source files. So composer needs to be installed and run in Ampache's root folder.

I reopened this issue because using this issue is the only way I could find a way to keep track of comments and keep them isolated from issues on the develop branch.

I'm sure there will be problems and questions, So If you find that you need to open a new issue about Ampache/Laravel, please label it with the Laravel label and possibly with a Discussion label also. Otherwise it will probably be ignored.

Click Ampache/Laravel to go to the release.

[lachlan-00]

the laravel link is gone? i was just going to pull

wait, it's moved to here now https://github.com/ampache/ampache/tree/laravel

[wagnered]

OH yea, I changed the tag name and forgot to change the link above. I just edited the previous comment: It now points to the actual release page. I did that because someone iis allowing autoupdates and noticed the pre-release version was being displayed. The pre-release is not suitable for updating. I modifed the current release to ignore the pre-release and changed the tag name to have something to check against.

You really need to go to the wiki for installation instructions. it is quite different from earlier versions.

[stebe]

I have the Laravel version installed. What areas are ready for testing. For example, the admin server config options page has no save button. I get an E_Error when I click on server config interface.

It seems I'm unable to label new issues, so I can always reference this issue instead.

[stebe]

I've been playing with the 4.0 version for a couple of days now. I'm very impressed with how fast the interface is compared to the 3.9 version. The layout is very familiar so finding options and menu items is quick and easy. Considering this is an alpha or pre-alpha release I've got to compliment @wagnered on the work he has done by himself to get to this point.

[a7medo778]

question is still valid, @wagnered still around?

[Psy-Virus]

@vollmerk, @Afterster

Did you hear from @wagnered ?

[a7medo778]

@vollmerk, @Afterster, @wagnered ?

[Afterster]

Looks like @wagnered is away for two months now. He may have other priorities, lets hope it is temporary. He did a great job on the Laravel version, it would be sad to stop all of this now ^^.

[Psy-Virus]

[...] lets hope it is temporary.

Yepp

It would be nice to give me some rights. so I can at least keep the translations up to date. Or would you be so kind and merge them?

[lachlan-00]

Dec/Jan are big months for everyone so it's not out of the ordinary. Personal lives are more important.

I'm trying to look into v4 code and get abreast of things but I just don't know enough about laravel/js to be that helpful compared to php. (not that i know a lot about php either.)

[lachlan-00]

If Ampache is abandoned by wagner (which would be terrible as wagner has done a lot of good work picking it up after everyone else. :) ) there probably needs to be talk on what to do instead.

I don't know anything about laravel but i would like to keep the legacy ampache alive with a focus on audio only as a secondary function of an api/database for playback in other sources.

it seems like ampache itself is such a large thing for what really amounts to one person that it needs to cut down to survive.

Features i would remove -> what your alternative is video -> jellyfin channels -> icecast2 podcasts -> thousands of options localplay -> ???

I use/used these features but they aren't actually that important to the function of ampache to be viable.

features that i don't understand well but do need changes

• html5 player needs an overhaul
• composer packaging seems to be falling out of date
• A lot of the current bugs are probably beyond my understanding at this stage

For me, the biggest feature ampache has is being used as a single point of truth for all my other playback sources. Playback in the website is just a bonus really as i can use dsub/android apps and then sync my playback from rhythmbox automatically.

So what i'm really saying is does this seem reasonable? I'm only partially understanding of ampache code as i primarily code in python so i'm not a great dev but i would really not like to let ampache die. i'm pretty sure i've been using this software for a decade now and i would rather work on a fork than let it die.

[lachlan-00]

I've started working on this last night. https://github.com/ampcore/amuzak

I'm using a copy of my current database and will work on testing a base installation once I've finished cutting down the features.

• Videos are gone, Podcasts and channels are next.
• I'll start looking at the current pull requests after that.

If Wagner or anyone else pick Ampache up again I'll be really happy but for now i'll maintain this fork as an ampache-legacy option.

[Afterster]

I would not jump into a fork so fast, this project survived decades it should stand a little bit longer :). @Psy-Virus you have now write permissions so you can continue to do what you are doing great since so long. Thanks.

[a7medo778]

If Ampache is abandoned by wagner (which would be terrible as wagner has done a lot of good work picking it up after everyone else. :) ) there probably needs to be talk on what to do instead.

I don't know anything about laravel but i would like to keep the legacy ampache alive with a focus on audio only as a secondary function of an api/database for playback in other sources.

it seems like ampache itself is such a large thing for what really amounts to one person that it needs to cut down to survive.

Features i would remove -> what your alternative is video -> jellyfin channels -> icecast2 podcasts -> thousands of options localplay -> ???

I use/used these features but they aren't actually that important to the function of ampache to be viable.

features that i don't understand well but do need changes

• html5 player needs an overhaul
• composer packaging seems to be falling out of date
• A lot of the current bugs are probably beyond my understanding at this stage

For me, the biggest feature ampache has is being used as a single point of truth for all my other playback sources. Playback in the website is just a bonus really as i can use dsub/android apps and then sync my playback from rhythmbox automatically.

So what i'm really saying is does this seem reasonable? I'm only partially understanding of ampache code as i primarily code in python so i'm not a great dev but i would really not like to let ampache die. i'm pretty sure i've been using this software for a decade now and i would rather work on a fork than let it die.

would be awesome if you can add the artist youtube channel as a profile section, but in general i agree, ampache core should be all about music

[Psy-Virus]

I would not jump into a fork so fast, this project survived decades it should stand a little bit longer :).

True. @lachlan-00 and basically everyone else, if you have any fixes or improvements, that you think, need to be merged, you can still add Pull Requests. The community can still decide if the changes are okay or not. Github is meant to be a platform for collaboration between every kind of person with their specific skills and ideas. I'm not a pro dev either but I try to fix things that bug me and create my PRs after I tested my changes and think they're stable enough to be merged.

For example: a few years ago, I discovered Ampache and was fascinated by the functions but no one was actively developing it anymore and the UI was gross XD. Then I found Ampache-Doped, forked by Afterster and SUTJael, that added more functionality and a completely overhauled UI. I installed it and everything was working. But the German translation was horrible. So I started digging into it, completely rewrote it and took over the Translation part of Ampache. I also provided several fixes and improvements, not only for translations.

I think: The problem with those projects is simply that they start as a hobby and transform into work after a while. That makes it hard to keep up the motivation to work on it without getting paid or get any kind of reward or compensation, except thankfulness ( Don't misunderstand me. Thankfulness is a big thing! Stay thankful people! :P ), for all the time you have spend. Especially when you're working as the lone leader and only see the issue count growing. :D And of course there's this weird thing called real life :P

Just some thoughts I wanted to share after reading the discussion here.

@Psy-Virus you have now write permissions so you can continue to do what you are doing great since so long. Thanks.

Thank you @Afterster!

[lachlan-00]

I'm also using this opportunity to learn more about how the code works which has been really helpful whatever happens. I'm still also only one person and would rather keep ampache as is because it's been so important to me.

I agree that the drain is a big issue on an individual and can be really hard to manage. If i can simplify ampache to a point that makes sense i would rather make a pull here here and see where other people wanted to take it.

[lachlan-00]

@Psy-Virus you are 100% correct in how we should be looking at this. I'll stay out of this discussion now and focus on making practical pulls, and stripping out a core system for myself.

I've made a pull and I think it's a good first step without being too drastic. https://github.com/ampache/ampache/pull/1856

[lachlan-00]

It's not dead it's resting ;)

[nearwood]

@lachlan-00 wrote:

html5 player needs an overhaul

I agree. I use Ampache a lot and on mobile I prefer the web player over any apps*. I have some experience with HTML5 Audio and I would love to see a responsive player.

I'll take a look at the web player code and see whether it's something I can do.

*I have developed and Android App that is basically the Google Audio Player example hooked up to Ampache, with an Android Auto interface, but it does not work well with large collections :( so I have not released it.

[lachlan-00]

@nearwood is your app using the API? There are a few changes coming in the api/xml that should help with the large collection. I think a large problem with API apps is we haven't really given decent documentation or support to people who have made that effort.

Right now I think dsub is the best Ampache android app so it would be good to make API clients first class citizens.

We should work on the issues you have as well. If it's based on an example Google app it could make a good example app to include as a repo here.

There is also power Ampache by @antoniotari which I think would really benefit from better API code and support.

https://github.com/antoniotari/reactive-ampache

I'll be merging my core repo soon as I finish up a few more things and test the changes.

While I'm still merging changes from my original fork I don't recommend using it unless you want to look at current code.

https://github.com/lachlan-00/ampache/tree/core

My weakest area is in JS/Java/android so having another pair of eyes on the webplayer will really help.

[lachlan-00]

Hi everyone, I've just pushed my core branch into develop! This is the culmination of about 3 months work when you include my initial fork and the modernization project is essentially complete (https://github.com/ampache/ampache/projects/2)

I've really enjoyed being able to push ahead with this and I hope we can keep the momentum going.

[stebe]

I just pulled the latest develop and so far nothing has broken. Great work @lachlan-00 for keeping the project alive and adding updating features.