[Bug]: Podcasts not auto downloading

[andonevris]

Describe the issue

Waited for a new episode of a podcast to be released, by the next morning it still hasn't auto downloaded. If I do a manual scan for new episodes no new episodes are found. If I set the date back a day (in the search for new episodes dialog) the new episode is found.

Could this be a time zone thing?

LOGS: 2022-06-01 08:00:20 (AUTO CHECK FINDS NOTHING) INFO [PodcastManager] checkForNewEpisodes: "Security Now (Audio)" | Last check: Wed Jun 01 2022 07:00:18 GMT+0000 (Coordinated Universal Time) | No latest episode

2022-06-01 08:23:54 (MANUAL CHECK FINDS NOTHING) INFO [PodcastManager] checkAndDownloadNewEpisodes for "Security Now (Audio)" - Last episode check: Wed Jun 01 2022 08:00:00 GMT+0000 (Coordinated Universal Time)

2022-06-01 08:23:54 INFO [PodcastManager] No new episodes found for podcast "Security Now (Audio)"

2022-06-01 08:24:17 (MANUAL CHECK MANUALLY SETTING YESTERDAY'S DATE FINDS NEW EPISODE) INFO [PodcastManager] checkAndDownloadNewEpisodes for "Security Now (Audio)" - Last episode check: Tue May 31 2022 08:23:00 GMT+0000 (Coordinated Universal Time)

2022-06-01 08:24:17 INFO [PodcastManager] Found 1 new episodes for podcast "Security Now (Audio)" - starting download

Steps to reproduce the issue

1. Podcast is released but not downloaded automatically.
2. Running a manual scan retrieves no new podcasts.
3. Setting the date back by one day and searching for new episodes finds the new episode.

Audiobookshelf version

2.0.18

How are you running audiobookshelf?

Docker

[kurumushi]

I noticed that most podcasts use a RFC 2822 formatted pubDate in their feeds:

<pubDate>Sun, 13 Mar 2022 19:00:00 -0400</pubDate>

But the feed for the podcast you're pulling, Security Now uses RFC 822 format:

<pubDate>Tue, 31 May 2022 20:40:03 PDT</pubDate>

I believe this are both valid formats for a date in a podcast feed, so it's not a buggy feed itself.

I'm not so well versed in JavaScript, but I don't think the Date() object in the parser supports anything other than RFC2822

My guess is that the parser is ignoring the timezone with the RFC 822 date, and parsing the date as if it were GMT+0.

[advplyr]

I just tested the js date object with both of those pubDate formats

RFC 2822: Sun, 13 Mar 2022 19:00:00 -0400  =  2022-03-13T23:00:00.000Z
RFC 822: Sun, 13 Mar 2022 19:00:00 PDT  =  2022-03-14T02:00:00.000Z

They both look like they parsed correctly. PDT offset is -7 hours.

[advplyr]

Are you able to provide reproducible steps for this?

[andonevris]

Auto download has not worked once for me. I have to manually download each episode by using the trick above (setting date back one day)

For me it happens constantly, steps to reproduce are wait for next episode to come out and it won't download.

Steps to reproduce the issue

Podcast is released but not downloaded automatically.
Running a manual scan retrieves no new podcasts.
Setting the date back by one day and searching for new episodes finds the new episode.

[advplyr]

Can you give me an example podcast so I can add it and test

[andonevris]

Sure as per the intial logs, the "security now" podcast has done this every week since I set it up.

New episodes come out on Tuesday, I have to do the date trick every Wednesday to get the new episode. All my other podcasts also do the same thing but for testing you can use "security now"

Not sure if this would make any difference but I always delete podcasts after listening, could the fact that the podcast is always "empty" i.e. zero current episodes have an effect on new episode downloads?

[RandomWare]

I have the same issue. I am running v2.0.22 in docker on ubuntu.

After several podcasts have been downloaded (over 100GB of files) downloads seem to stop. Logs are unclear and I can't find any obvious interface to centrally monitor downloads and their status.

I recreated the entire container stack and queued up other downloads. I found this one case where it seems to stick.

» cat metadata.abs 
;ABMETADATA2
#audiobookshelf v2.0.22

media=podcast
title=It Could Happen Here
author=iHeartPodcasts
language=
genres=Society & Culture, News:Politics
feedUrl=https://www.omnycontent.com/d/playlist/e73c998e-6e60-432f-8610-ae210140c5b1/78d30acb-8463-4c40-a5ae-ae2d0145c9ff/bc7f369b-dce6-43c2-897e-ae2d0145ca12/podcast.rss
itunesId=
explicit=N

[DESCRIPTION]
A jaunty walk through the burning ruins of the old world, the one we all live in now, and a guide to avoiding the worst pitfalls along the road to a better world. It Could Happen Here season 1 ended with the possibility of a second civil war. It Could Happen Here Daily with Robert Evans, accepts collapse as a given, and tries to provide a roadmap to survival.

Logs don't show anything even in DEBUG.

audiobookshelf    | [2022-06-21 12:38:22] DEBUG: [DB] Updated user: 1
audiobookshelf    | [2022-06-21 12:38:24] DEBUG: [PodcastController] Podcast feed size 0.76MB
audiobookshelf    | [2022-06-21 12:38:28]  INFO: Recieved ping
audiobookshelf    | [2022-06-21 12:38:29] DEBUG: [Watcher] Ignoring directory "/podcasts/It Could Happen Here"
audiobookshelf    | [2022-06-21 12:38:29] DEBUG: [fileUtils] Downloading file to /podcasts/It Could Happen Here/It Could Happen Here Weekly 39.mp3
audiobookshelf    | [2022-06-21 12:38:59]  INFO: Recieved ping
audiobookshelf    | [2022-06-21 12:39:29]  INFO: Recieved ping
audiobookshelf    | [2022-06-21 12:39:59]  INFO: Recieved ping
audiobookshelf    | [2022-06-21 12:40:29]  INFO: Recieved ping

I cleared the download queue from the web UI and deleted the write-protected file from the disk. Then I queued just It Could Happen Here Weekly 39 to download but there's no indication that it had started downloading.

audiobookshelf    | [2022-06-21 12:44:00]  INFO: Recieved ping
audiobookshelf    | [2022-06-21 12:44:04] DEBUG: [PodcastController] Podcast feed size 0.76MB
audiobookshelf    | [2022-06-21 12:44:31]  INFO: Recieved ping
audiobookshelf    | [2022-06-21 12:45:01]  INFO: Recieved ping
audiobookshelf    | [2022-06-21 12:45:05] DEBUG: [PodcastController] Podcast feed size 0.76MB
audiobookshelf    | [2022-06-21 12:45:31]  INFO: Recieved ping

After a while I got this in the logs:

audiobookshelf    | [2022-06-21 12:46:31]  INFO: Recieved ping
audiobookshelf    | Failed to getFileTimestampsWithIno [Error: ENOENT: no such file or directory, stat '/podcasts/It Could Happen Here/It Could Happen Here Weekly 39.mp3'] {
audiobookshelf    |   errno: -2,
audiobookshelf    |   code: 'ENOENT',
audiobookshelf    |   syscall: 'stat',
audiobookshelf    |   path: '/podcasts/It Could Happen Here/It Could Happen Here Weekly 39.mp3'
audiobookshelf    | }
audiobookshelf    | Parse failed TypeError: Cannot destructure property 'format_long_name' of 'format' as it is undefined.
audiobookshelf    |     at parseProbeData (/server/utils/prober.js:223:11)
audiobookshelf    |     at /server/utils/prober.js:281:26
audiobookshelf    |     at runMicrotasks (<anonymous>)
audiobookshelf    |     at processTicksAndRejections (node:internal/process/task_queues:96:5)
audiobookshelf    |     at async PodcastManager.probeAudioFile (/server/managers/PodcastManager.js:146:26)
audiobookshelf    |     at async PodcastManager.scanAddPodcastEpisodeAudioFile (/server/managers/PodcastManager.js:113:21)
audiobookshelf    |     at async PodcastManager.startPodcastEpisodeDownload (/server/managers/PodcastManager.js:87:17)
audiobookshelf    | [2022-06-21 12:46:56] ERROR: [PodcastManager] Podcast Episode downloaded but failed to probe "/podcasts/It Could Happen Here/It Could Happen Here Weekly 39.mp3" Probe Failed
audiobookshelf    | [2022-06-21 12:46:56] DEBUG: [Watcher] No longer ignoring directory "/podcasts/It Could Happen Here"
audiobookshelf    | [2022-06-21 12:46:56] DEBUG: [Watcher] Ignoring directory "/podcasts/It Could Happen Here"
audiobookshelf    | [2022-06-21 12:46:56] DEBUG: [fileUtils] Downloading file to /podcasts/It Could Happen Here/It Could Happen Here Weekly 39.mp3
audiobookshelf    | [2022-06-21 12:47:01]  INFO: Recieved ping

The podcast downloader seems very obscure and does not expose enough status information to the user, or even in the logs. Is there any way to improve that?

[kormoc]

I'm having an different issue.

When I added "99% Invisible", only the latest 3 episodes were found. When I run "Look for new episodes after this date" with the current time, it doesn't find any additional episodes. If I change the date to be way in the past, it'll find 3 additional episodes every time I check for new episodes, however it doesn't seem to download any additional episodes on its own.

I would presume new episodes would download, however, I generally listen to podcasts from the first episode on and would want the complete archive downloaded.

[jvonhoff]

@kormoc , I think you might be hitting this line, which says to only grab the latest 3 episodes. I've had to set that date back several times to get it to download all the missing episodes (assuming that's what you're wanting). Possibly some room for improvement here (like a "grab all episodes" button or something)?

[advplyr]

Right now max episodes for auto download is set to 3. We can make that number adjustable in settings in the future. You can bulk download by pressing the search button on the podcast page

[lakoliu]

My podcasts also are not downloading automatically. I am running Audiobookshelf in Docker and have 4 podcasts. None of them had the episodes download automatically. I had to manually search for new episodes for each of them.

If I can get this worked out then Audiobookshelf will definitely be my new go-to podcast player, I'm really loving it!

[advplyr]

@lakoliu Please make sure you are using the latest server version and re-enable the auto-downloader. You can see in your server log files every hour the episodes are checked for and whether or not it succeeds or fails. If it fails 24 hours in a row then it will disable the auto-download option.

The latest server also allows changing schedule that episodes are checked for, the default is every hour.

[kormoc]

I would love it if the auto-disable was customizable. I personally would disable it, as there are times that I'm without internet for over 24 hours and wouldn't like to have to remember to re-enable all my podcast downloads.

[lakoliu]

I am using the latest version. It seems my issue is mostly with one podcast. Some of the errors in my logs:

ERROR [CronManager] Library item li_hvj125n3zwu2gc2ixo not found for episode check cron 0 * * * *

INFO [PodcastManager] runEpisodeCheck: "Coder Radio" | Last check: Wed Aug 24 2022 07:00:05 GMT+0000 (Coordinated Universal Time) | No latest episode

INFO [PodcastManager] runEpisodeCheck: "Under the Radar" | Last check: Wed Aug 24 2022 07:00:07 GMT+0000 (Coordinated Universal Time) | Latest episode pubDate: Wed Aug 17 2022 16:00:00 GMT+0000 (Coordinated Universal Time)

INFO [PodcastManager] runEpisodeCheck: "Self-Hosted" | Last check: Wed Aug 24 2022 07:00:08 GMT+0000 (Coordinated Universal Time) | No latest episode

ERROR [PodcastManager] getPodcastFeed Error Error: timeout of 5000ms exceeded

ERROR [PodcastManager] checkPodcastForNewEpisodes invalid feed payload for Coder Radio (ID: li_khh58844z4vt8hafzl) false

WARN [PodcastManager] runEpisodeCheck 9 failed attempts at checking episodes for "Coder Radio"

I added the feed using the search function of Audiobookshelf. Anything I can fix to make it stop failing?

[lakoliu]

Never mind, everything seems to be good now. It's auto-downloading. Not sure what the issue was, but thank you for your help @advplyr!

[advplyr]

I believe this has been fixed for a while now