w0ndersp00n

  • Content Count

    21
  • Joined

  • Last visited

Everything posted by w0ndersp00n

  1. That's strange - it only happens to my new Armbian installs. But I've assigned static IP Addresses for now, to see if that fixes this issue
  2. With my OPi Zero, I noticed that at random times the ethernet connection somehow gets disabled. The only way to recover is by power cycling. I use the device as Pi-Hole (so when ethernet gets disconnected, I don't have internet anymore), print server and UniFi controller. I decided to swap it for my Odroid C2. Odd enough the C2 has the same issue. Maybe someone can help me with this? When powercycled, the Odroid with the latest Armbian (installed two days ago) is all up and running fine. It can connect to the internet, I can SSH into it. The ethernet led is flashing orange, s
  3. 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.
  4. 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,
  5. 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
  6. 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”.
  7. 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
  8. 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.
  9. 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
  10. 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.
  11. 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
  12. 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:
  13. 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
  14. 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.
  15. 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
  16. 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
  17. 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
  18. Building on the N2 takes about 5 to 10 minutes, so it's not that bad. The resulting image is about 1.2 GB in size. I'm not really someone who can write great scripts, but I'll get out my old C2 and try to make a script that builds the image and then starts Docker with it.
  19. Actually, the current Dockerfile is working for aarch64. I've tested it on my N2. The issue is that the GitLab CI right now seems to lack the option to build ARM images, that's why they're not supplied. You have to build on the platform for which the image should be. On my N2 I followed this guide: https://docs.mayan-edms.com/chapters/docker/building.html I only changed the tag in the Makefile, because I didn't know if it would conflict. After building locally, you can start the container. As of now I haven't noticed any issues, but haven't been using it lon
  20. The default Mayan EDMS docker image is only built for AMD-64. It doesn't work on ARM, so this will never work. Someone might write a Dockerfile for armhf and or aarch64, which we can use for this, or Mayan should be installed on bare metal. See: https://gitlab.com/mayan-edms/mayan-edms/issues/422 https://hub.docker.com/r/mayanedms/mayanedms/tags
  21. I've installed Armbian on my brand new Odroid N2. I realise it still is WIP, but almost everything works great. There is just one issue, which prevents me from setting it up the way I want. I use my eMMC card to boot the system. I've also added a larger A1 SD card for application data. However, after a reboot the SD card isn't recognized. There isn't even a message about it in dmesg log. But when, after booting, I remove the SD card and insert it, all of the sudden it's detected and mounted. Does anyone know how I kan make this happen at boot, so I don't need to physica