I added this container to reboot birdmakeup every hour, which appears to be an ok workaround, but I don't know what is causing this issue with the main application.

  restarter:
    image: docker:cli
    restart: unless-stopped
    networks:
      - socket-proxy
    depends_on:
      - socket-proxy
    entrypoint: ["/bin/sh","-c"]
    command:
      - |
        while true; do
          sleep 3600; docker restart birdmakeup;
        done
    environment:
      TZ: $TZ
      PUID: $PUID
      PGID: $PGID
      DOCKER_HOST: tcp://socket-proxy:2375

Is anyone else running into this issue? I need to restart my container in order for new tweets to get fetched, and pretty quickly they just begin returning "0 tweets from user X", even when there are new tweets. I'm planning on adding another docker container to reboot the image every two hours, but wanted to see if anyone else is running into this problem.

One note that the version on github uses database version 3.1 not 3.2 as the sr.ht version does. To get the github version working you only need to edit the entry in the db_version table to be 3, 1 instead of 3, 2, and then drop the "extradata" columns from the twitterusers and instagramusers tables.

bird.makeup is pulling some content from nitter instances, and it looks like some of those nitter instances are inserting content into tweets. See comment from the bird.makeup developer here: https://r.town/@vincent/111307622842372614

~retiolus the version hosted here on sr.ht hasn't worked for me for awhile, I've been using the version hosted on github here: https://github.com/rursache/bird.makeup which has some modifications and is slower to roll out changes, but seemingly is more stable. Thanks to ~rursache for working on this

~peanutlasko as far as I know the only way is to follow each account from your mastodon instance, as both BMU and your mastodon account have to recognize and register the follow

~peanutlasko gotcha, glad it sounds like it's working as intended now - clearly the setup issue raised wasn't addressed by ~cloutier for new installs, so unfortunately the manual insert of data is needed, and the table structures have changed since I put together the sample values a couple of months ago

~peanutlasko weird I was able to look up the account I seeded in the DB using the bmu interface without that error - but frankly there isn't much value in using the interface. You can just look up users in the mastodon UI and follow them from there, so long as that's working you should be in good shape.

~peanutlasko Ok I was able to re-create the issues you're seeing on a fresh install, and got everything working. The problem is resolved by populating the data below in the two tables (followers, twitter_users).

May be worth doing a fresh install rather than trying to resolve your current setup, so stop and remove the container, delete the database and birdmakeup user from postgres using pgadmin.

After you've stopped and remove the bmu container, and removed the db/user from postgres, do the following:

1. Create BMU user in postgres
2. Give superuser privileges
3. Create the birdmakeup database, and set it to be owned by your birdmakeup user

Start up the container, you should get a working UI at your birdmakeup domain

In pgadmin, paste the following values into the two relevant tables:

followers:

id	followings	acct	host	inboxroute	sharedinboxroute	actorid	postingerrorcount
1	{1}	peanutlasko	mas.to	/users/peanutlasko/inbox	/inbox	https://mas.to/users/peanutlasko	0

twitter_users - NOTE that the lastsync timestamp has spaces in it (2023-07-21 14:54:07.16) and the following 0 is for the fetchingerrorcount. Leave fediverseaccount NULL

id	acct	lasttweetpostedid	lastsync	fetchingerrorcount	twitteruserid	fediverseaccount
1	npr	1646138106595139584	2023-07-21 14:54:07.16	0	5392522

Then restart the bmu container and it should be working

~peanutlasko yes fully feel the frustration, it seems like the setup may be broken. I'm going to try setting up a fresh install and see if I can re-create what you're seeing, and hopefully solve.