oxtyped
Makes episode sync work
I've tested this with Antennapod, and episode sync is working perfectly.
This merges #18 and completes that work. Thanks @TheBlusky !
fixes #39
I couldn't figure out how to run the tests. They seem to require a pre-existing database, but I'm not sure what's expected there, and I didn't see anything in the repo that would generate it. I did manually test this with antennapod, but I don't know if the automated tests would pass after these changes.
If anyone else wants to try this in the meantime, you can use container image quay.io/mhrivnak/gpodder2go-container:mhrivnak-fork
Just take note that I made a new `Containerfile' which has the process running as non-root (user 1001), so be mindful of permissions when mounting storage there.
Update: I forgot to mention that I also put the binary in /usr/bin/ instead of just dropping in at /. So when you run commands to create an account for example, you can just name the command like any other without a / prefix. For example:
podman exec -it $CONTAINER_NAME gpodder2go accounts create ...
so when I would like to try it I have to change the image to quay.io/mhrivnak/gpodder2go-container:mhrivnak-fork or additional things are needed?
Here's what I did to run it locally on Fedora and use a directory on my system to store the data:
mkdir data
chmod g+w data
podman run -d --name gpodder2go -p 3005:3005 -v ./data/:/data:Z quay.io/mhrivnak/gpodder2go-container:mhrivnak-fork
If you're still using docker, the same arguments should work. And you might not need the :Z if you're running on a system without selinux.
When I use the following docker compose file in Portainer and start with an empty gpodder2go-folder I got the following error message:
services: gpodder2go: image: quay.io/mhrivnak/gpodder2go-container:mhrivnak-fork container_name: gpodder2go ports: - 3005:3005 environment: - NO_AUTH=false - VERIFIER_SECRET_KEY="" volumes: - /volume1/docker/gpodder2go:/data restart: unless-stopped
No database found, intializing gpodder2go ... 2024/12/14 16:39:03 unable to open database file: out of memory (14)
Yeah, that error message is misleading, and it's a bug in the sqlite3 driver. The problem is just that the process can't write to the /data/ directory.
The process running in the container will run as UID 1001, instead of running as root. That's a good thing. We just need to make sure that user 1001 can write to the data directory. Sorry, I haven't used docker in many years, so I can't test with it. One of the main reasons to use podman is that it makes it easier to run things as non-root.
Can you run sudo chmod g+w /volume1/docker/gpodder2go on the host system and see if that fixes it? The user inside the container should still have its group set to 0 aka root, so giving write permissions to the root group should work.
Thanks for the explanation. I fixed it via giving read+write access to everyone in the Synoloy DSM GUI for this folder.
Via the command in SSH it did not work via sudo chmod g+w /volume1/docker/gpodder2go
Then I tried to add a user via:
docker exec -it DOCKER-ID /gpodder2go accounts create Felix -e [email protected] -n Felix -p PASSWORT
But I got this error:
OCI runtime exec failed: exec failed: unable to start container process: exec: "accounts": executable file not found in $PATH: unknown
Ah yes, sorry, I forgot to mention one other change! I put the binary in the standard location for binaries instead of at /.
Just remove the / in front of gpodder2go in your command.
docker exec -it DOCKER-ID gpodder2go accounts create ...
After synchronisation I recognised that the sync is failed in AntennaPod.
Then I checked the logs in Portainer I found this line:
missing cookie, have you logged in yet: &errors.errorString{s:"http: named cookie not present"}
I have attached my podcast subscriptions and also the log from portainer. antennapod-feeds-2024-12-15.opml.txt gpodder2go_logs.txt
I suggest opening a new issue on this repo for that, as it's likely unrelated to the episode API.
The auth check happens early in the code flow, before any of the API handlers get invoked. Reading the code, I don't see how the no cookie message could happen unless the request truly did not include the required auth cookie. Perhaps it's even a bug in antennapod, that it sent a bad request?
Now I started with a fresh installation of AntennaPod and added my subscriptions and checked it with a second device. It synchronizes now without any problems the subscriptions and also the listened episodes.
