Cloudron Forum

@girish said in Easy appointments:

http://easyappointments.org/

Is this still our top candidate for a self-hosted scheduler?

I'm dying to get out of Calendly + Zoom and go to Easy Appointment + Jitsi and kill off google calendar completely once and for all. (I'd need to be able to run automations off the back of the scheduler as well...so will check that requirement as well.)

If this is still the project we wish to champion, let's rally.

I'll put up a donation if 3 others are wiling to match, once someone closer to this is able to confirm this is the path forward.

@subven it worked! My test video plays instantly and smoothly now!

face palm on my part for not looking directly for a config file to turn off federation....

Thanks for the lift @subven This came up big!

Let's get this across the finish line!

A decent scheduling alternative will be huge!

From what I can tell one of us just needs to:

1. successfully complete a docker build (looks like @roofboard has made a start, well done )
2. add the cloudron packaging files
3. I'm knew to this game, but it seems like we should then send a pull request to the main cal.com repo -- why not just stick with the primary repository on this one?
   ( thanks to @jdaviescoates 's github issue, they've stated their friendly to having this available on cloudron)

@girish is there an official packaging queue that the cloudron team is working on? I don't see any "WIP" tags as mentioned above. Would be helpful for planning purposes.

For instance, lack of a real scheduler is a gaping hole I need to fill, not sure where cal.com app is in the queue or if there's a known issue preventing progress or if it's already being worked on, etc.

Just a quick update from me....

I did an initial test using cal.com (hosted by them) and their CalDAV integration with NextCloud, and it failed some of my required use case tests (recurring invites were buggy.....although it looks like one of the use cases may have been fixed already, so this means progress is being made....and I may need to re-test soon).

So this isn't quite high enough priority for me to mess with getting the deployment on Cloudron figured out since it can't quite solve my use case yet....

However, if you want this to progress, here's what I suggest:

1. start using/testing a hosted cal.com account
2. since you likely don't want to hand them your main login credentials, if you're using NextCloud, you can make a separate "scheduler" user, and then share that calendar with your main calendar. (NextCloud seems to have gotten much better at this.) Or...just make a test account and try it.
3. post issues and talk back to the cal.com team.

The Cal team has a CalDAV integration issues roundup here you can check, comment on, prior to posting additional issues that you run into: https://github.com/calcom/cal.com/issues/3457

@girish it seems the most recent update worked....while i did change some email settings, the only other action I took was manually bumping along the updates several versions. So there must have been some sort of inconsistent state that came up.

It seems all is well with the world and no way to track down what happened.

Thanks for the help, all.

@roofboard re: "I cannot figure out why it is stuck on localhost:3000 as opposed to accepting the new dns settings" --
can you provide further details on the problem you've run into? Is this when you're just trying to get it to run on docker on your local machine? or when deploying as a custom cloudron app? I'm unclear what the status is.

Some further elaboration might help us or @girish troubleshoot. If it's not cloudron specific, let's get a thread going with cal.com if we need to.

@marcusquinn thanks for this resource. I hadn't seen this service before.

It doesn't replace deploying an app on cloudron (especially if the app mashes up several other cloudron apps.) But useful nonetheless!

@girish After thinking about this a bit more, it seems the optimal solution for "developer apps" isn't a published app, but some git repos of a few starter custom apps (dockerfile + ldap login + config instructions for a database if needed) specifically.

I know all the published cloudron app repos can be viewed (as linked in the packaging tutorial). Perhaps that is sufficient.

I'm building what is effectively a cloudron mashup (tying multiple apps together, LDAP, + private dns so API calls are local).

I'll provide further feedback if the current tutorial materials seem insufficient.

@subven thanks a lot for helping us get to the bottom of this.

The webtorrent selection UI in the settings is a bit odd (and the peertube documentation has no search functionality), so your writeup should hopefully help any future travelers figure it out.

I was able to find the the relevant section in the Peertube Docs now that explains these options a bit. HLS is actually the recommended setting by them as well:

We recommend you to enable HLS (and disable WebTorrent if you don't want to store 2 different versions of the same video resolution) because video playback is really better

https://docs.joinpeertube.org/admin-configuration?id=webtorrent-transcoding-or-hls-transcoding

@luckow said in Jitsi Installation Recipe for >10 Participants?:

@tshirt-chihuahu I followed https://jitsi.github.io/handbook/docs/devops-guide/devops-guide-quickstart on a hetzner cx21 (around €6.00/month). It's a good fit for up to 15 concurrent user.

That's great news! Thank you.

Something must've changed since last year, as I wasn't anywhere near being able to support 15 users with similar specs.....but this is fantastic to hear. I'll give it a shot.... If only there was a US host as well-priced as hetzner

There are tons of use cases for a python analogue to the LAMP stack app.

While this could perpetually live as custom deploys in our private docker images, I think it would be handy to have a version published in the cloudron app store.

Some thoughts on implementation:

• Database URL provided in config(?) Given cloudron apps can be configured to talk to each other over the private/internal cloudron network -- seems reasonable to either just leave a database off this app and take a Database URL in a config file, if a database is needed at all. User can then select whichever backend is most appropriate.
• Read in and install from Requirements.txt (?) If I can hit deploy on cloudron, drop in a requirements.txt file from "pip freeze" somewhere to have additional dependencies installed, and then have a python app with LDAP user directory already good to go, life will be good.

Or do you guys think this is better left to just custom app deploys?

If you've already deployed a custom Flask app (even better if it uses the LDAP directory) on Cloudron and are willing to share your setup, I'd definitely appreciate not spending time re-inventing the wheel.

@girish understood. thank you.

The upgrade from Cloudron Limesurvey release 1.34.11 to 1.34.12 broke the "export_responses" API call (throws a 500 error).

• Verified API call works on 1.34.11
• Verified API call does not work on a fresh install of 1.34.12 (to rule out any strange state in my primary install that is several months old).

Nothing related to api listed in change log for this release:

Changes from 5.4.12 (build 221121) to 5.4.13 (build 221128) November 28, 2022
-Fixed issue: gid suffix was missing in aRDP_regexpStaticAttribute array (Tim Willig)
-Fixed issue #18463: List of uploaded files should be sorted alphabetically (#2722) (Gabriel Jenik)
-Fixed issue #18461: Survey groups at survey list screen should be listed alphabetically (#2724) (Gabriel Jenik)
-Fixed issue #18424: Typo in debug message (#2705) (Gabriel Jenik)
-Fixed issue #18395: Access to limereplacementfields didn't check read permission on survey (#2655) (Gabriel Jenik)
-Fixed issue #17648: Email received by participant is empty (#2691) (Denis Chenu)
#Updated translation: Portuguese (Brazil) by rafaelmaia
#Updated translation: Polish by elissa
#Updated translation: Polish (Informal) by elissa
#Updated translation: Luxembourgish by Mazi
#Updated translation: Italian by lfanfoni
#Updated translation: Italian (Informal) by lfanfoni
#Updated translation: German by c_schmitz
#Updated translation: German (Informal) by c_schmitz
#Updated translation: French (France) by b00z00, DenisChenu, Nickko, sim.eesp
#Updated translation: Dutch by Han
#Updated translation: Dutch (Informal) by Han
#Updated translation: Chinese (Simplified) by hdaphq, humandynamic, xiongrui, zengqing, zhanginshanghai, Zoctan
#Updated translation: Azerbaijani by Heyder

Reporting here in case this is a cloudron specific issue -- there are some more recent releases of limesurvey that don't mention any issues being noted yet in the changelog.

Will also check with LimeSurvey directly to see what I find.

This is a critical issue for me that interrupts service. However, I was able to roll back to the prior release as a temporary fix that seems to only have created data migration headaches.

Would appreciate any intel that anyone finds related to this issue.

@jdaviescoates thanks for this. I actually re-uploaded the same video to my instance to use it as a benchmark.

On your instance I can see the download speed spike to a more reasonable speed to get the video buffered as shown on the peertube interface:

This doesn't happen with mine.

So unless there was some sort of configuration that you improved (i haven't been able to find anything in the Peertube Admin), so at least thanks to your help we've ruled out that it's something to do with the basic function of Peertube.

@nebulon Based on my time-limited search, wasn't able to find a way to submit an issue that seemed viable. Limesurvey github project has issues deactivated. Quickly checked site, have forum, but decided not to mess with it.

Was able to find a fix though.....see below

@subven @girish An alternative suggestion to disabling by default: calling this setting out in the cloudron app documentation. ( I'm kind of surprised this hadn't come up in the forum yet.)

I was unable to find any official documentation showing a breaking API change. However I did find this python library that seemed to be on top of its game: Citric.

Their "save_responses"/"export_responses" method still worked, so as a temporary measure I was able to drop in their method to get data flow working again.

I haven't dug into their code further yet to see what specifically changed/broke, but I'm going to mark this thread as resolved (before I lose it), as someone can read that code to find the specific solution if needed.

Also, for those that don't know what HLS is (I didn't prior to running into this issue), here's a link to get you started with "HTTP Live Streaming":

**Adaptability **
To enable a player to adapt to the bandwidth of the network, the original video is encoded in several distinct quality levels. The server serves an index, called a "master playlist", of these encodings, called "variant streams". The player can then choose between the variant streams during playback, changing back and forth seamlessly as network conditions change.

https://en.wikipedia.org/wiki/HTTP_Live_Streaming#Adaptability