starred/audiobookshelf
1
0
Fork 0
mirror of https://github.com/advplyr/audiobookshelf.git synced 2026-05-30 23:40:40 +02:00
Code Issues 1.0k Packages Projects Releases 10 Wiki Activity

[PR #3162] [CLOSED] Make OPML import non-blocking #3885

New Issue
Closed
opened 2026-04-25 00:17:26 +02:00 by adam · 0 comments
adam commented 2026-04-25 00:17:26 +02:00
Owner
Copy Link
Copy Source

📋 Pull Request Information

Original PR: https://github.com/advplyr/audiobookshelf/pull/3162
Author: @mikiher
Created: 7/14/2024
Status: ❌ Closed

Base: master ← Head: import-opml-task

📝 Commits (1)

  • 0c8285a Make OPML import non-blocking

📊 Changes

4 files changed (+40 additions, -17 deletions)

View changed files

📝 client/pages/library/_library/podcast/search.vue (+19 -9)
📝 server/controllers/PodcastController.js (+13 -3)
📝 server/managers/PodcastManager.js (+6 -3)
📝 server/utils/podcastUtils.js (+2 -2)

📄 Description

This fixes #3118.

In this bug, an OPML import took a long time to handle on the server, due to the large number of feeds, the connection timed out, and Axios.post() failed with an error.

This PR fixes this by changing the OPML import flow as follows:

  1. When calling /podcasts/opml, the client starts listening for an opml_feeds socket event
  2. On the server, /podcasts/opml now starts the OPML import asynchronously and returns immediately (note: this breaks the current behavior of the API)
  3. When the server finishes importing the OPML, it emits an opml_feeds event with the OPML feeds
  4. The client intercepts the event, and continues to show the OPML feeds modal as before.

I know we talked about adding a task so it shows in the appbar, and skipping the confirmation modal:

  • I think it may be better to keep the current flow, which seems synchronous to the user although it's now not, and perhaps start to emit progress events, so the user doesn't think the request is stuck.
  • I think the confirmation modal is useful. We should probably add the ability to select which feeds to add to the library.

Also changed a couple of minor implementation details:

  • Changed the timout in podcastUtils.getPodcastFeed() to 5000 (12000 seemed excessive)
  • Now throwing an error if no valid RSS feeds remain after running getPodcastFeed on the feeds extracted from the OPML (there seems no point in showing an empty feeds modal)

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/advplyr/audiobookshelf/pull/3162 **Author:** [@mikiher](https://github.com/mikiher) **Created:** 7/14/2024 **Status:** ❌ Closed **Base:** `master` ← **Head:** `import-opml-task` --- ### 📝 Commits (1) - [`0c8285a`](https://github.com/advplyr/audiobookshelf/commit/0c8285a4ae8a6e6af943e756b8f4745c2f7c6a05) Make OPML import non-blocking ### 📊 Changes **4 files changed** (+40 additions, -17 deletions) <details> <summary>View changed files</summary> 📝 `client/pages/library/_library/podcast/search.vue` (+19 -9) 📝 `server/controllers/PodcastController.js` (+13 -3) 📝 `server/managers/PodcastManager.js` (+6 -3) 📝 `server/utils/podcastUtils.js` (+2 -2) </details> ### 📄 Description This fixes #3118. In this bug, an OPML import took a long time to handle on the server, due to the large number of feeds, the connection timed out, and Axios.post() failed with an error. This PR fixes this by changing the OPML import flow as follows: 1. When calling /podcasts/opml, the client starts listening for an `opml_feeds` socket event 2. On the server, /podcasts/opml now starts the OPML import asynchronously and returns immediately **(note: this breaks the current behavior of the API)** 3. When the server finishes importing the OPML, it emits an `opml_feeds` event with the OPML feeds 4. The client intercepts the event, and continues to show the OPML feeds modal as before. I know we talked about adding a task so it shows in the appbar, and skipping the confirmation modal: - I think it may be better to keep the current flow, which seems synchronous to the user although it's now not, and perhaps start to emit progress events, so the user doesn't think the request is stuck. - I think the confirmation modal is useful. We should probably add the ability to select which feeds to add to the library. Also changed a couple of minor implementation details: - Changed the timout in `podcastUtils.getPodcastFeed()` to 5000 (12000 seemed excessive) - Now throwing an error if no valid RSS feeds remain after running getPodcastFeed on the feeds extracted from the OPML (there seems no point in showing an empty feeds modal) --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
adam added the pull-request label 2026-04-25 00:17:26 +02:00
adam closed this issue 2026-04-25 00:17:26 +02:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
authentication
backlog
bug
chapter editor
config-issue
ebooks
encoding/embedding
enhancement
help wanted
listening sessions & progress
planned
possible plugin
progress sync
pull-request
Mirrored from GitHub Pull Request
 sorting/filtering/searching
unable to reproduce
upload
users & permissions
waiting
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam (Adam Melkus)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/audiobookshelf#3885
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?