Hi,
One question: Is there any way to assign auto-dj size to each radio station?
On the control panel of each radio it appears: "13.31 GB of 19.10 GB Used (5.78 GB Free)". On that radio, I've uploaded about 70 songs, which will be about 250 MB. In each radio there are 13 GB occupied?
Is there any way to define the disk size for each auto-dj?
If someone can help me...thank you thousands.
@multi023 At the moment, this isn't possible for one primary reason: because our main recommended method of distributing AzuraCast is via Docker, which (by design) abstracts out things like the host's CPU, RAM and hard drive storage so that the individual containers don't need to particularly worry about managing them.
On some Docker hosts, it's possible to set quotas for each of these items, but the support varies widely and isn't something we could include directly in the distributed Docker Compose file without causing a lot of potential issues. I went looking for a relevant Docker Compose configuration section in case you wanted to add it in just for your specific instance, but the documentation on this is so sparse that I can't even find _that_.
As for creating a fake quota that we only enforce when attempting to upload files directly through the web interface, that's possible, though it could easily be circumvented by anyone uploading using SFTP directly to the filesystem.
As for creating a fake quota that we only enforce when attempting to upload files directly through the web interface, that's possible, though it could easily be circumvented by anyone uploading using SFTP directly to the filesystem
I don't see that as a problem, as long as the application warns you, and denies uploads (unless admin, or permission). A limit could be tracked by checking the Station's data folder (recursively), perhaps with a cached cronjob to lessen the load, instead of iterating on every request (maybe remove cached value on each upload).
(Too much potential, this thing has)
::\`--._,'.::.`._.--'/::
::::. ` __::__ ' .::::
::::::-:.`'..`'.:-::::::
::::::::\ `--' /::::::::
Hi,
I would be happy to use instead of 20 GB, for example, to use 50 or 100 GB. Is that if not, I can not create more radio stations on a 2 TB server, having used only 20 GB :(

It's great, it does not consume resources ... well, I'm still happy, but I could be much happier :)
@multi023 The problem you're having isn't related to this issue, which is requesting the _addition_ of a soft quota per-station into the system. No such quota exists right now.
If your Docker installation is limiting the size of your installation currently, but your hard drive is bigger than that, this may bean issue with your kernel version (you may need a newer one), with how your drive is partitioned (make sure the partition where Docker volumes is stored has enough space allocated to it), or something else. In other words, it's a bug, very likely with Docker.
I do not use docker. It really is a problem if a user uses all my quota on disk to send mp3. This will end up hurting other users who have sent fewer files.
I also have the same problem, a user uploaded a lot of music and copped the server limit
good day and good Christmas. my question is how we can limit the hard drive for 1 radio Storage Space Restrictions
Just as an update for everyone wondering about this feature: it is entirely possible for us to implement a "soft quota" feature that prevents stations from uploading files once the station has reached a specific total file size.
Frankly, however, the largest (and perhaps only) market for people interested in this feature being added to AzuraCast aren't station operators looking to manage multiple stations of their own on the same server, but resellers looking to build out shared AzuraCast instances and possibly to sell each individual station to separate managers.
This item has been a low priority to implement on my list, and it seems that many of the requests to implement it are coming from people interested in reselling AzuraCast for a profit.
If you are interested in using this software commercially, and are requesting a feature whose sole purpose is to help facilitate commercialization of the software, then this is something you should be paying for or implementing yourself via a pull request.
This is one of the few moments where I'll "break character" and express a decision based entirely on my personal emotion, but I have a strong resentment for the idea that open-source developers are often expected to facilitate others making a profit on their work while those others contribute nothing back to the developer. This is an exploitative relationship I don't want to promote here, not in the least because I simply can't continue to survive while being exploited in such a way.
I would not have a problem paying for it and helping your job. . as well as I want to help and support your job. because it is important that you do. well done.
For me the same.. it not a problem to paying for it!
Hi @multi023
If you know php code, you can easily create a function to hide the "upload_progress" div.
Idea of the function:
If "$space_used" is (500MB -for example) then to hide "upload_progress div".
File: AzuraCast/resources/templates/stations/files/index.phtml
Hi @multi023
If you know php code, you can easily create a function to hide the "upload_progress" div.
Idea of the function:
If "$space_used" is (500MB -for example) then to hide "upload_progress div".
File: AzuraCast/resources/templates/stations/files/index.phtml
I'd strongly discourage modifying the templates or other code of AzuraCast for such customizations since they will be overwritten with every update.
Agreed with @Vaalyn; if you have a proposed implementation of the size quota, feel free to fork the codebase and then submit a pull request, but please don't just modify your local installation's code, as it will be wiped out by subsequent updates.
Furthermore, the suggested fix in this case just hides the upload bar; it doesn't stop new files from being processed or uploaded. The reason we have taken a while to implement this is because we want to implement this inside the controller code itself, providing both a clean way to modify the quota from an administrator's end and an intuitive UI for users who reach a full quota.
I completely agree with the reasons for not editing the code, due to the updates. My idea is just a suggestion.
Honestly, my suggestion is only as a temporary alternative.
Definitely, it is highly important to limit some primary aspects in any streaming server:
The project is really exciting and I am enjoying the features. Especially, it is a great alternative to old environments, such as Centovacast, where design and functionalities are already part of the past.
@vasilisss @inetactief I've set up something for this issue on Bountysource, which will let groups of people contribute toward the development of a feature. Currently, the estimated time to implement this is one working day, which I've set at a bounty of $250. As far as I know, this doesn't have to be provided by one person, but kicks in once the total funds raised have reached that threshold.
https://www.bountysource.com/issues/53541896-define-size-quota-for-each-radio-station
Let me know if you encounter any issues in this process, and thank you for helping to test out this functionality.
Keeping in mind that my programming skills are very limited ...
If limiting disk space is impossible, then another idea is to limit the total number of audios that it is possible to upload (number of audios + size of each audio) It is just a suggestion, perhaps much easier to program.
In my particular case, I want to use Auracast for three or four working groups (3 or 4 radio stations), all students. They are responsible for the use of disk space. But there may be exceptions.
Imagine a group of colleagues using Azuracast. Each friend has his own radio station. When I talk about a group of friends, it can also be an amateur club, a broadcasters association, ... Limiting disk space is really necessary. Example: The same limitation for all radio stations.
I would like to find a solution to this problem, really. I have been testing a trial version of Centovacast (as I said earlier) but the system is really very old and too complicated, however, I see that Centovacast has a limitation on disk space. (I know, this is commercial)
Everything comes down to keeping a track of all files "owned" by a station and and enforcing it on the front and back-end, file count, size of all files, it's all almost the same effort, I can't think of anything that'll reduce the complexity on that (which I mean we're talking an entire day, so the problem isn't duration it's just other priorities come first unless there is funding involved).
Being as you're on a "traditional" install, doing Linux filesystem shenanigans would actually be _really_ easy and would be a good workaround for a single installation.
Reference to those shenanigans here: https://github.com/AzuraCast/AzuraCast/issues/1095#issuecomment-453906221
Imagine a group of colleagues using Azuracast. Each friend has his own radio station. When I talk about a group of friends, it can also be an amateur club, a broadcasters association, ... Limiting disk space is really necessary. Example: The same limitation for all radio stations.
I work with an install where this is the case and a looking at doing a 2nd deployment, along with some teams we work close with that have similar setups, we just enforce it on the administration level (running du reports inside of Linux when we want to see who is using up space) and administrate our system accordingly. It's why it's been relatively low priority -- because this setup can work okay without quotas (because a lot of AzuraCast installs seem to be like this).
Reference to those shenanigans here:1095 (comment)
Ok @CodeSteele , I'm going to try to do what you recommend. According to the instructions, I must create a file where to specify the maximum size allowed. Considering my programming limitations, I'm going to "take a breath", play zend music on my headphones, and try to follow these steps.
Before, I need some answers;
Azuracast creates a new folder where to locate all the files of a radio station? Specifically, a folder where the audio of the radio station is stored?
In the case of developing this solution that you have commented, in what way can this help the other users? I understand that this solution is manual (if I create a radio station, I follow these steps manually to limit the disk space of each radio station). I mean, my programming limitations are not going to allow me to develop something that works automatically. The ideal in this project is to create things that help improve the common project.
I mean we're talking an entire day, so the problem isn't duration it's just other priorities come first unless there is funding involved.
How much money are you talking about? How is it possible to help financially? I can contribute some dollars, not too much. Also, I'm reading to some users in this thread, who want to help with some money.
This function is not important for the project, really?
@tonimad
The bountysource link was provided above at: https://www.bountysource.com/issues/53541896-define-size-quota-for-each-radio-station
Azuracast creates a new folder where to locate all the files of a radio station? Specifically, a folder where the audio of the radio station is stored?
Yep, you'll want to create your stations first then re-mount the upload directories to your new filesystems.
In the case of developing this solution that you have commented, in what way can this help the other users? I understand that this solution is manual (if I create a radio station, I follow these steps manually to limit the disk space of each radio station). I mean, my programming limitations are not going to allow me to develop something that works automatically. The ideal in this project is to create things that help improve the common project.
Writing up end-to-end instructions on a workaround that is useful for others is a good contribution.
This function is not important for the project, really?
It's important -- but we have a lot of other _more_ important features.
@CodeSteele Sorry, I had not understood the purpose of this link. I have now contributed with some dollars, if this helps improve the project.
I just made my contribution with a few dollars.
@vasilisss @inetactief You can now contribute with some dollars, just as you said. Reasons to do this:
A few dollars is not enough!
I will transfer $40 hopefully when everyone do this in this post, we have great new functionality.
Share us the link we can do the payment for paypal :-)
@inetactief As you can see, I made my transfer.
Yes i see and here it the payment link https://www.bountysource.com/issues/53541896-define-size-quota-for-each-radio-station
Any advance about this
Just committed $40 myself to this - it's an important feature. Understand the point of view posted, but there's also the simple need to manage resources responsibly and being able to either monitor or restrict disk usage is a common need for most users. I am both a donor here and a monthly patron and believe strongly in the support and expect nothing truly for 'free'. The effort, work and time invested here is impressive and appreciated. If you're using it, don't be shy about pitching in guys - it helps us all in the end and helps those who help us. JB
@inetactief @williambatson Thank you for your important contribution to attract the attention of the developers, so that they can create this important functionality.
William, your reasoning is totally correct.
@multi023 @xewl @JMultimidia @webma5ter23 @vasilisss Can you help by contributing? https://www.bountysource.com/issues/53541896-define-size-quota-for-each-radio-station
@CodeSteele @SlvrEagle23Â How much more money is necessary?
@tonimad The current bounty goal is set to $250 and there is $105 currently pledged so the remaining sum necessary is $145.
Thanks for your answer @Vaalyn
I'm a little frustrated with this, really. I would like to know the direct opinion of the developers. They have not said anything for days.
First of all, I do not consider that this functionality should be labeled "commercialization". I can understand the concern of the developers at this point. However, I consider it more important to improve the project, being able to control important aspects such as the use of disk space (as in this case), instead of preventing the development of features for fear of commercialization.
If someone wants to market the project, this is inevitable. This is in the consciousness in each person.
Second, I can not understand the reason for considering this feature as unimportant, or low priority. Having the possibility to manage the disk space is important and responsible.
Some users have contributed some money in Bountysource. Do you still consider that it really is not important?
This is an open source project. I understand that there is a lot of effort and work. However, there is a philosophy that we all understand in terms of open source. Requesting money to "unlock the decision" to add this functionality that is really important, is definitely to market with the project. There are other ways to contribute to the project, which we are already doing.
At this point, there is $105 in Bountysource, currently. With all my respect, do you consider that this amount is enough money to unlock your decision to add this feature?
@tonimad As the creator and lead developer of AzuraCast, first let me ask that you be patient with us with this process. We may not respond for quite a while, largely because we are busy with other projects. In particular, because of the bankruptcy that I went through late last year, money is very thin and I am forced to work on other projects that actually pay hourly rates so that I can pay for rent and groceries.
The reason I set a bounty target for this item at $250 is because this corresponds to well under a day of work at senior web developer rates. This project may well take multiple days to build out properly, but rather than set the bounty goal at the hourly rate, I chose to pick a lower amount because:
I chose this item as a "test bed" for the feature bounty program because it is so heavily oriented toward resellers who want to share one single AzuraCast installation across multiple installed stations. Whatever your opinion of this bounty project or open-source software in general is, I do not think it is appropriate or fair that I invest thousands of hours into the creation of a product, that product is then used for a profit out on the web, while I continue to face the very real prospect of imminent homelessness. This exploitation of the labor of honest, hard-working developers would be somewhat more permissible if the developers were otherwise living comfortable lives, but that is unfortunately not the case here.
I still maintain that $250 is an extremely reasonable amount to be asking for the full design and implementation of not only this feature but the supporting technology needed to make this feature practical (namely the administrator-specific ACL controls for stations that separates what permissions a station owner can themselves change about a station and what can be changed from only an administrator).
If you disagree with that decision and believe that $100 should be enough to develop and implement this feature not only properly but cleanly with existing AzuraCast code, I invite you to submit a pull request yourself, have it reviewed, approved and merged, and then claim the bounty as it stands right now. The fact that nobody has implemented this feature in the over one-year period that it has been outstanding suggests that perhaps this requires more hands-on developer expertise, and that perhaps that expertise is, at least to the users who are commercializing my software based on it, worth paying for.
@SlvrEagle23 Thank you for your response and for the time you have dedicated to solve my doubts.
I've understood your reasoning much better. And yes, I know your personal story, I've read about your circumstances on the project website. After reading your answer, I still consider that this functionality is important, but I also understand that it can be used by resellers.
I have now added more money to Bountysource.
I've contacted some users of this thread, who request and defend this feature. Researching a little, I see that some have hosting companies and streaming audio. They have not contributed any money in Bountysource. It is curious the silence they maintain. Honestly, I must be very sincere: That silence is not reasonable.
Good morning and from me to everyone I have just seen the messages here your mouth please a lot of information and an email to do me a transfer amount and to help as much as I can for this work thank you!!
@vasilisss The best way to contribute is by adding a little money here:
https://www.bountysource.com/issues/53541896-define-size-quota-for-each-radio-station
No registration is required. With your Github account is enough.
Thank you so much.
I've said it before and I'lll say it again - nothing in life is free and if
you find something for 'free' it's either junk or stolen. AC is neither
and I truly just fell in love with the project and am having a blast with
my sons overseas and a few friends. We use it, we enjoy it and most of all
we appreciate everyone's efforts and contributions. Circumstances
shouldn't matter (Eagle: my heart goes out to you and God bless, I hope the
sun shines your way soon my friend) - but my point here is whether it's
asking for more and useful features like this one (or others) or you just
downloaded it and use AC - there's nothing more honorable than showing
your appreciation. These guys don't charge for the software and I'm not
affiliated in anyway with the project other than an end user - so even more
respect for these guys doing what they do without holding their hand out or
expecting anything in return - Hell, if I had the expertise I'd jump on
board with these guys in a flash - I don't, so I became a patron and help
out where I can - I might not be able to code but maybe I can give a little
back to those who give me some enjoyment thru their hard work. Enough
preaching LOL Just again, my heartfelt thanks and I hope I bring some
attention to the subject to some other users still on the fence on how to
help a great project. You guys are a good group and I thank you!
On Thu, Jan 17, 2019 at 4:30 PM Toni notifications@github.com wrote:
@vasilisss https://github.com/vasilisss The best way to contribute is
by adding a little money here:https://www.bountysource.com/issues/53541896-define-size-quota-for-each-radio-station
No registration is required. With your Github account is enough.
Thank you so much.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/AzuraCast/AzuraCast/issues/368#issuecomment-455383051,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AnlnB7Z_7b23cNj_SxchDTLuUtC4RKXqks5vERWjgaJpZM4RXNAT
.
Hello all! Just an update on this item's progress:
I just merged my branch which implements the full functionality of a per-station storage quota. This quota can only be set by people with the global administer stations permission, not the station owner themselves, in a new "Administration" tab you'll see when editing any station. Uploads will immediately increase the used portion of the quota and deletion will immediately decrease it, with the 5-minute media sync also serving to re-calculate the total space used from the disk and make sure it stays in sync. If you attempt to upload a file and you're over-quota, it will immediately fail rather than making you wait through the whole upload process.
I appreciate all of you who contributed to the Bountysource listing for this item. I realize that there was some contention about tagging this feature as "commercial" and requesting sponsorship of its development. I'm not certain this is the best way to secure support for individual features, and we may not take advantage of this same tool in the future. In any case, thank you to those of you who helped make it work this time.
To those of you reading this thread and wondering how you can support AzuraCast, we have two means of providing ongoing funding. The first is our Patreon, which lets you donate monthly to directly support the project's continued development: https://www.patreon.com/AzuraCast
The second is my personal Ko-fi account, which helps me purchase living essentials, including the coffee that I dutifully convert into the code that makes up AzuraCast: https://ko-fi.com/silvereagle
However you choose to support this project, whether financially or through spreading the word to your friends and fellow station operators, thank you for helping make this project of mine more successful every day.
@tonimad @inetactief Per the message above, size quotas were added to AzuraCast last week. I've noticed that both of you were backers on the BountySource project, but have yet to approve the item as completed. This is causing an unnecessary delay in receiving the funds for the project's completion.
If you could please visit the BountySource web site and approve the bounty, it would be much appreciated. Thank you.
@SlvrEagle23
Oops! I'm SO sorry!! I do not know how BountySource works. I have just accepted, now it is all right. Please, check this.
Thank you very much for the implementation. I appreciate your effort and your work, I'm very happy with the project and I feel involved. Thank you so much!
Most helpful comment
Hello all! Just an update on this item's progress:
I just merged my branch which implements the full functionality of a per-station storage quota. This quota can only be set by people with the global
administer stationspermission, not the station owner themselves, in a new "Administration" tab you'll see when editing any station. Uploads will immediately increase the used portion of the quota and deletion will immediately decrease it, with the 5-minute media sync also serving to re-calculate the total space used from the disk and make sure it stays in sync. If you attempt to upload a file and you're over-quota, it will immediately fail rather than making you wait through the whole upload process.I appreciate all of you who contributed to the Bountysource listing for this item. I realize that there was some contention about tagging this feature as "commercial" and requesting sponsorship of its development. I'm not certain this is the best way to secure support for individual features, and we may not take advantage of this same tool in the future. In any case, thank you to those of you who helped make it work this time.
To those of you reading this thread and wondering how you can support AzuraCast, we have two means of providing ongoing funding. The first is our Patreon, which lets you donate monthly to directly support the project's continued development: https://www.patreon.com/AzuraCast
The second is my personal Ko-fi account, which helps me purchase living essentials, including the coffee that I dutifully convert into the code that makes up AzuraCast: https://ko-fi.com/silvereagle
However you choose to support this project, whether financially or through spreading the word to your friends and fellow station operators, thank you for helping make this project of mine more successful every day.