Continuing the discussion from MusicBrainz Web Home Page Mock Ups:
Here are interesting (at least for me) topics about it (most recent first) from meta.discourse.org:
Continuing the discussion from MusicBrainz Web Home Page Mock Ups:
Here are interesting (at least for me) topics about it (most recent first) from meta.discourse.org:
4.6MB for a photo of a sketch on a notepad is a classic example of where compression save bandwidth with no loss of comprehension. Compression on the sever saves so much more on data transfer on the clients. You can say it then saves on time for those with lower bandwidth and power for those of us not having to download a huge image.
On average these are being displayed in a very zoomed down format on the webpage anyway.
I did the change, the limit is now 10m on the nginx proxy in front of discourse (discourse has its own nginx instance, with 10m limit too).
Thanks for the links! Looks like the relevant composer options are not available in our current version. I’ve set a reminder in a month and I’ll see what version we’re on then (and will likely set another future reminder and check etc. until we’re on the new major version with the feature).
Just a first quick hint, if here you press Ctrl+U (see page source), you can see the version we are on:
<meta name=“generator” content=“Discourse 2.7.8 - GitHub - discourse/discourse: A platform for community discussion. Free, open, simple. version 18b6f4ecf6d3513af90b8a54a3514dfa160044d8”>
It appears to be the very latest commit/version on stable
branch, so it’s all good.
You cannot really compare with beta.discourse.org because they are always on main
branch’s latest commit (just 4 hours ago, for instance now):
<meta name=“generator” content=“Discourse 2.8.0.beta6 - GitHub - discourse/discourse: A platform for community discussion. Free, open, simple. version 77b8347158de30c86fdb11ec1ac5d6617facf16d”>
I can also see the version at https://community.metabrainz.org/admin
Client side image optimisation should be enabled now. Do let me know if something seems off with it!
An image I uploaded is still being “processed”. It’s ca. 4.35MB
Not sure what’s going on there, but it seems unrelated to this feature discussed here (which is client-side only). Maybe @zas can look at some logs to figure out what’s happening? Did you try uploading the image again?
Found the cause. I’m always running out of memory…
While processing it was using up to ~1.600.000 KB
At one try it crashed even: SIGTRAP
media-optimization-worker.js:90 Resize failed: RuntimeError: unreachable
optimize @ media-optimization-worker.js:90
onmessage @ media-optimization-worker.js:124
mozjpeg_enc.js:9 Insufficient memory (case 4)
printChar @ mozjpeg_enc.js:9
_fd_write @ mozjpeg_enc.js:9
$func185 @ mozjpeg_enc.wasm:0x18f2e
$func98 @ mozjpeg_enc.wasm:0xd275
$func58 @ mozjpeg_enc.wasm:0x79ba
$func169 @ mozjpeg_enc.wasm:0x18636
$func171 @ mozjpeg_enc.wasm:0x186ab
$func163 @ mozjpeg_enc.wasm:0x17b63
$func192 @ mozjpeg_enc.wasm:0x1c52c
$func193 @ mozjpeg_enc.wasm:0x1c993
(anonymous) @ mozjpeg_enc.js:9
optimize @ media-optimization-worker.js:99
onmessage @ media-optimization-worker.js:124
media-optimization-worker.js:141 ExitStatus {name: 'ExitStatus', message: 'Program terminated with exit(1)', status: 1}
onmessage @ media-optimization-worker.js:141
media-optimization-worker.js:142 Uncaught (in promise) DOMException: Failed to execute 'postMessage' on 'DedicatedWorkerGlobalScope': Data cannot be cloned, out of memory.
at onmessage (https://community.metabrainz.org/javascripts/media-optimization-worker.js:142:9)
onmessage @ media-optimization-worker.js:142
Not sure there’s much, if anything, we can do on our end about that. :\ Maybe upstream Discourse can do something in this case?
I’ve worked around it by uploading from my phone instead.
I guess in that regard a phone with lots of RAM does pay off.