Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] image or attechment files storage at outside #2210

Closed
leeyaunlong opened this issue Oct 9, 2021 · 9 comments
Closed

[Feature Request] image or attechment files storage at outside #2210

leeyaunlong opened this issue Oct 9, 2021 · 9 comments

Comments

@leeyaunlong
Copy link

I saved over 2000 web pages with trilium web clip tool at last year. But trilium db size over 1GB.
I think the db size will over 3GB at the next year.

I checked pages, they are include many images.
The most images just for web page style, they are unuseful for real content. And the unuseful images over 50% db space.

If the trilium has a way save the webpage attechment files(image, etc.) to local folder. The trilium db will keep the size.
Then we can use some sync tool to sync the attechements to other devices.

@sigaloid
Copy link
Sponsor Contributor

sigaloid commented Oct 9, 2021

If you want to make the images smaller, try changing the JPEG quality in settings:
image
(Don't think this applies retroactively, though)

@leeyaunlong
Copy link
Author

If you want to make the images smaller, try changing the JPEG quality in settings: image (Don't think this applies retroactively, though)

I know set the image compression to shrink the image size.

The point is one page include many unuseful images.

for a case :

In the disscus page, many reply message will include user's avator, emoji icon or other signature image.
I just want to save the important main disscus content.
Don't save the user relation misc images.

I knew , some chrome plugins can format or remove some images.
But we need focus read and save , not focus on format page, remove garbage.

If the trilium save the webpage relation images files in local storage , we need not care trilum db size.

PS. when the trilum db size over 1GB, I found the startup trilium need over 1-2 mins.
I also try to remove all images in same db, the trilimu startup just 5 sec.

@abitofevrything
Copy link
Contributor

Trilium has no way to know which images are essential to the web page, so you would need to do this manually anyways.

@zadam
Copy link
Owner

zadam commented Oct 10, 2021

Hi,

PS. when the trilum db size over 1GB, I found the startup trilium need over 1-2 mins.
I also try to remove all images in same db, the trilimu startup just 5 sec.

This seems to be the main problem, it shouldn't be anywhere as slow. Could you provide anonymized database and logs so that I could debug this issue? You can send them to zadam.apps@gmail.com

@leeyaunlong
Copy link
Author

Hi,
It seems cause by auto backup : backup-daily.db.

zadam added a commit that referenced this issue Oct 11, 2021
@zadam
Copy link
Owner

zadam commented Oct 11, 2021

Hi, that makes sense - (daily) backup will need to copy the whole database. I added the option to disable backups which should help in this case.

@leeyaunlong
Copy link
Author

Hi, that makes sense - (daily) backup will need to copy the whole database. I added the option to disable backups which should help in this case.

Can you add the backup option at 0.47.x?
The 0.48b1 is not stable , we daliy note still use 0.47.8.

@zadam
Copy link
Owner

zadam commented Oct 19, 2021

@leeyaunlong do you have some issues with 0.48.1-beta or is it just the "beta" label?

So far there haven't been serious bug reports so I plan to release a stable 0.48 soon.

@meichthys
Copy link
Collaborator

Trilium has entered maintenance mode. Future enhancements will be addressed in TrilumNext: TriliumNext#136

@meichthys meichthys closed this as not planned Won't fix, can't repro, duplicate, stale May 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants