Hello @archos
I've looked into it and the version you have installed org.tt_rss.cloudronapp:3.0.0 was the final update and was a manual update (which you had to confirm manually) with the following release note:

CHANGELOG.md

[3.0.0]
* **IMPORTANT:** This package uses MySQL and upstream TinyTinyRSS has dropped support for MySQL. This is the last release of this package. We have published a new package which uses PostgreSQL. Please switch to the new package using the [migration guide](https://docs.cloudron.io/apps/tinytinyrss/#migrating-from-mysql-to-postgresql) .

Which looked like this:

So you must have not noticed this while applying the manual update back then (~28 April 2025)

I will think about how we can make this more noticeable to users in the future.

Hello @ekevu123
Can you provide the backup logs of one of the latest backups that takes this long?

Hello @archos

@archos said in Tiny Tiny RSS – updates not showing up:

Sorry for the unnecessary question!

No question is ever unnecessary. Please never hesitate to ask away if something is unclear.
This helps us improve.
It seems the change was not communicated well enough so we can improve here.
Maybe in the future, a "discontinued" app should get a final update with a changelog notice that informs the user about the state of the app and possible migration steps?
Do you think this would have made you aware?
Open for other suggestions.

Hello @archos
I notice that your package id is org.tt_rss.cloudronapp but @tiny-tiny-rss package now is called org.tt_rss.cloudronapp2 that is why you are getting no updates for the app.

This happened because on 22 April 2025 the app was moved to PostgreSQL instead of MySQL.

See also:
@nebulon said in Tiny Tiny RSS - might drop support for MySQL:

We've released a new package with a new appstore id for the postgresql version of tinytinyrss. This is a whole new package, so automatic updates will not migrate to postgres, as there is no good way to automatically migrate.

We've written the steps to migrate over via OPML at https://docs.cloudron.io/apps/tinytinyrss/#migrating-from-mysql-to-postgresql

Hello @hakunamatata
I assume you are using Cloudflare, right?
Can you check your DNS configuration and check/uncheck the proxy part and save the config again?
This might already solve it.
Still, this seems like an unintended bug from the upgrade.

Hello @mononym

You can always create a clone from your latest backup and tinker with the clone.
With that approach you risk nothing and can report findings.

Hello @GuillaumeRZ

Without the real domain I can't look up the DNS records.

The only manual DNS records needed would be:

A *.mydomain.com 51.XX.234.115

and

AAAA *.my.domain.com IPv6 Address

In the log, it expects if the AAAA record is 2001:XXd0:b00:fb00::2.

And since you only stated you have configured A records, yes the AAAA record is missing.

Hello @dylightful
I have restored your original post for context.

@dylightful said in Unable to Install Older Versions of UptimeKuma:

Version 2.0 broke our UptimeKuma site when attempting to update.

You can clone the app from the latest backup and then attempt to update the clone.
If it still fails, please checkout this topic: https://forum.cloudron.io/post/114707

Hello @samuelhalff and welcome to the Cloudron forum

The version you are referring to is v0.8.1-rc1 correct?
Since rc stand for release candidate we will have to wait for the stable release of 0.8.1.

Also, a great topic for https://forum.cloudron.io/topic/14481/community-event-workshop-webinar-app-packaging

@stoccafisso said in Install errors:

Will this work well for later updates of the app?

I am trying to fix this issue without this dirty hands-on fix.
So, if I get this fixed, my quickfix guide is not needed.

The following guide will delete all existing data

If you want a quick fix right now - after the installation, put your app into recovery mode.

Open the web terminal and delete all data in /app/data/*

rm -r /app/data/*

In the web terminal drop all tables from the database:

mysql --user=${CLOUDRON_MYSQL_USERNAME} --password=${CLOUDRON_MYSQL_PASSWORD} --host=${CLOUDRON_MYSQL_HOST} ${CLOUDRON_MYSQL_DATABASE} -Nse 'show tables' | while read table; do mysql --user=${CLOUDRON_MYSQL_USERNAME} --password=${CLOUDRON_MYSQL_PASSWORD} --host=${CLOUDRON_MYSQL_HOST} ${CLOUDRON_MYSQL_DATABASE} -e "SET FOREIGN_KEY_CHECKS = 0; drop table \`$table\`"; done

Edit the /app/pkg/start.sh and find this section:

    echo "==> Finish configuration"
    $curl http://localhost:8000/installer/config/finish
    $curl http://localhost:8000/installer/config/finished

Comment out the two curl statements, it should look like this:

    echo "==> Finish configuration"
    # $curl http://localhost:8000/installer/config/finish
    # $curl http://localhost:8000/installer/config/finished

Save and exit the file.

Run the start.sh manually with:

/app/pkg/start.sh

It will run once and exit, after that, run the same command again.

/app/pkg/start.sh

Now that it is running, visit your Humhub url.
You will see the manual setup process:

After finishing this guided initial setup you can login with admin and changeme and will have all the demo data including the user profile fields.
You can turn off the recovery mode now and the app will work as intended.

The issue is somewhere in the first startup.
It tries to load the demo data but does not install any module's or loads the demo data.
Already on it to figure out why this is not happening.

Hello @stoccafisso
I already have 2x fresh humhubs installed.
1x OIDC version and 1x local user management version

I am just trying to gather as many details as possible to get this sorted out asap.

@stoccafisso said in Install errors:

That does not indicate that the problem is related to the cloudrons or DO-droplets themselves, so that leave it to the app (and its installation script/procedure) to be investigated. IMHO.

I never stated this is a problem just for you, and I am already trying to figure out where this is going wrong in the Cloudron app.

Hello @stoccafisso

@stoccafisso said in Install errors:

Also, a standard HumHub installation done the traditional way comes with preconfigured standard profile fields. I find it very strange and unlikely that the cloudron version of the HumHub has gotten the profile fields stripped away "by intelligent design". If so, then why?

That is what I am trying to figure out.
Where or at which step these fields get created and why it is not present for the Cloudron app.

Could you please check in your working HumHub installation if these profile field may be configured in a file in /app/data/config?

@stoccafisso said in Install errors:

To illustrate I will post two images from an earlier HumHub installation that works as it shall do.

What version of HumHub is this? Are any modules installed?

Hello @stoccafisso
The Humhub app version 1.8.3 which packages HumHub 1.17.4 is the latest available version in the app-store.

Could you please go into detail what you would expect there?

In HumHub you can create your own User Profile Attributes under /admin/user-profile.
You can create new profile category e.g. named Personal Details:

and add custom fields

Here I added Nickname and What foods can I eat. One a freetext and one a checklist. Be sure to mark them as editable.

Resulting in these two fields in the profile which I can fill.

I hope this helps.

I just reproduced this as well. Indeed, it seems this sorting does not work and there is no error in the browser console.

In your browser, when you press F12 you get the browser console.
Sorry, that was a little confusing formulated.

Hello @ekevu123
Can you please open the web console and see if there are errors present when doing this?

Hello @dgtlmoon

Maybe I am understanding the scheduling settings wrong.

The full log since installation can be viewed here: https://file.cloudron.dev/api/v1/shares/sid-0387aa81cfe5d4aa1b40368f38b4004bd7242e862414b781d1fbed7d2d7c8601?type=raw

If you'd like to look at the UI yourself the password is dd6de65db716 and the URL https://io.changedetection.cloudronapp.cloudron.dev/
Here is the replicated setting from this post.

It is the latest version v0.50.39.
From https://changedetection.io/tutorial/checking-web-pages-changes-according-schedule

For example, if you combine a "Time between recheck" of 1 days, and then click the "BUSINESS HOURS" shortcut, it will automatically configure a time schedule that runs from 09:00 for 8 hours (until 17:00h), and since you have "recheck" time set to 1 days, it means it will only check once per day at 09:00.

So I'd expect these setting to have created a check at 04:00 o'clock.
But the last check was a manual one and no sceduled check at 04:00.

But maybe I am just understanding the setting wrong.
Thanks in advance @dgtlmoon