Images randomly disappear

I had a Kegberry working a couple of years ago but never put it into production. I’m finally getting an opportunity to go live and had to rebuild my raspberry pi. I’m new to docker so it took me a bit to get it working.

I’ve got it all working, rfid,flow sensors and relay switches. My problem is my tap images disappear randomly from the adroid tablet. Can’t figure out why but navigating around the picture eventually reappear. In my old set up there was a config file where you specify KEGBOT_BASE_URL and fixed it then. I can’t find that config file. Any ideas?

Poking around the admin portal and my images are broken there too. I assume there is no config file and Ineed to edit the ENV variables in docker, I’m new to dockers, is KEGBOT_BASE_URL still a setting in this new build?

Btw still running old android app, my tablet is a bit old.

Thanks
Rich

Rich,

Welcome to the forum.

Are you referring to the image of the beer? And if so, is it coming up as just one of the the default keg images like this:

If that is the case, I think there is a minor bug which should be fixed soon.

Thanks for response. I see the problem with uploaded pictures I.e. beer labels and photos taken. It seems to happen on android app. My home screen which shows the two taps sometime looses beer label image.

When it happened on raspberry pi it showed up as a broken image.

I’ll keep monitoring.

I had this issue too, rebuild fixed it and I haven’t had the issue since.

I’m having the same issue with a new installation. From what I can tell, you can still set the base url in your docker-compose file.

Like this:
services:
kegbot:
image: kegbot/server:latest
restart: always
ports:
- ‘8000:8000’
volumes:
- /home/pi/kegberry/data:/kegbot-data
tmpfs:
- /tmp
- /var/tmp
environment:
KEGBOT_REDIS_URL: ‘redis://redis:6379/0’
KEGBOT_DATABASE_URL: ‘mysql://kegbot_dev:[email protected]/kegbot_dev’
KEGBOT_SETUP_ENABLED: ‘true’
etc…
etc.
etc.
KEGBOT_BASE_URL: 'http://192.168.2.105:8000/'

However, even after doing this, the images do randomly drop out. This can be ‘solved’ for me by just continuing to refresh the page, and eventually they work, however not consistently.

If there are debug logs I could send that would help pinpoint the problem, please let me know and I can look. I’m brand new to the system so I’m still figuring out how everything is supposed to work. Very cool software, thank you to the devs who write & maintain it!

This may help in debugging where in the code something needs to change. I’ve noticed that when the images fail to load, this is the image URL that is attempting to be loaded:

http://kegbot:8000/media/CACHE/randomdirectoryname/randomfilename.jpg

The issue is that for this part of the code, it’s not obeying the base_URL in the docker-compose file. Or perhaps I need to add another configuration parameter elsewhere. Help appreciated if anyone knows where this can be edited.

Edit… the below suggestion didn’t work either… going to need help from the devs or someone who understands the code better to see where the settings need to be changed to make sure the BASE_URL is applied consistently.

Hi @Richpuch - I think I figured out the problem. Try adding a local configuration file here:

*~/kegberry/data *

nano kegbot.cfg

[config]
*KEGBOT_BASE_URL = http://YOUR_URL:YOUR_PORT *

The example in my case is:

[config]
KEGBOT_BASE_URL = http://192.168.2.105:8001/

Since I’ve done that, (so far at least), the random failure load seems to be fixed.

Ok… I think I have fixed this for real this time. In addition to setting the base URL as I had above, you also have to change the default for the API in the docker compose file. It’s been working consistently for the last day since I added this.

  KEGBOT_API_URL: 'http://YOUR_URL:YOUR_PORT:8000/api/'

The original is:
KEGBOT_API_URL: ‘http://kegbot:8000/api/

Thanks for responding and sorry for the long delay. I had to put things on hold. I tried your recommendations.

Did you stick it inside the docker?

I created a file in:
/kegbot-data/kegbot.cfg

It looked like this:
[config]
KEGBOT_BASE_URL=http://192.168.2.191:8001/

KEGBOT_API_URL=‘http://192.168.2.191:8000/api/

I rebooted the raspberry pi, and went back into the docker and used the set cmmand, but not variables set:
KEGBOT_DATABASE_URL=mysql://kegbot_dev:[email protected]/kegbot_dev
KEGBOT_DATA_DIR=/kegbot-data
KEGBOT_DEBUG=true
KEGBOT_ENV=debug
KEGBOT_INSECURE_SHARED_API_KEY=uVkQz7Deuu0VfNVo0vER8csQZ0wFxVYx
KEGBOT_IN_DOCKER=True
KEGBOT_REDIS_URL=redis://redis:6379/0
KEGBOT_SECRET_KEY=NCZ3iEZqSzzeRdbSHopPX4wdUvXv4xlV
KEGBOT_SETUP_ENABLED=true

I manually set them from command line but still no difference.

I’ll play around to see if I can get it to work? Are your ports set up right, you have 8001 in one line and my system isn’t even listening on that port.

Thanks
Rich

From what I can tell, the cfg file is not used in the Docker version so I don’t think that’s the solution. Re: the 8001 vs. 8000 port, apologies for that mistake. I changed my port to listen on 8001 which is why there is that one difference in 8000 vs. 8001 but I should have explained that above.

The solution for me was to edit this line into the docker-compose.yml file in the root kegberry directory. In that file, you’ll see a section of the code for pycore, and you need to update the KEGBOT_API_URL line to look like this.

  KEGBOT_API_URL: 'http://YOURURL:YOURPORT/api/'

