w0ndersp00n

Members
  • Content Count

    19
  • Joined

  • Last visited

About w0ndersp00n

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I never heard of Teedy before... It has a beautiful UI though. But considering it's written in Java, I can't call it lightweight. Every Java app I run uses about 6 times the amount of memory compared to Python apps. Rust or C/C++ would be best, considering most ARM boards don't get more than 4GB's of RAM. I might try it out on an old C2, to get a feeling of how it compares to the other ones.
  2. In general, a lot of things are not documented or are documented as comments within the code and config files. So besides the documentation, you need to read the code and config files to figure out how everything works. This is a small package, but probably not worthwile since it's only helpful for storing text-based documents, which isn't the core. True, but it doesn't fix the fact that the database is locked during operations, making it sometimes annoying to work with Paperless. I'm going to find out if it is possible to use MariaDB or PostgreSQL,
  3. In my case `disable-notify` is needed, because my consume folder is on a NFS-network location. inotify doesn't work on network locations, so new files would never be processed. Because I'm using NFS, rights are not an issue (if you set the UID and GID to the same from the NFS server.) Regarding the date: in the Netherlands we use DMY dates. I noticed that Paperless wouldn't detect any correct date when this was set to YMD. I guess this idea is nice, but I still don't understand how that script would be able to define the correct filename. E.g. my sca
  4. This is the same with Paperless as it is with Mayan. By setting the restart policy in the docker-compose file or in the docker run command. I use “unless-stopped”.
  5. I haven’t tested exporting documents yet. I did notice that when downloading a file, the filename will become ‘Date of the file_Title of document’. Title of document is the original filename, if you didn’t change it. Documentation regarding exporting all files: https://paperless.readthedocs.io/en/latest/utilities.html#the-exporter I’ve been using Paperless for a few moments now and I have to say it really seems to be what I was looking for. On a technical level I’ve seen that the documents are saved with numeric filename (00000010.pdf), while May
  6. So after playing around with Paperless for a few hours and with a few testruns, I have to admit I'm starting to get more positive. The downside still is that documentation is lacking and that development seems slowed down quite a bit. On the plus side, when you know what to do, this tool can work very well for you. Some less positive points: It doesn't support Office-type of files. So no docx, odt, xlsx, etc. This issue isn't too big, since I'm using it mostly for files I received/scanned. And if I receive an Office-type of document, it isn't very hard converting it to PDF.
  7. It’s true that initial setup of Paperless is quite ok. However, as you noticed, you have to use the command line in order to change settings and setup the user. Basically everything to setup happens via the CLI. In my case I also had to disable inotify. This is once again a specific setting which needs to be changed before starting the container, because otherwise it would never detect any of my files in the consume directory. The consumption process on my side is also less reliable than with Mayan. It’s very slow. Where Mayan processes a PDF including OCR with in
  8. I don't know why it failed. But here are the steps I took to get Paperless running next to Mayan on my dev/test Odroid: git clone https://github.com/the-paperless-project/paperless.git cd paperless cp docker-compose.yml.example docker-compose.yml cp docker-compose.env.example docker-compose.env docker-compose up -d I edited docker-compose.env to change variables for Timezone and OCR Languages: TZ=Europe/Amsterdam PAPERLESS_OCR_LANGUAGES=nld deu eng With these steps, Paperless will be build and run on port 8000. This process takes about 15 minutes on my Odroid C2.
  9. No problem! I want it for private use. It’s true wat you say about paperless, that it supports web upload (HTTP POST). The big difference is that you need to create/write/develop the form to upload a document yourself. A lot of functionality lacks out of the box. In Mayan, you simply go to the settings and enable a web form for the upload and it works. So Mayan has a larger footprint, but is also more complete in my opinion. Actually, there is about nothing you can do regarding settings from the Web UI with Paperless, in contrary to Mayan. Maybe I haven’t looked at it l
  10. The changes made are in no way valuable for upstream. The original script simply pulls the AMD64 image from Docker Hub, which is way quicker and easier than building the image during setup. Probably creating a second script to only update the Mayan image and container would be a simpler solution. However, recreating the containers for Postgres and Redis barely takes up measurable time on my C2. So it's not worth the effort. I assume higher end boards, such as N2 and Rock Pi 4 wouldn't even notice this part of the script. The more interesting question would be:
  11. This script doesn't update the system, it only installs docker when the variable is set. But great to know the build also worked for the Rock Pi! Maybe... I could add an additional variable where you can enter the tesseract-ocr languages. But if this script would eventually be called from Softy, the question would never be asked, so a default install is performed. The Mayan containers can be updated independently, but this script was made for easy set-up. So it'll remove all the containers and create them again on every build. The used images for Pos
  12. Yes, I guess updating would be quicker. But I personally wouldn't want to try; if a new version in a container would fail, it's easier to roll back. I also changed the script a little bit. I figured that the version number is stored in the Git repo, so I'm using that in the script. So the current script is able to always build the newest Mayan version and start a container with that version.
  13. No, installing on bare metal wouldn't lower memory usage. Maybe 1 or 2MiB from the Docker overhead, but isn't worth the trouble of installing Mayan. I'd still recommend a container (Docker or podman). Mayan has high system requirements: https://docs.mayan-edms.com/parts/installation.html#minimum-hardware-requirements Considering this it simply doesn't make sense to install it on lower end ARM devices. It should have at least 1GiB of RAM, but that is the bare minimum. 2GiB is recommended, so a Raspberry Pi 3 would be the bare minimum for running Mayan EDMS. But a Pi 4 or Odroid C2 w
  14. Considering the complexity and all the dependencies I doubt it. The buildfile for Mayan EDMS uses Debian Slim and removes a lot of packages during the build in order to keep the resulting image as small as possible. It theoretically would be possible to to switch to Alpine, but considering all dependencies for Mayan I don't think it's worth the trouble. For every new version of Mayan a new image should be build. So that would mean an hour of time from a C2 or RPi3. For anything lower end I wouldn't even consider Mayan EDMS, it's way to heavy. Right now I'm trying to fig
  15. So with a few modifications in the script from Mayan I was able to build the image on my C2. Building on the C2 with Class 10 SD Card takes about 50 minutes, so I assume that a Raspberry Pi 3 might need more than 1 hour. However there are some issues which I haven't figured out, since I usually don't write or edit shell scripts. The default Installation script pulls mayanedms:latest, however during the build a versioned image is created. This means that the variable DOCKER_MAYAN_IMAGE should be updated for every new version. I don't know if there is some automatic way to do t