AudiobookShelf Integration

[redwiz666]

Summary

Added AudiobookShelf Connection in settings.

This gives us the option to scan after importing a new book or when a download completes.

Once ABS libraries are loaded you can like them to root folders

This allows for different paths in ABS and Listenarr. This is mainly used for the import options.
Had to modify the Library Import dropdown to keep RootFolders and ABS Libraries seperate

When importing from ABS it doesn't move the files it just Adds the books from their current location, will convert the path to once accessible to Listenarr if its mapped to a RootFolder. Once ABS books are imported they will show up in your Listenarr library.

Testing

Tested importing over 500 books from ABS version 2.33.1. The only issue I have found during my testing is that when a book in ABS doesn't have its metadata filled out (mainly ASIN) then it will import as missing. Since Listenarr requires ASIN or ISBN to use the scan feature. If later this gets updated to be able to scan using something else then it should work fine. I didn't want to rewrite your scan function just to make this work 100%. The scan feature would need to be adjusted similar to when/If you allow for manual import later on.

[T4g1]

I dont understand the way this integration works. Why should Listenarr manage a third-party settings ? If I understand correctly, the goal of your PR is to import books managed by audiobookshelf in specific folders rather than the configured root folder(s) ?

The way I see it is that Listenarr should import media and metadata in the configured folders and it's the responsibility of third-party to scan those just like Jellyfin/Plex with Radarr/Sonarr/Lidarr.

Eventually, shouldn't Listenarr simply do API calls to Audiobookshelf on imports to trigger scan on it's side ? More like a plugin would do it

Also, I believe this PR closes #233 and update the roadmap but if find both of those lacking in terms of feature description/discussion

[redwiz666]

Maybe I didn't explain it well. It still does it within the root folder but I added a way for it to translate audiobookshelf path to listenarr path. This is similar to how sonarr/radarr does it for download clients. For example if in audiobookshelf your books are saved in /audiobooks but in listenarr the root folder is /nas/audiobooks. When importing it will convert the audobookshel path to the rootfolder before adding the book to the database

[T4g1]

Isn't what you describe there the feature requested here: #494 ? How does it relate to Audiobookshelf at all ?

Wouldn't this behavior solve the issue you have:

• Allow import of arbitrary folder
• Monitor added audio books to current path (maybe create a specific root path for those)
• Trigger events on import succeeded, download completed, and/or other events
• Write a plugin that interface those events to Audiobookshelf

This way, the code can stay agnostic of third-party, here it's really adding a lot of Audiobookshelf specificity into the backend, I know it's already what the code does for a lot of thing but low coupling is probably the direction we should follow

For context, im trying to understand what problem the PR solves so I can do a review of it, worst case you'll have to wait for Robbie's return

[redwiz666]

The path translation is only part of the problem. The main part is adding in the integration to audiobookshelf to allow importing the books directly with metadata and also notifying audiobookshelf of new books and to scan the new book. Since a lot of people probably will use listenarr to download the books but audiobookshelf to listen to them.

[T4g1]

I understand but I do not think it is required to have any Audiobookshelf knowledge in Listenarr to do that. We can do exactly the same thing that Jellyfin does with Sonarr/Radarr/... with the features i describe in my comment. Don't you agree ?

To integrate with audiobook shelf, you would have to first support #494 so we can import library without impacting the files themselves:

• Add a root folder specific for Audiobookshelf (or only one that already contains the library)
• Scan and import audiobooks

Now, there should be all your audiobooks from Audiobookshelf in the Listenarr library.

And then, all you need is a plugin system with an event queue with subscriber/publisher to trigger API calls to Audiobookshelf so it can import new files/refresh library on some given events (that feature is not in issue form but I saw it somewhere on the roadmap)

[lzinga]

I agree with @T4g1 here. There's an unneeded level of dependency on Audiobookshelf implemented throughout the core pipeline. Listenarr should stay media-player-agnostic, the same way Sonarr/Radarr don't have Jellyfin or Plex code in their download processor. A post-import event/notification system would serve ABS, Plex, Jellyfin, and any future integration without coupling them into the codebase.

Also worth noting there are no tests added for the 5,600+ lines of new code, and the existing test suite would fail to compile due to the new IAudiobookshelfService constructor parameter added to CompletedDownloadProcessor. There are at least 6 call sites in CompletedDownloadProcessorTests.cs that would need updating.

I'd recommend closing this and revisiting after a generic notification/event system is in place that ABS (and others) can hook into.

[therobbiedavis]

Hey there @redwiz666, first off thanks for taking to the time to contribute!

From my understanding of this PR it seems like this is pretty complex and solves for specifically one program without taking a more macro-view of the roadmap. I would like to build a foundation for multiple integrations like Audiobookshelf, Plex, Jellyfin, Emby, ReadMeABook, or any other audiobook consumer program that comes out in the future.

With that vision, I don't see a need for an ABS integration to add an ABS root folder. We should first solve #494, then let the user add their ABS root folder independently for the library import. This would decouple ABS from Listenarr. Then we should build out the post-import event integrations for ABS and others, where Listenarr just sends to those applications. This would make Listenarr more flexible while solving what you're accomplishing. The idea being that it would be one way communication: Listenarr -> ABS/Plex/etc. Those applications do not need to send any info back to Listenarr.

If you would mind kindly refactoring more towards that direction, I'll happily take a deeper review of your PR. Please also make sure to add relevant unit tests.

Thank you!