So just move that line from where you have it in the cfg file now and put it in the docker-compose pile and you should be good.

Thanks again. I tried to edit my /root/kegberry/docker-compose.yml and had no luck after a reboot.

I did go into the docker
docker exec -it kegberry_pycore_1 /bin/bash

and edited the
/app/kegbot/pycore/kegbot_app.py
changing
FLAGS.SetDefault(‘api_url’, os.environ.get(‘KEGBOT_API_URL’, ‘http://localhost:8000/api/’))
to
FLAGS.SetDefault(‘api_url’, os.environ.get(‘KEGBOT_API_URL’, ‘http://192.168.2.191:8000/api/’))

This seems to work.

Probably not the cleaned way, but still learning docker. Does the docker-compose.yml get called everything the docker is boots?

Yes, my understanding is that it does. Your manual changes may not persist through a reboot, and definitely won’t persist if there is a new docker image to download in the future that will replace the default you’ve manually edited. (the latter may not be an issue as I don’t think there is much activity on the code there)

Can you post your docker-compose.yml file and I’ll take a quick look and compare to mine?

Here is my file:

/root/kegberry/docker-compose.yml

version: '3.0'

services:
  kegbot:
    image: kegbot/server:latest
    restart: always
    ports:
      - '8000:8000'
    volumes:
      - /root/kegberry/data:/kegbot-data
    tmpfs:
      - /tmp
      - /var/tmp
    environment:
      KEGBOT_REDIS_URL: 'redis://redis:6379/0'
      KEGBOT_DATABASE_URL: 'mysql://kegbot_dev:[email protected]/kegbot_dev'
      KEGBOT_SETUP_ENABLED: 'true'
      KEGBOT_DEBUG: 'false'
      KEGBOT_SECRET_KEY: 'NCZ3iEZqSzzeRdbSHopPX4wdUvXv4xlV'
      KEGBOT_INSECURE_SHARED_API_KEY: 'uVkQz7Deuu0VfNVo0vER8csQZ0wFxVYx'
      KEGBOT_ENV: 'production'

  workers:
    image: kegbot/server:latest
    restart: always
    command: bin/kegbot run_workers
    volumes:
      - /root/kegberry/data:/kegbot-data
    tmpfs:
      - /tmp
      - /var/tmp
    environment:
      KEGBOT_REDIS_URL: redis://redis:6379/0
      KEGBOT_DATABASE_URL: mysql://kegbot_dev:[email protected]/kegbot_dev
      KEGBOT_SETUP_ENABLED: 'true'
      KEGBOT_DEBUG: 'false'
      KEGBOT_SECRET_KEY: 'NCZ3iEZqSzzeRdbSHopPX4wdUvXv4xlV'
      KEGBOT_ENV: 'production'

  mysql:
    image: kegbot/mariadb:latest
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: 'changeme'
      MYSQL_USER: 'kegbot_dev'
      MYSQL_PASSWORD: 'changeme'
      MYSQL_DATABASE: 'kegbot_dev'
    tmpfs:
      - /tmp
      - /var/tmp
    volumes:
      - /root/kegberry/mysql:/var/lib/mysql

  redis:
    image: redis:latest
    restart: always

  pycore:
    image: kegbot/pycore:latest
    restart: always
    tmpfs:
      - /tmp
      - /var/tmp
    environment:
      KEGBOT_REDIS_URL: redis://redis:6379/0
      KEGBOT_API_KEY: 'uVkQz7Deuu0VfNVo0vER8csQZ0wFxVYx'
      KEGBOT_API_URL: 'http://192.168.2.191:8000/api/'

  kegboard:
    image: kegbot/pycore:latest
    restart: always
    command: bin/kegboard_daemon.py --kegboard_device=/dev/ttyACM0
    tmpfs:
      - /tmp
      - /var/tmp
    environment:
      KEGBOT_REDIS_URL: redis://redis:6379/0
    devices:
      - /dev/ttyACM0:/dev/ttyACM0
      - /dev/bus/usb:/dev/bus/usb

volumes:
  mysql-data:
  kegbot-data:

Thanks, after looking more carefully at my own docker-compose.yml file, I found that I entered this line everywhere until eventually it worked. Not exactly scientific, but one of these entires did the trick:

  KEGBOT_BASE_URL: 'http://YOURURL:YOURPORT/' 

Example:

  KEGBOT_BASE_URL: 'http://192.168.2.191:8000/'

I have the line repeated in these sections. I’m positive it’s not necessary in all of these areas, but as I look back, I now remember getting frustrated and putting it in everywhere until it eventually ‘stuck.’

  • Workers / environment
  • mysql / environment
  • pycore / environment
  • kegboard / environment

Thanks. Sorry for long delay. I thought its been working but still same issue. The randomly don’t show up and sometimes a refresh doesn’t help. Has yours been running fine?

Yep, mine has been working fine for quite some time. Might be worth starting fresh and hand-typing the entries in to make sure you don’t have a typo somewhere (happened to me earlier at least).

Hey @Richpuch, I stumbled across another issue that breaks images while redeploying kegbot today. If you set up your docker-compose to include:

 KEGBOT_ENV: 'production'  #instead of debug

I’ve found that this will change DEBUG mode to FALSE and 100% break the custom images that you upload. It is [mentioned in this thread] (Kegbot server issues when DEBUG = False) as well (with no way to fix it, but if you leave it as KEGBOT_ENV=‘debug’, it doesn’t mess with the images loading. Since you said yours sometime work, this may not be the issue, but I thought I’d post what I found in case others have this problem in the future.