CorneliousJD

Indeed, sadly it's still one of the best self-hosted recipe management solutiolns even with this fact and its quicks that come with it. I lack the time AND the know-how to properly update any of it, but as it stands now for my own private use with the dockerfile you've provided, it works very well at this point. I am certainly open to suggestions for other recipe management software that's self-hosted though if someone finds something worthwhile.

In an effort to get some of the bugs fixed (by running latest version) I've adopted for now to use @BrambleGB's Dockerfile fork. Change your repository FROM maduvef/openeats TO bramblegb/openeats And save the container, this should pull the latest version and fix a few bugs that exist in the older version. I'm working on forking the Dockerfile to see if I can address a few other things but time is VERY lacking for me at the moment, work and personal life keep me very busy, so for now BrambleGB's file will work and pull you the latest version. Thank you very much BrambleGB for providing this to the community as well!

Awesome, rgr that! I'll probably stick with the LSIO one for now, but always good to have options. I settled on TheLounge too after my research. Thanks!

Any difference/reason to use this container for TheLounge vs the LinuxServer.io one? If so, would pointing at my existing appdata work fine?

I had the same issue this morning, I actually just removed the container and re-added it and it's working again now. For what it's wroth, very much *not* a fan of the animated gif logo in my docker page either. If anyone else is not either, I changed FROM: https://raw.githubusercontent.com/Organizr/docker-organizr/master/logo.gif TO: https://raw.githubusercontent.com/causefx/Organizr/v2-master/plugins/images/organizr/logo-no-border.png

Automatically? No, not unless the Stash devs add it to the docker themselves, but manually, sure! So /mnt/user/appdata/stash/scrapers -- just follow the instructions on the CommunityScrapers page to download the files and put them in the correct place and you should be able to use them no problem.

Thanks for sharing. I will probably continue to run this with it's final update. I can still access locally at least and via my own remote access. Will you just tag it as unsupported and let people still install from CA?

I'm pretty new to docker containers in general already - i'm not sure why it pulls an old version either, but what would i need to add to the dockerfile and startup scsrips to accomplish this? Right now this is an openeats developer's dockerfile - i may be able to get him to update it so I don't have to fork.

You can't use "localhost" as the SQL host from what I recall, because that only looks inside the container. You need the IP of the host or your unraid box

I have mine setup using another user, make sure whatever user you setup has full permissions over that database in question. Also see my previous reply, your select statement showed "openeats" as the user, NOT "admin" like your variable states, so that may have something to do with it, it doesn't seem to be actually writing your intended superuser user/pass. If the select satement shows username of "openeats" again I'd try logging in with that for both user AND password. If that doesn't work try "openeats" as the username with the password you actually specified. If that doesn't work, I'd try again setting "openeats" as both the superuser username and password when setting up the container. PS, just worth mentioning, make sure you aren't yet trying to hit this from a publicly accessible URL, try from the IP:port you have it configured on to rule out any reverseproxy issues.

Your username here shows "openeats" -- try login in with user and pass of openeats maybe? It doesn't appear to have listened to your "admin" username you specified in the screenshot, the default it will make is openeats//openeats. Give that a go.

Your variables all look fine to me. If you drill down into your database anto the "auth_user" table do you see your admin user you selected in the container? If you do not see it there, then you may want to try blowing away the database itself and the appdata folder for OpenEats and force an update on the container (this will re-pull it fresh) and fire it up again, and create the database with the user. EDIT - This is what mine looks like - I'm the only user listed, and this username was my supseruser user/pass I put into the container as a variable.

Hey guys, I've been completely re-evaluating my backup strategy lately, and I'm replicating essentail appdata and assocated backups to the cloud via Duplicati, but I want to do local backups as well. My thought process was to store them on an unassigned disk, because in the event of a total system or hardware failure I could pop that one drive out and plug it into another machine and spin up a Duplicati instance and read the data from it without any real issues? But then on-array has the benefits of the data still existing in parity of the drive dies, but if unRAID itself somehow blows up then I'd lose it all the local backup data and have to pull from the cloud storage which as fees for downloading. Let me know what you guys think the best move here is. Thanks in advance!

That would be something you'd need to check in with the OpenEats developers themselves on to see if it's soemthing that can easily be modified somewhere. I don't have a way to set that though from the container side personally, sorry! That's odd, I never tried another langauge before because I don't know any, but the NODE_LOCALE variable was taken directly from here: https://openeats.readthedocs.io/en/feature-doc-update/Setting_up_env_file/ (see the very bottom) Also the Dockerfile that this is built from also includes the NODE_LOCALE variable so it should be working. Does any other language work when you try to change it to anything other than English? Or does it always show as English?

Some IRC networks wont let you connect with VPNs - I'm not speaking for LSIO here but it seems unlikely that this would happen directly

Soundsl like you want ZNC or Quassel-Core for this.

The scraper should be functional, you'll likely want to take this up with the devs on their GitHub here: https://github.com/stashapp/stash Or you can try upgrading to the beta release to see if it's been fixed/improved there, as that's where actual development is happening. You can edit the container to pull stashapp/stash:development-x86_64 But note that if you upgrade, you can't easily downgrade because it changes the database. You'd need to stick with the beta/dev build until they update the main release to be based off that new updated database.

Thanks! Do you happen to know why the other one wasn't actually pulling from an updated master file? I can't seem to figure that out. I'd like to fork just the dockerfile if I can and not have to maintain a separate OpenEats repo itself. Thanks. Although I do not believe the serving size changes will be able to parse that character and change it accordingly? If it does great, otherwise you would still need to stick with 1/2 anyways.

Interesting, I guess I'm not sure why it would be pulling such an old build when it's supposed to pull from master. Mind sharing your dockerhub repo? I can change my pull to that and if it works successfully I can just update the template in CA to pull from yours instead

I am not the dev, see first post that describes this request already The dev has already touched on working on that but it's still not working correctly at this time. I would just recommend biting the bullet and firing up a MariaDB container, it's not too tough to do.

Is your ALLOWED_HOST variable set to *? If not set it back to * and try again, also see known issues about linked recipies as well, it is known to hang currently when trying to link a recipe. 1/2 is supported just fine but ½ (the actual symbol) is not. e.g. the following are fine 0.5 cup water 1/2 cup water the following is NOT ½ cup water The last one will not work becuase it cannot proccess that as a proper quantity.

Not really, I assumed there was some new containers using up more in the image, I'm not sure what's new, but when containers update (if you ahve it scheduled then) it may be why it's filling up more around those times. I just stopped docker, added 5GB to my img file and I haven't had a warning since!

I actually use the same container, but like @jonathanm said, you could also spin up a second MariaDB instance with a different name and different appdata. I personally just use the same container, I find using a program called HeidiSQL on Windows makes it easy to connect to my MariaDB instance and add/drop databases and tables, and add users if needed too, or Adminer (which is it's own docker container in CA) can be used to do the same as well, it gives you a nice GUI to work with instead of command line for managing the databases. If you're comfortable with a little tinkering and learning along the way, you can use the same MariaDB you use for Nextcloud, otherwise just install the same container again and called it mariadb-openeats and give it an appdata with the same name and you'd be off to the races in no time!

I keep running into an issue while trying to test this container too... I just setup a fresh install of it and a fresh B2 bucket, but now I'm seeing that purges from B2 are failing as "File not present". I saw this last week too and CloudBerry support isn't being much help here honestly, I'm not sure what's going on. I just want to backup my entire /appdata/ folder at midnight every night. CrashPlan is currently doing this and is not complaining (I'm also not ever purging anything either), but I'm really trying to get away from CrashPlan and thought CloudBerry would be leaps and bounds better, but I'm not sure what's going on now, this hasn't even been up and running for a few hours yet and purges are failing?

Alright, I'm still going through some hoops getting this setup properly to give me a minimal B2 usage and also be efficient enough to give me what I need. I have it setup like this currently, and I think it's right, the goal here is to Backup CA Appdata backup files (generated weekly) and keep them for 30 days. Backup direct appdata/nextcloud/some other files as well. Only keep X days of versions. Keep latest 3 versions at minimum (even if older than X days) If anything is explictly deleted or unchecked from backup jobs, delete them from B2 after 30 days. Does this look correct to you guys? If there's a better retention that you think I should be using please let me know. I'm currently debating keeping 7 days, 14 days, or 30 days of versions.