@girish It really was caused by uBlock Origin. After disabling it, Umami appears to load all pages correctly. In Uptime Kuma, I removed and re-added the HTTPS address for Umami, and now everything works fine. Thank you very much for the information; I would have never thought of that.

And we're up and running again!
Thanks again @girish , without your help I wouldn't be able to get it running again.

Thank you so much! For some reason, I always looked in "View" instead of "Edit".

Thanks. That worked. I augmented from initially 2GB to 4GB.
Strange this happens to the instance with a tracker on only one website. My other instance with trackers on four websites had no issues. But by the number of single URL/pages tracked, the first instance has much more single sites to track.

@girish yes its working now thank you i will observe

I have that installed, and it recognizes traffic, but not clicks or anything

@psifertex iirc, I think that changed happenned from 1.x to 2.x .

@d19dotca @Meuschke this should be finally fixed in the latest update.

@d19dotca Interesting, on the new fresh install, I restarted and voila, it works !

on my old install, the one I don't want to loose the site ID's (even if I lost the historical data, that's fine)

I see this error after restart :

==> Starting Umami May 26 10:33:14 May 26 10:33:14 May 26 10:33:14 Inconsistent column data: Error creating UUID, invalid character: expected an optional prefix of `urn:uuid:` followed by [0-9a-zA-Z], found `u` at 1 May 26 10:33:14 Invalid `prisma.website.findUnique()` invocation: May 26 10:33:14 PrismaClientKnownRequestError: May 26 10:33:14 at async NextNodeServer.runApi (/app/code/node_modules/next/dist/server/next-server.js:514:9) May 26 10:33:14 at async NextNodeServer.runImpl (/app/code/node_modules/next/dist/server/base-server.js:432:29) { May 26 10:33:14 at async Object.apiResolver (/app/code/node_modules/next/dist/server/api-utils/node.js:372:9) May 26 10:33:14 at async Object.fn (/app/code/node_modules/next/dist/server/next-server.js:828:35) May 26 10:33:14 at async Router.execute (/app/code/node_modules/next/dist/server/router.js:243:32) May 26 10:33:14 at async __WEBPACK_DEFAULT_EXPORT__ (/app/code/.next/server/pages/api/websites/[id].js:154:25) May 26 10:33:14 at async t._request (/app/code/node_modules/@prisma/client/runtime/library.js:179:10484) May 26 10:33:14 at pn.handleAndLogRequestError (/app/code/node_modules/@prisma/client/runtime/library.js:176:5907) May 26 10:33:14 at pn.handleRequestError (/app/code/node_modules/@prisma/client/runtime/library.js:176:6477) May 26 10:33:14 at pn.request (/app/code/node_modules/@prisma/client/runtime/library.js:176:5786) May 26 10:33:14 clientVersion: '4.13.0', May 26 10:33:14 code: 'P2023', May 26 10:33:14 message: 'Error creating UUID, invalid character: expected an optional prefix of `urn:uuid:` followed by [0-9a-zA-Z], found `u` at 1' May 26 10:33:14 meta: { May 26 10:33:14 }

@jayonrails Remember, Cloudron helps you manage your server and apps. To really understand the apps you want to run you need to reading up on those apps. There are times when Cloudron's implementation may have some effect on an app, but please read all you can about the apps first before thinking all your answers should be answer(able)ed by Cloudron. I don't know if @girish had that link saved already for exactly such a question, but it is the sort of thing you could have found yourself, too.

@girish Created a formal feature request at https://forum.cloudron.io/topic/9144/system-disk-usage-should-include-database-consumption-of-each-app/1, just FYI. 🙂

We pushed the new package with 2.0.0. Note that only website/domains are retained across the update. All event data are lost across the update. For this reason, this package is a major release.

Documented this at https://docs.cloudron.io/apps/umami/#custom-endpoint

@girish said in Umami packge 2.4.1+ breaks TRACKER_SCRIPT_NAME:

@d19dotca I removed your salt. But maybe you can change it for good measure in your installation.

Good catch! Sorry I missed that 😅 I’ll change it quickly as a precaution.

@girish that’s perfect, thanks so much! I’ll try this out tonight.

OK, docs updated and package pushed.

I might set up another instance for a friend in a few days, we'll let you know.

@girish That worked! And the migration worked properly. Thank you!

@nebulon said in Reduce minimum RAM requirements?:

Looking at the start script, umami needs a lot of resources to start up, so this is likely why it is like this.

Ah

@nebulon said in Reduce minimum RAM requirements?:

To improve here, we would need som burst memory limit

That would be good

@nebulon said in Reduce minimum RAM requirements?:

but all in all those limits are merely to discipline some language runtimes to run garbage collection more often and in the worst case cause that the whole server becomes unresponsive due to one app.

Not really following, but OK.