28.0.3-rc2:
- Slow performance on file transfer: Not fixed
- Federation does not work: Not fixed
- Photos app DoS when scrolling large libraries: Not fixed
- Preview generation: Completely useless in all regards and should be disabled and rewritten
2 Likes
EDIT: Let’s take follow-up to your existing thread: Photo viewing cripples server
- Slow performance on file transfer: Not fixed
Is there an open GitHub Issue associated with this so we can understand what it is you’re referring to?
- Federation does not work: Not fixed
Is this a reference to a specific open Issue?
- Photos app DoS when scrolling large libraries: Not fixed
Is this a reference to a specific open Issue or more a general a comment on your experience?
I’m curious: What are your preview concurrency parameters set to relative to your server’s CPU core count?[1] Are you using/not using Imaginary for previews? What media formats do you have previews enabled for?
- Preview generation: Completely useless in all regards and should be disabled and rewritten
Are you referring to the previewgenerator app used for generating previews offline?[2] (If so, it’s not a shipped app so it has no relevancy/connection to new Server releases since it’s independently updated/released). If you’re not referring to that, but just previews in general, then my questions to the prior item apply.
[1] Configuration Parameters — Nextcloud latest Administration Manual latest documentation
[2] GitHub - nextcloud/previewgenerator: Nextcloud app to do preview generation in the background.
No, there is not an “open github issue”. I’m one of literally thousands of people who have brought this up (do a quick google for things such as “NC server is catastrophically / painfully / astonishingly / infeasibly slow” and you’ll find no shortage of people complaining that even over a LAN, and with no WAN at all, Xfer speeds are in the toilet.
I’m not opening a “github issue” either. “Open a github issue” is (and has been in my entire 35 years of OSS experience) code for “Please go away”. People who really want to deal with a users issue will either:
- Work out that it’s a prexisting problem and point them at a “github issue” that they’ve already created to help users out .
- Work out that this is a new problem, and work with the user to explore / document the issue, eventually either developing a fix or workaround, which can then be documented by opening an issue.
Theres no issue for Federation, either, because I havent opened one. I came to the forums to talk to people and ask questions. I do my best to also impart what knowledge I do have (you can easily see I’ve been helping others), and I do my best to not ask questions that have already been answered.
I’ve been here 8 days, and I’ve read over 400 posts, and made 30 odd.
I’m smart enough (and been doing IT stuff long enough) that I can see when I’ve done all the proper steps, only to find that it doesn’t work and that the reason is undocumented.
Thats WHY Ive come to ask for help here.
I’ve another thread re: federation - its here:
And another re: the photo app DOS - read here:
Until last night, preview concurrency was “whatever the default is” because I had assumed that the devs would select sensible defaults - either “not much”, or some heuristic, like “CPU cores -1 or 1 at minimum” or “cores/2 rounded up”, rather than the completely insane “infinity” which is the default.
I also had no idea there was an option for changing it until last night. No-one else has mentioned it to me until now, after I already found it.
Its certainly not mentioned in the setup guide, which is where it should be, since the defaults are insane, and guaranteed to DOS anything but a tricked-out gaming rig…
I am referring to the built in preview generator, although I’ve disabled that now and am using preview-generator.
If you select (as I’ve done) a max size preview of 256x256, then when you go to ACTUALLY look at your photos (ie. not just previews thumbnails), they look like total sh*t, because you get a scaled up 256 x “whatever” image, not the actual original.
Why? If I click on the thumbnail image, I WANT THE ORIGINAL (like anyone else would).
What this means is that I can either cripple my machine (ie. let the preview generator generate unlimited previews up to the 4K (!) defaults), because all my pictures are <4K, and so at least I’m guaranteed to always see them in full quality when I open them,
or I can run the preview-generator app (yes, I know its not in the base install) and have useable speed scrolling in Photos, etc., but then I can never see the images in full quality in the “Memories” app. (which I have to use, because “Photos” is so utterly CR*P that its useless in every way - Slow, hard to use, DoSes your server etc.)
What I want is for previews to never be >256x256, but for apps to ALWAYS open the original image when I click in the previews. Not just the “largest preview”, which is uselessly small for fullscreen display.
I can’t believe anyone capable of coding actually took the extra time it must take to screw this up. The rules are really simple -
- If rendering a thumbnail, select the closest size that matches or exceeds the size you want,or if > the largest thumbnail, simply use the original).
- If rendering the main image, ie. NOT rendering a thumbnail, then use the original image.
I mean, seriously - if it has to generate a 100% resolution thumbnail in order for the f*cking photos app to display a clean image, that really is insane. The image is already there on disk. WTF. Why is NC wasting my disk duplicating the original image?
1 Like
Guess I’ll head back to GitHub and keep slacking off like the rest of the devs. Sounds like you’ve got it all figured out and don’t need anyone’s help. Good luck!
1 Like
Oh come on.
That’s a cop-out and you know it.
I’ve raised a ton of very valid points that should make anyone on a project think twice.
And all I got is
“Did you open an issue”
“No, I like human interaction”
“Please go away”
Exactly as predicted.
1 Like
Try answering just one question - “Why does NC need to waste 100% of the space a file occupies by generating a full resolution thumbnail of it?”
This isn’t the thread for this.
I only asked about relevant GitHub issues because you posted on a release announcement with a comment that implied these were specific open bugs that you’d hoped/expected these to be fixed in the release. I wanted to look them up to see if something got missed. 
It’s clear you’re frustrated, but you need to refer to the community’s Code of Conduct: https://nextcloud.com/contribute/code-of-conduct/
I’ve tried to help a bit in some of your other threads, but you’re attitude isn’t really motivating. You come off as somebody that wants help, but also already feels they’ve already got it figured it all out. There is always room for improvement with Nextcloud - that’s literally why there are people doing development everyday on the core and in the various apps as well as expanding the documentation and interacting here.
If you have suggestions and ideas, great.
If you need help, cool.
If you think you may have found a bug, awesome.
If you aren’t sure what you’ve found yet, that’s cool too.
P.S. If you want a turnkey / pre-optimized (though certainly not appropriate for all situations) Nextcloud Server deployment you may want to evaluate/test/compare something like Nextcloud All-In-One, but that’s another story.
No. This is NOT an end user fault. I refuse to accept that.
It should be entirely reasonable to expect an un-cached, non-jit NC, running on hardware from this decade to manage over one megabyte per second straight out of the box with the webserver config from the documentation.
Fundamentally, all that should involve is copying one file, unzipping the install, and letting it rip.
1.07 MiB/s syncing a file that is all zeroes even over a software encrypted connection should not be that slow
This is a fresh Debian install underneath - not repurposed old boxes.
If it’s not that easy to get a basic install up and running, one that can manage, lets say, 10MiB/s (that’s only 100Mbit/s), then the default install is simply BROKEN.
I’d be happy to “tune” the thing if I wanted more than that, but it simply shouldn’t be necessary to “tune” it to get it to work at speeds that are actually lower than my (pretty basic these days) internet connection. (80Mbit/s).
I didn’t expect it to come set up “tuned perfectly for a bizarre workload”.
Just “well enough to allow me to explore / use it”.
And it doesn’t.
Locate the bug on GitHub. If it is not there create one. This is how it works. If it is just reported to this thread it will not be worked on.
And php is not jit and it does require a cache. It is designed to run on everything from s tiny raspberry pi to a large server cluster.
Tone down a bit. This is on a news thread and everyone on the forum will get these mails.
1 Like
Is that stated NC policy?
[quote]And php is not jit and it does require a cache. It is designed to run on everything from s tiny raspberry pi to a large server cluster.
[/quote]
PHP 8 most certainly does have a JIT. and an opcache. It requires neither to function, however.
It is how most open source software works. Just reporting in a forum is mostly not enough.
You are right php 8 has jit. but opcache needs tweaks and it needs to be installed and enabled. And other caches for different stuff to offload the database is needed for optimal performance.
It is in the installation and administration guides, and Nextcloud will complain in admin settings if you don’t have it.
That’s how many small, volunteer driven, open source projects work, but it 's not the way they must work.
Nextcloud is a for profit company with paid developers. It’s also a company that uses its community as unpaid beta testers.
This is a forum run by that company, which the company invites users to contribute to. As such this forum is seen by the community as an official, and proper way to communicate with the company.
It’s completely understandable that ‘if if doesn’t have a GitHub issue, it’s not going to be worked on’. But it’s not acceptable to tell users, who have already taken time out of their day to report a problem, to go file those issues themselves in addition to the reports they already made. That behavior really is saying ‘Please go away’.
To all the paid Nextcloud developers here, please ask yourself why you are participating in this forum. Are you here to help users and improve your product? Or are you here to alienate and gaslight your users?
If a user reports a problem here and you actually want to help, and there isn’t an existing GitHub issue, go file one yourself, that’s part of your job as a developer. If you need more information, point the reporting user to the issue you just created and ask then to contribute more there.
The attitude I’m seeing here from the developers is driving me to seek an alternative product.
1 Like
Who are you referring to?
1 Like
Someone with the handle ‘jtr’:
Guess I’ll head back to GitHub and keep slacking off like the rest of the devs. Sounds like you’ve got it all figured out and don’t need anyone’s help. Good luck!
I’m not paid.
1 Like
So you’re voluntarily alienating and gaslighting users, even better.
Please point out where I did that.
I already did.
-
Someone points out that your behavior is alienating and harmful, and your response is to argue with them?
-
You are asking for me to do more work to correct your behavior. Which is just repeating your original mistake. Asking others to do your work for you.
-
Paid or not, you are representing yourself as a developer. Therefore you are casting a negative light on all developers on this project and alienating countless users, who you are already relying on to do free labor and free marketing for you.
My primary point stands. Please think about why you are here. Are you really here to help? Great, then be helpful. If you’re here to hurt this project, then carry on as you are.
Are you sure you’re not the one misreading the situation here?
I never told anyone to file anything on GitHub in this thread.
I asked if there were GitHub issues so that could I check the context out (because there weren’t any details in the original comment).
This is a release announcement post. When someone comments on it about four bugs that are apparently not fixed, without providing any further context, is it a stretch to ask which GitHub issues they are referring to?
I’m not going to rehash the rest because it’s all above in the thread itself. And the original commenter has taken their follow-up to an existing dedicated thread covering their situation.
2 Likes
What do you mean by that? It is of course not mandatory to follow this as a policy.
However, neither is there a policy in any open source project that guarantees or warrants anything, including that the product will work the way you want, or that someone will fix any issues you’re running in.
All you can really do is ask nicely. However, the developers are under no obligation to fix issues you report or otherwise respond to your requests. The only thing that will grant you certain rights, within the agreed terms of course, is an enterprise subscription / support contract.
1 Like