Roadmap to 1.0 #4460
Comments
BusterNeece
added
enhancement
|
Hello; I love Azuracast. I've been using it for over 2 years with no problems. I like the Ansible version more than Docker. Azuracast should now exit beta. I agree with this thought. I translated the entire Azuracast into Turkish. I have one more thought. I hope that will be useful. Is it possible to make a firewall with a graphical interface that works with Azuracast? I don't know how Docker works on this. I am actively using CSF for Ansible. I have tips for some safety precautions. I'm very sorry, but the reality of DDoS/Botnet still exists today. Depending on this it may be necessary to block some bad traffic. This is forcing the server owners. For example, we can add "ratelimit" rules that will not cause problems for users. Hope this project will continue for many years. That's all I want to say for now. Endless thanks to the team. |
|
Not sure if it's related to "Grouped/Nested Playlists" but the Drag and Drop Music Scheduler could make AzuraCast a viable option for a wide range of Radio Stations Another benefit of the roadmap is you could set up funding goals for both the 1.0 release as well as specific features on https://opencollective.com/azuracast |
|
Hello. Thank you for the wonderful project! I'm now investigating it as a part of my very special possible future podcast project for Telegram. One thing I'm missing and one that looks rather easy to implement would be having different designs/custom backgrounds/css for different stations public pages/virtual DJ pages.... Or might even URL-dependant custom images/css for login pages as well.... |
|
You can have my support for native Romanian, Chinese Simplified and Indonesian. Feel free to contact me. |
|
I can help with Dutch, Feel free to contact me. |
I currently use a Docker install which is obviously a bit different, but I personally block the radio ports using UFW, whitelist the Nginx proxy inside AzuraCast to only be accessible through a "proxy" server and I run rate-limiting and other proprietary DDoS protection techniques on that proxy. This helps a LOT with the threat of botting and DDoS attacks. I feel like something like this would be cool to add to AzuraCast, BUT I think it would be slightly out of the project's scope. |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
github-actions
bot
added
the
stale
Vaalyn
removed
the
stale
|
Hello, I am looking forward to seeing the Grouped/Nested Playlists feature. This will be a very nice improvement in automating your radio. One important legal issue may not be forgotten for this. Pretty sure this will be a challenge and most likely is already discussed between the developers. That is, that such a grouped/nested playlist must also have the "Avoid Duplicate Artists/Titles" option and handle with care. My personal opinion on this matter is that it should be removed from the playlist setting, but must work station wide. Of course, it can only take care of this on the queued tracks for the random types. The live and sequenced playlist is the responsibility of the DJ's. Further, in some countries, the rules on streaming radio are a bit more restrictive than the current autodj setting is offering. |
|
Hi, As recommended I'm posting my use case of the Grouped/Nested Playlists feature to see if it can be built-in. Besides that script, another script runs to create SymLinks. These symlinks are created based on the date in the filename. So if a mix has the date of today, The symlink points to the active folder of the DJ. When there is no new set for today (so no filename with the date of today) then the symlink is created to the Archive folder of the DJ. In this way, the DJ is flexible when he uploads a new mix and one will be played from the archive when he does not upload. Would be awesome if this could be done within AzuraCast playlists. We currently have not yet moved to AzuraCast because we haven't found a solution for it. Also, StereoTool is required for us but isn't integrated and we are having trouble getting it working. Kind Regards, PS: if you need help translating to Dutch, let me know! |
|
Quick question - Is the Statistics Overhaul #5242 on the roadmap? What about the Drag and Drop Music Scheduler referenced in #4460 (comment)? Are there other features/functionality needed to make AzuraCast a viable solution for community, noncommercial, and other types of radio stations? Not sure if they all would be included in a 1.0 release or some would only be built if there was a budget. Either way, I'd suggest a funding goal for the 1.0 on https://opencollective.com/azuracast and continue to use the 'projects' feature for the latter. As mentioned in #4609 (reply in thread) we're hoping OpenProducer's platform pilot focusing on extending Newspack/WordPress for radio stations will provide opportunities to direct funds and contributors to AzuraCast. |
|
@gusaus the Statistics Overhaul is still on our to-do list, though is a lower priority and isn't something we would necessarily include in the 1.0 roadmap. If we get some help with the Drag and Drop scheduler, then we can work on that too, but I wouldn't start work on it myself as I don't have enough experience on implementing that kind of thing myself. We tried to use the OpenCollective sub-project system for the statistics overhaul, and it worked fine, but it's not a bounty system at all. |
|
@SlvrEagle23 I appreciate the clarity. I've seen Drag and Drop scheduler referenced in discussions around features like #5407 but haven't seen an RFP or Feature Bounty (similar to #5242). It's been a while since we discussed your specific needs to move that forward. Are there certain tasks you'd need help with (including non-development tasks like requirements, docs, and fundraising)? Would it make sense to create a separate issue or discussion about this specific feature as it's out of scope for 1.0? I'll followup in Open Collective's Slack about how OpenProducer's pilot 'should' provide a way to direct resources towards the development of 'commercial' features as well as this 1.0 release. Really appreciate all the work you and the team have put into the project! |
|
AzuuraCast is making great progress every day, it's awesome to see. Thank you so much for your continued hard work on this software!
As for the listener point of view, I think Voting on Songs would be one of the main priorities. It's definitely one of the things people mention to me first. Thanks for reading! |
|
Hello, a functionality that I think is essential for the proper functioning of a station is the playlists with the option to interrupt so they can respect the assigned priority. For example, only interrupt other playlists with lower weight. If a list with the same or higher weight is playing, wait for it to finish. This would allow meeting schedules without interrupting programs. |
|
Here’s my ideas, sorted by priority (top=highest):
Thanks & keep it rollin’! |
|
Closing this issue as we're no longer really referencing it to target a 1.0 release. Much of the work here has been completed, and our needs for what should be in a 1.0 release are always evolving. |
Over the years, many folks have asked us what it would take for us to tag a 1.0 release version of AzuraCast. After all, thousands of stations run every day on AzuraCast already without any issue, and we have a stable enough infrastructure that we're able to tag "Stable" versions of our software every few months.
Historically, we've (well, I've) been hesitant to ever tag a 1.0 release version for the same reason that a lot of projects are in a sort of "perma-beta" state: because people have different expectations for something they see as under active development versus something they see as "released". We've been faced with very upset users in the past and we don't want to encourage that behavior via our own actions.
So, here's the bottom line: it will never be possible for us to write completely bug-free software or to eliminate every issue that exists prior to a 1.0 launch, but we will manage the process in such a way that everyone has plenty of opportunities to report bugs to us before the final tagged release version, and it's our hope that the resulting product will be one that is reliable, powerful and that folks can count on for production radio stations the way many stations already do.
With that in mind, there are a few things that I think are necessary for AzuraCast to have in place before we can tag a 1.0 release. We've made a lot of headway on these items already, but I'd want them to be done before we tag a 1.0 version:
Implement Liquidsoap 2.0: The next major release of Liquidsoap is already in its testing phases, and we already have branches set up (Implement changes for Liquidsoap 2.0.0 #4402 and Update to Liquidsoap 2.0.0 docker-azuracast-radio#12) to test how it integrates with AzuraCast; we will want 2.0 to itself have a stable tagged release, and for our integration of it to be well-tested and merged in our main branch.
HLS Support: We have a separate issue for our proposed implementation of this (Proposed HLS Implementation #3685). We expect this will become somewhat easier to implement with the adoption of Liquidsoap 2.0.
Grouped/Nested Playlists: One of the most widely-requested features that we don't currently support is the idea of "nested" playlists; one overarching playlist that contains other ones in a specified playback order. For example, one parent playlist could say "Play X songs from playlist 1, then Y songs from playlist 2, then Y from playlist 3". Although our code doesn't currently support this, implementing it is, at least in my opinion, imperative for a 1.0 release.
"Vue-tify" Everything: Already, as we build new functionality into AzuraCast, we're slowly moving components over to Vue pages that call underlying APIs to accomplish their work. There are still areas that haven't been fully Vue-tified, though:]
Evaluate Media Processing: In recent versions, we've implemented code that separates the media processing process from the rest of the system. The media processing code doesn't need to be PHP at that point, and may even benefit heavily by not being PHP; we should evaluate our current processing performance metrics and whether spinning that program off into a C#, Golang, etc. program would be appropriate.
Full Localization in Selected Languages: We rather frequently change strings, but for the 1.0 release process, we would intend to have a "string freeze" early in the development cycle to allow for our friends who help with translation and localization to fully translate the entire application. Currently, our ten most localized languages are the ones below, which we would expect to be at 100% translated strings before any 1.0 release:
I would love to hear folks' thoughts on this. I know everyone has a particular feature or two that they're especially interested in, and I don't want this thread to just become folks listing out the specific features they want for their own station, but rather a big-picture discussion about what we should prioritize as we target a 1.0 release that would do the most good for the greatest number of stations.
The text was updated successfully, but these errors were encountered: