mirror of
https://github.com/advplyr/audiobookshelf.git
synced 2026-05-30 23:40:40 +02:00
[Bug]: Podcast cron infinite hang #2647
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#2647
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 @SuperEllipsis on GitHub (Mar 10, 2025).
What happened?
Sometimes when the server has been running for a while, it seems to hang on it self, with a simple message of "[CronManager] Podcast cron "0 * * * *" is already executing", it will not download more podcasts from the RSS feeds automatically, until the docker container is restarted. I can still go through each manually and download the episodes from the RSS feed
What did you expect to happen?
I expected it to potentially throw an error/warning in the logs, if it was hanging, and then retry later
Steps to reproduce the issue
I am unsure of when and how it happens, but usually it is just
Audiobookshelf version
v2.19.5
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
@Vito0912 commented on GitHub (Mar 10, 2025):
Could you please enable debug logging (top right) and check if there is anything in the logs after a server restart and the first scan?
@SuperEllipsis commented on GitHub (Mar 10, 2025):
Good catch, I will do that. And update, if I find something in the debug logs
@SuperEllipsis commented on GitHub (Mar 16, 2025):
I restarted the server, and set the log level to debug. And a couple of days later, it failed again.
Here is the log from the day, where the "Podcast cron "0 * * * *" is already executing" starts to appear
2025-03-13.txt
Specifically, here is a selection of message right as the warning starts (full logs in file above):
@shimeike commented on GitHub (Mar 18, 2025):
I am seeing this same issue exactly as described and with same setup as @SuperEllipsis .
Only abnormality in the logs (other than those same Cronmanager warnings once the issue has occurred) are some episode data errors for some feeds. I guess these have always been there and likely don't relate to the issue.
I've setup a cron job to restart the container daily as a workaround for now. Will report back if I see anything else of use in the logs. For now, just wanted to establish that the original report is not an isolated case.
@Vito0912 commented on GitHub (Mar 18, 2025):
Do you have set a custom
PodcastDownloadTimeout?@shimeike commented on GitHub (Mar 18, 2025):
Do you mean
PODCAST_DOWNLOAD_TIMEOUTenvironment variable? If so, no I do not have this set in my docker-compose.@SuperEllipsis commented on GitHub (Mar 24, 2025):
I have looked through the logs from the last few restarts. If it helps, it seems that the following RSS feed, might be causing the trouble for my setup: "https://nihongoconteppei.com/feed/podcast/". It might infact coincide with the release of a new episode, the dates for when ABS stops downloading is the same day, as new releases on their website (so far at least).
It has been the same line every time, right before the warnings starts:
@Vito0912 commented on GitHub (Mar 24, 2025):
Yeah, I saw that too. I cannot reproduce it on my site. And if I looked up correctly, the code stops working where it physically should not be able to be stuck.
The only conclusion I had, was that the timeout does not get triggered. Any error, timeout, success would result in a log entry.
But the timeout also seems also not to be the problem
@SuperEllipsis commented on GitHub (Mar 24, 2025):
It is quite weird. I might try to setup another instance on some alternative server equipment I have laying around, and see if it triggers on that as well. Or if I might have to try and clean / migrate to a new ABS instance.
@lodesmets commented on GitHub (Apr 15, 2025):
Hey all, I have had the same issue multiple times, but usually the logs got deleted, because I only noticed the issue after a while. But now I have some logs
It looks like ABS is trying to get the feed, but then it hangs
(2025-04-15T04:00:01.120413732Z [2025-04-15 04:00:01.095] DEBUG: [podcastUtils] getPodcastFeed for "https://feeds.soundcloud.com/users/soundcloud:users:293803449/sounds.rss")
@lodesmets commented on GitHub (Apr 25, 2025):
I don't know what changed in the latest couple versions. But I have version 2.20.0, and the issue happens quite often (at least once a week)
@lodesmets commented on GitHub (May 8, 2025):
I know it is a shitty solution, but I made a script to restart the container every day
@vincentscode commented on GitHub (May 25, 2025):
Unfortunately I have the same problem. The logs show nothing abnormal except for that warning. Is there anything we can try to make this reproducible?
@badbrain79 commented on GitHub (May 25, 2025):
same problem here
@Eragos commented on GitHub (Jun 1, 2025):
@advplyr your right - Thank you really much!
Btw: Last days it goes without problems. If I have more results of observe this behaviour I hit you up ;-)
Best Michael
@hardwareadictos commented on GitHub (Jun 3, 2025):
Same here:
Podcast sync is broken since some versions. They don't sync correctly or directly they don't sync till you restart the container. And lots of podcasts are tagged as "missing"
@Vito0912 commented on GitHub (Jun 3, 2025):
@hardwareadictos This looks like another error.
Also, you might want to consider wrapping long logs in a details section so it does not spam or make the issue difficult to scroll.
Summary Here
Long logIs there anything else in the logs besides
[podcastUtils] Invalid podcast episode data? Also, did you check if the RSS feed is still correct?@Vito0912 commented on GitHub (Jun 5, 2025):
In the current edge version, I added some new code that might fix the issue. You can update to the edge version now or wait for the next release. Please let us know if the issue happens again. If the problem seems fixed, check the logs for
checkPodcastForNewEpisodes failed to fetch feed for xxx..., so we can check if it really was because of this@Eragos commented on GitHub (Jun 5, 2025):
Good time to test it THX ❤️
I got the missing episodes by hand. Starts yesterday. Installed :edge now :-D
Best Michael
@Eragos commented on GitHub (Jun 7, 2025):
Seems to work actually no more warnings like this. I'll keep an eye of this.
@Vito0912 commented on GitHub (Jun 7, 2025):
As long as you do not have an (error) log that says
checkPodcastForNewEpisodes failed to fetch feed for <some text>, the issue should not have happened again. Could you please check if you see this entry? If you do, please let me know.@Vito0912 commented on GitHub (Jun 16, 2025):
This is now in stable release. Please check if the error happens again in the future, so we can eventually and hopefully close this issue.
@Eragos commented on GitHub (Jun 16, 2025):
Hey @Vito0912
I took a close look to those error messages in the last nine days. Actually there is no more abnormalities in the log visible. For me it's fixed ;-) A warm thanks!
Best, Michael
@shimeike commented on GitHub (Jun 16, 2025):
@Vito0912 thanks for this! I have disabled my nightly container restart cron job and will monitor this new version.
@SuperEllipsis commented on GitHub (Jun 22, 2025):
@Vito0912 Thank you very much for the fix in the latest stable version 🎉
I have had the stable version running since it was released, and so far it has run without any problems - No more restarts needed
Therefore, I am closing this issue as fixed 👍
@Vito0912 commented on GitHub (Jun 22, 2025):
@SuperEllipsis No problem. No clue why this issue occured in the first place. Therefore could you please do me one more favor?
Could you check your past logs to see if you find the string
checkPodcastForNewEpisodes failed to fetch feed for?And nice this could be closed now!
@SuperEllipsis commented on GitHub (Jun 22, 2025):
Sure, I have looked through the logs, and the error you are refering to has occured twice since I changed to the latest release