Commitblockmarker stalling

Brownout woes - version being updated to already exists

Putting things together from two topics is probably worse.

Not clear on this reference. Is this partly referring to

which was named in one post (which doesn’t show much from single view of status)?

There is no mention over there of filesets. Filesets correspond to dlist files not dblock.

Then the latest version would have the bad data, but should still restore without issue.
Ordinarily one just uses a version before the problem, but I see the version statement:

which maybe you can clarify, as I don’t use MEGA, so don’t know the connection there.
Duplicati versions are independent of any versioning that the storage provider provides.

If you know times of the brownout, you could tell if there’s a pre-brownout backup there.
Restore (if you have a database) has times. Or begin a Direct restore from backup files.
Or look at the destination files, find the dlist files, and convert from UTC to local times.
If you genuinely have only one version with only damaged data, that raises the difficulty.

Is it a special characters problem (needing shell protection) or a passphrase problem?

In the webui for the job, you can Export As Command-line to get a quoted remote URL.

For example mega://folder?auth-username=username&auth-password=password.

Mega.nz also talks about these. Also note the name. It is not called auth-passphrase.

Do you have extra space on local drive? Do you have any other MEGA download tool?
I’m wondering if you should grab a local copy before you have an accident with MEGA.