Branch: fix/strip-contributor-role-suffix (pushed; the two commits are the stack's ab1dd476c and 729550a30, cherry-picked clean onto upstream/canary; verified on origin by git ls-remote). A third commit, 86840ceea, applies the same cleanup on the Rescan metadata path, after a report from @Yoldark34 on this PR, and a fourth, 13f39de16, only swaps test data for catalogue values. No existing upstream issue or PR covers this.
Touches FileNamingService.Helpers.cs and AudibleBookMetadata.cs, also changed by my open #961, #984 and #763; this merges cleanly with each.
Body
Audible has no role field. A translator or an editor arrives as an ordinary author name with the role appended.
Measured on stock ghcr.io/listenarrs/listenarr:canary (Listenarr.Api/1.3.4), in an isolated throwaway container, against two public-domain audiobooks:
GET /api/v1/metadata/audible/B00EZAXAF8("The Brothers Karamazov [Naxos AudioBooks Edition]") returnsauthors: ["Constance Garnett - translator", "Fyodor Dostoevsky"]from the real Audnexus data.POST /api/v1/library/addstored it as received, and because that credit came first it also became the folder name:"basePath":"/app/Constance Garnett - translator/The Brothers Karamazov [Naxos AudioBooks Edition]". So the suffix reaches both the stored author field and file naming, on stock.
Control. B002V9ZF3K ("Crime and Punishment"), a different book, with a single author credit and no translator credit, stored and named clean: "authors":["Fyodor Dostoevsky"], "basePath":"/app/Fyodor Dostoevsky/Crime and Punishment". The defect is specific to a role-suffixed credit.
Read, for the mechanism: AudibleBookMetadata.ToMetadata() (listenarr.domain/Audiobooks/AudibleBookMetadata.cs) passes Authors through untouched, and FileNamingService.Helpers.cs takes Authors.First() as the naming author ...
Automated Canary build