Cloudron Forum

Me as well. I'd be willing to host this via Zoom, record the session, and then host it on Vimeo. We could post the Vimeo link in a "Community" category. But I can't do this until December.

@girish Thank you for addressing this annoyance in 9.0.0.

@james Seem to be running into an interesting problem during uploading. So far with 100M as my "size" limits, I am unable to upload FLAC files larger than 50MB. I found out that htaccess, not the .htaccess file I created contained the operative limits: 50M. So by editing the correct file (htaccess) and fixing the limits, both larger FLAC files uploaded. My mistake!

@james My mistake on the .htaccess vs. htaccess. I am so used to using it with the dot and hiding it. I'm happy to experiment with different RAM settings and watch what happens with Koel.

@james Perfect. Koel is working! Thank you. One suggestion, one question. Suggestion: you might want to add the period in the new documentation before htaccess (/app/data/public/.htaccess). Most users will understand the intent, but for inexperienced users, they might take this literally. Question: Based on the size of my FLAC files, I chose 100M as the "size" parameter. Do you have any thoughts on whether we should increase the application RAM to accommodate larger files on both upload and streaming and if yes, how that should scale with "size"?

@james Sure. What's strange is I had no problem uploading .FLAC files at all. Just playing them. Files varied from 12MB up to 30MB.

@james Impressive bit of detective work. Is /app/data/php.ini the proper way to set PHP settings inside Cloudron PHP apps? I understand that /app/code/public/.htaccess overrides this and that is a read-only area.

No. The demo server (https://demo.koel.dev/#/queue) plays just fine for me. I also have the same issue on Windows, so it does not appear to be Linux related. But interestingly, neither the demo site or my Cloudron instance seems to work on iOS Safari.

@robi It's a brand new installation. Cloudron version is 7.15.1 which matches GitHub master release level.

@james I'm not using Cloudflare or proxying. Nothing unusual about my Cloudron setup. I am using that particular Cloudron only for SoGo and Koel (as a test). I have 2 songs in my library, one FLAC, one MP3. When I attempt to play the FLAC, it looks like it tries and then skips over the song and goes to the second MP3.

Cloudron is so reliable I am using Kuma inside Cloudron to check availability on all my other unreliable vendors:) And some of them will have one less customer in the near future.

So I just installed Koel, changed the admin credentials and added another user. All working just fine. I uploaded some m4a files (either ALAC or AAC) and nothing played. I tried FLAC instead and nothing played. Locally (Linux), the files played without issue. Koel supports all 3 formats, so this shouldn't be an issue.

Tried php artisan koel:doctor (running as www-data user) and all tests passed. x_sendfile was the streaming method. And Apache had the xsendifle module available. So this looked good.

I notice that PHP Max Upload was 2M and Max POST was 8M. My high quality files were bigger than either. On a hunch, I uploaded a <5MB MP3 file and Koel streamed the file to my Linux laptop via browser.

My next move was to try and adjust PHP.ini to modify those settings. Unable to edit the files as both www-data and root (read only) .

I don't know if my hunch is correct. There is nothing I could find in the Koel troubleshooting docs to suggest these parameters could cause a streaming issue.

Any advice would be appreciated. If someone can suggest a method to modify these limits, I can see if that is causing the problem.

@LeZalata You always have the option of self-packaging any app. The easiest ones already have Docker versions. But PHP apps and others have been packaged as well. I am not familiar with the two you mentioned so I cannot provide guidance. But the platform is solid already and getting better with each update/upgrade.

@BrutalBirdie Thanks for sharing. A fun travelogue to view.

@fbartels Thanks.

@marcusquinn I would build a new room with floor to ceiling monitors on one wall. Reclining theatre seating and a kegerator. And a Hirsh keypad to prevent anyone except me from entering:)

Just looking for some advice on the best way to implement a help desk ticketing system.

FreeScout looks promising (after adding a couple of modules). That being said, I need to put ticket creation behind a user login. The End-User-Module would do that (I think), but I would also like to enable chat (with Live Chat module?), but that doesn't seem to be possible. It is a widget (like Chatwoot) meant to be added to a website. That makes chat available to all.

Has anyone done something like that? Currently I am managing users within the app. I did see the Cloudron LDAP option and perhaps using that, I could build a one-page website using LAMP, host it only for authenticated users, and embed the ticket form and the chat widget.

Any advice/experience appreciated!

@creative567145 Try these (replacing endpoint and region with proper references matching your bucket):

export S3_ACCESS_KEY="your_backblaze_b2_keyID"
export S3_SECRET_KEY="your_backblaze_b2_applicationKey"
export S3_BUCKET="your-bucket-name"
export S3_ENDPOINT="s3.us-west-002.backblazeb2.com"
export S3_REGION="us-west-002"
export S3_SSL="true"

My backup failure issues continue. I wanted to share another Cloudron topic about Minio backup failures and multipart. It got me thinking that perhaps my problem with iDrive E2 is the number of simultaneous connections being initiated as a result of the default Cloudron part size (10MB). I decided to increase the multipart size from 10MB to 64MB and see what happens. In looking at the size of files backed up, for me they range from a few kB to 20GB+ (mail). @joseph Two thoughts: First: should the Cloudron default be increased? Second: Future enhancement... perhaps 2 part size parameters could be defined: small and jumbo. For small tar.gz files, 10MB would be ideal. For jumbo tar.gz files, even 64MB is undersized. But the backup process would be tuned to the task at hand and not cause failures due to too many connections.

@joseph I agree. I looked at some of the implementation requirements and it takes effort. With each Cloudron app update and server reboot, it requires a process to "turn on" the server. That involves presenting several keys to unlock the server. For large companies with dev ops resources, this is doable. But for smaller companies, it is too much effort with a huge risk of bringing down applications if you miss a secrets server reboot.