Does the plugin work with Beets versions >2?

[maelstrm-code]

Thank you so much for making this - just got it working in Unraid and so far it's great! Really appreciate your efforts!

I was wondering whether the plugin is compatible with the latest version of Beets, ie whether removing the pin to v2 will work - as it's nice to avoid having old versions of things in case of bugs & vulnerabilities. Understand if that's not feasible given maintenance overhead!

Also a few observations on the install journey in case they're helpful:

Yes you can get it working in Unraid's docker, using "Docker Compose Manager"
The config file and script goes in
/boot/config/plugins/compose.manager/projects/beets-audible

Documentation gives the following command to use the app:
beet import /path/to/audiobooks
I found I needed to run
beet import /input
to align with the config

And oddly it uses 3-6% CPU when idle, so probably not something to leave running continually.

[Neurrone]

Thanks for the feedback.

I was wondering whether the plugin is compatible with the latest version of Beets, ie whether removing the pin to v2 will work - as it's nice to avoid having old versions of things in case of bugs & vulnerabilities. Understand if that's not feasible given maintenance overhead!

I actually realized that I pinned it accidentally and fixed it recently. It should now work with any 2.x version of Beets.

And oddly it uses 3-6% CPU when idle, so probably not something to leave running continually.

I haven't noticed that myself, that's pretty strange. I do have this on a pretty powerful CPU though, a Ryzen 5700G.

[maelstrm-code]

Appreciate the super speedy response :)

The docker-compose spec in the readme has 2.0.0 pinned which is what I had used. I've now manually updated mine to :latest (can't figure out if there's a way to pin to the v2 family as there doesn't seem to be a tag for it), and it seems to be working.

Ignore the following - it was user error! I had missed the userid & groupid set in the docker compose file... D'oh, sorry for the hassle. For future readers, if you have this error check those against the permissions your DB has.

---

_Regarding the CPU usage, I suspect it's something to do with something in the container struggling with database access as when I tail the log in the container I see the following repeated endlessly. I'll do some more checking to see if it's user error, and if nothing obvious pops up I'll move it to a bug report
error: database file /config/library.db cannot not be opened: unable to open database file

Which is odd, since I've checked that the library.db file is in /config/ (from the container's perspective), that it has permissions to it, and I can use the beets command successfully (and when I do it remembers files it has processed).

 root@ab00017ced0c:/# id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video)

root@ab00017ced0c:/# ls -la /config
total 2052
drwx------ 3 root root    4096 Dec 29 10:51 .
drwxr-xr-x 1 root root     330 Dec 29 10:44 ..
-rw------- 1 root root     466 Dec 28 22:32 .ash_history
-rw------- 1 root root     359 Dec 29 10:45 .bash_history
drwx------ 3 root root    4096 Dec 28 17:13 .cache
-rw------- 1 root root     674 Dec 28 17:01 beets.sh
-rw------- 1 root root    2510 Dec 28 17:12 config.yaml
-rw------- 1 root root 2068480 Dec 29 10:51 library.db
-rw------- 1 root root    1095 Dec 28 17:01 original_beets_config.yaml_bak
-rw------- 1 root root     180 Dec 29 10:51 state.pickle

As a check I've installed sqlite3 inside the image in case there was a missing dependency, but no change. I've also used sqlite3 to validate the DB and it doesn't seem to be corrupt:
root@ab00017ced0c:/# sqlite3 /config/library.db "PRAGMA integrity_check;" ok_

---