mirror of
https://github.com/advplyr/audiobookshelf.git
synced 2026-05-30 23:40:40 +02:00
[Bug]: Patreon RSS Feed bouncing on useragent fail #3093
Assignees
adam (Adam Melkus)
Clear assignees
adam (Adam Melkus)
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: starred/audiobookshelf#3093
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @noticons on GitHub (Nov 14, 2025).
What happened?
RSS feeds from patreon were formerly working just fine, and still work in other apps on my network, but Audiobookshelf has recently been unable to download episodes automatically or on request when I "check for episodes" through the webUI.
What did you expect to happen?
Downloading episodes! lol
Steps to reproduce the issue
If you don't have a patreon rss feed and don't want to pay to find out whether its working or not, Linux User Space has a free tier that has an RSS feed you can try out. https://www.patreon.com/linuxuserspace
Once you add the "member's only" RSS feed to audiobookshelf, everything works fine, including metadata and coverart, but fails to download episodes. I have included the log, which is below.
Audiobookshelf version
2.30.0
How are you running audiobookshelf?
Docker
What OS is your Audiobookshelf server hosted from?
Linux
If the issue is being seen in the UI, what browsers are you seeing the problem on?
None
Logs
Additional Notes
No response
@benn447 commented on GitHub (Nov 20, 2025):
I am experiencing a similar issue, but this appears to be a block by patreons cloudflare configuration, or cloudflare has recently updated their WAF rules, maybe causing audiobookshelf to be detected as a bot.
Cloudflare did apparently update their WAF this week, which caused a major outage, maybe this is related? 🤔
@noticons commented on GitHub (Nov 21, 2025):
If that is the factor it began two weeks ago--roughly one week before the outage. Whatever the problem is, and I'm sure you're probably right about it being cloudflare, I hope it is able to be resolved in some way.
@noticons commented on GitHub (Nov 21, 2025):
@benn447 are you still experiencing this as of today? I did some checking, and I'm still experiencing the same issue.
@MikaSturm commented on GitHub (Nov 22, 2025):
I have the same problem with both of my Patreon subscriptions
@noticons commented on GitHub (Nov 25, 2025):
@MikaSturm If this really is an useragent issue, as it seems to be, it seems the only solution would be a backend change on the server? I'm unfamiliar with this territory.
@benn447 commented on GitHub (Nov 25, 2025):
Unfortuneately, this is still occuring.
I suspect that the useragent has been detected as a bot on the cloudflare WAF or patreon has actively flagged it as traffic to be blocked.
I mainly think this is an auto detection on cloudflare, as it is unlikely patreon would actively block paying customers from using specific apps, having said that I recently noticed they are trying to push users to specific platforms like spotify.
I believe that modifing the useragent is probably the easiest solution, however its a bit disengenous to just set the useragent to chrome, firefox etc.
Maybe the better option here is to set a default useragent similar to the existing one, then allow users to modify their useragent if required?
This would mean the user isn't forced to use an incorrect useragent, but can use one if issues like this arrise.
@Vito0912 commented on GitHub (Nov 26, 2025):
It works completely fine for me. Maybe it's because you downloaded too many episodes, and Patreon protects its service by limiting how many episodes you can download (to prevent redistribution).
So this is not an issue with user agents (the error message appears because it tries multiple and none succeed) - but it does not actually mean it is caused by user-agents.
If a service decides to block users or IPs, in my opinion, it's their right to do so.
So maybe you, @advplyr can take a look, but imho this can be closed and is not an per se issue with user-agents nor ABS and just the service deciding to block users, where ABS can't do anything about it.
I just downloaded all episodes of the above mentioned podcast with no issues. You can try getting a new IP, if it maybe is caused by this. If you are using a VPN, make sure you disconnect (I was prompted by CF when using a VPN)
@nichwall commented on GitHub (Nov 26, 2025):
There are a number of user agent related issues and PRs, such as https://github.com/advplyr/audiobookshelf/issues/4758, https://github.com/advplyr/audiobookshelf/issues/3359, and https://github.com/advplyr/audiobookshelf/issues/3322. The initial PR with more discussion is in https://github.com/advplyr/audiobookshelf/pull/3099.
I don't think we necessarily need to expose the user agent string as a setting, because as mentioned in other discussions the point of the user agent is to identify what is being used. But, I can also see the argument for exposing the user agent as a setting.
@MikaSturm commented on GitHub (Nov 26, 2025):
I can confirm for my case, that it's not connected to the user agent, but the IP address of the server I host audiobookshelf on - thanks for the feedback
@Truth-And-Reason commented on GitHub (Nov 29, 2025):
Suggestion : Leave the user agent default as is , but in the podcast details section below "RSS Feed URL" add an input box for a user supplied alternative for that specific podcast. This would allow users a work around and also provide a trouble-shooting tool for users. It may cut down on the amount of help requests and bug reports.
@noticons commented on GitHub (Dec 2, 2025):
This may be a simple problem that the private rss is being over-polled and cloudflare is blocking it. So, perhaps reducing from the automatic "every hour" in the automation when adding the feed to a once a day or so will be more helpful. I've set mine this way; I'll report back whether this has been helpful.
@noticons commented on GitHub (Dec 2, 2025):
I also modified my docker-compose file to set the TZ variable for proper time reporting so that my crons will run at the right time in the container, as such:
@advplyr commented on GitHub (Dec 2, 2025):
I've not seen Patreon have issues with the user agent before. The episode downloader is set up to try 2 different user agent strings.
So far these 2 have worked for all feeds that I'm aware of. If we need to add another one that is easy enough.
I'd prefer not opening this up as another setting if we can avoid it.
I've had 2 private Patreon RSS feeds polling every hour for several years now.
@benn447 commented on GitHub (Dec 2, 2025):
This issue might be resolved now, at least for myself.
I tested patreon downloads again yesterday and they were successful.
No cloudflare errors in the logs.
I made no changes and my Ip accessing patreon remains the same.
I still think this was a cloudflare waf issue.
But I only have one patreon feed, so I dont think was cloudflare / patreon rate limiting me based on a large number of requests.
@noticons commented on GitHub (Dec 3, 2025):
While there have been a lot of comments about adding useragent options, that has never been the intention of this thread as I opened it. My purpose was to troubleshoot the actual problem that I was having. So there was no "plan" that needed to be disallowed in closing this issue.
In the interest of helping someone else who was experiencing the same issue that I was, the cron and TZ settings that I tried worked perfectly. If someone else experiences difficulty downloading private RSS feeds from Patreon, having it set to something less than every hour may be helpful.
For myself, I have it run once a day in the early morning, in the scheduling option on the audiobookshelf server for the feed. However, in order to have it do this correctly, I had to set the docker container to the correct TZ, as detailed above.