Improved Download Persistence and Discovery Logic

[ad2004teaster-cmyk]

Hello, and thank you for the great work you've put into Parabolic. I wanted to reach out and discuss the current download management architecture, specifically regarding the separation of "Downloads" and "History" and the repetitive "Discovering" process.

The Current Workflow Experience:
As a user, there is a significant friction point in how interrupted downloads are handled:

Single Videos: If a download reaches 75% and I close the app, the video disappears from the active "Downloads" queue and is moved to "History." To resume it, I have to manually initiate the process again, which triggers a completely new "Discovering" phase to fetch the metadata before it continues.

Playlists (The Major Pain Point): The issue multiplies with playlists. If the app is closed, the entire pending queue vanishes from the "Downloads" tab and dumps into "History." To resume, I have to manually click on each individual video in the history and wait for the "Discovering" process for every single one of them. This requires a massive amount of manual intervention and duplicated effort.

The Proposed Concept:
In most modern download managers, there is a single, unified list. If a download is paused or the app is closed, the item remains exactly where it was with its state saved. When you resume, it just continues downloading without needing to re-fetch the initial metadata. My suggestion is to keep completed, incomplete, and pending downloads all together in one single, unified log, where "Discovering" only happens once when the link is first pasted.

The Big Question:
I am genuinely curious about the technical architecture behind this. What are the specific technical hurdles and blockers that prevent you from implementing a persistent, unified download list in Parabolic?

Is it a limitation strictly related to yt-dlp and how download links expire over time? If so, is there no way to cache the metadata and only refresh the download token in the background upon resuming?

Are there complex architectural limitations in how the app currently handles state management and database entries between the active queue and history?

How difficult or complex would it be to merge "Downloads" and "History" into one persistent screen where the app simply remembers the state (Pending, Downloading, Paused, Completed) across sessions?

I’d love to understand your perspective on this and the complexity of these underlying mechanics. Is a seamless, one-time-discovery persistent queue something you see as achievable in the future?

Looking forward to your technical insights!

[ad2004teaster-cmyk]

I’ve actually found a solution to this workflow in Free Download Manager (FDM) using the Elephant plugin, which is also built on yt-dlp. It never requires re-discovery after the initial link is pasted; it keeps everything in one persistent list and saves the progress state perfectly. While FDM lacks Parabolic's superior features, like thumbnail embedding, advanced format options, and sophisticated subtitle downloading, it excels in providing that seamless, single-list experience. It is also worth noting that FDM is built using the GTK library as well, yet it manages this "one-stop" persistent log that is exactly what Parabolic is currently missing.

[ad2004teaster-cmyk]