Cloudron Forum

This is awful. Nextcloud calendar has become (effectively) unusable. Has anyone found a workaround? @nebulon were you able to figure out why you could not reproduce? Perhaps that's a potential workaround....

@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.

@girish I'm pretty sure i checked and there wasn't. I'll check again after the next scheduled automatic update and report back here to see if I see anything that points to an issue.

I've just re-installed Ghost to make this a non-blocking issue (and went through the brief hassle of re-importing content and configuration.) So this is a non-issue for me now.

@girish changing the update schedule didn't make a difference since updates were scheduled before, they just weren't being executed. So now they just fail to execute more frequently.

@girish
backups are working.

Cloudron platform version: v7.3.6 (Ubuntu 20.04.1 LTS)
Ghost package version: org.ghost.cloudronapp2@4.6.0

I hadn't used my Ghost install for a while. Automatic updates have been on the entire time:

However, it seems updates have not been happening. It's currently at 5.5 where 5.37 is the latest. So manually moving forward 1 step each time is not desirable.

2 questions:

1. Any reason why updates aren't updating automatically?

( Possible answer: I have not updated my cloudron for a while.....which is another issue i need to address.....cough cough...SSH keys lost)

2. Any recommended way to update to the latest Ghost without resorting to manually pressing the UI update buttons 30+ times? Can I just go into the app's terminal and use the ghost update command?

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.

@girish Thanks for chiming in on this promptly. There were no errors in the logs (just showed a 500 response returned.)

Was able to get this resolved, see below.

@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

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.

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

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

@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

@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.)

@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!

@subven I have not explicitly opened that port on the Vultr server, so I'll assume not. However, I had been under the impression the RTMP was only relevant to livestreaming.....
I'll assume that's not the case now. Thanks for the lead.

@subven Been working on it. Open to other hypotheses to better narrow in on the "right spots."

It's definitely not the device or the network—the clip kindly provided by @jdaviescoates downloads and plays just fine on same network/machine.

No sign of crash notifications. The app is responsive, the download speed of the video is just slow.

@girish I'll DM/email you. I'm out of ideas.

Only bottlenecks I can think of are:

1. memory( i would think this would show up in the usage graphs)
2. cpu
3. disk i/o ( Vultr advertises SSD)
4. network connection ( seems unlikely)

CPU seems the most likely culprit. Server has "4 vCPUs", CPU usage chart shows a spike from 18% to just under 30%:

Outside of my expertise here, but I believe by default Docker containers are single-threaded. On Cloudron I've got processor resource availability set to 100%, but perhaps it's possible this gets "under-reported" in the Vultr CPU usage chart because it's actually maxing out 1 of the 4 "vCPUs", but the PeerTube process is nonetheless maxed out......that's my current remaining feeble idea.

I'll open a ticket with Vultr as well.

@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.

@girish understood. thank you.