-
Notifications
You must be signed in to change notification settings - Fork 59
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature: Podcasts #188
Comments
@spl0k Given the size of this work, I'd like to commit it in multiple PRs. If you're cool with that, I can post the first one for getPodcasts, createPodcastChannel, deletePodcastChannel, deletePodcastEpisode. Otherwise, I'll post a bigger PR when I'm done with all of the work. |
Go ahead, submit multiple PRs 👌 |
Hello. Any progress on this front? Do you need help, advice or anything? I just noticed your question. I guess that could be a configuration option. Either download the file or stream directly from source if the configuration doesn't allow the download of episodes. If streaming from source it might be a good idea to cache the file in the case of clients requesting the same episode several times. See |
Hi, @spl0k. Work has taken over all of my time. My local repo has some near-finished changes in it (+330,-86). I'll take a look through my notes to make a plan. I'll hopefully start moving some commits upstream by the end of the month. I've setup AirSonic to mimic it's behavior for some of this. If I remember correctly, I wasn't able to prefix the Downloading the episode list will happen in the web request. I was thinking on-demand downloading episodes would happen in the daemon and cli (assuming large file sizes), unless there's a way to start an non-blocking job from a request? |
I'm not sure I understand to problem here (nor how podcasts work in Subsonic/AirSonic actually).
Not directly by the web application no. The only way would be to send a command to the daemon to tell it start the download. If you need an example on how to communicate from the web app to the daemon check the jukebox mode. Or for the CLI how scans are started. |
per AirSonic, I think you get where I was going using a prefix. I'll dig into your suggestion instead, which sounds more sane than my idea now that I know that code a little better. I was thinking of handling the decision of "stream or local file" using My preference for streaming would be to send an http |
(after thinking a bit more) I think I see now what you're saying about UUIDs. That's clever, and pretty easy to impl. Thanks! |
I haven't thought about that. That might be simpler to implement, provided clients support it. |
Hey- just checking in to let you know that progress is slow but steady. I'm writing for tests for downloadPodcastEpisode, refreshPodcasts, and stream in the API, and download & refresh in the CLI. After these things make it through PR, I'll wire up the daemon to do the work on a regular schedule. |
I've started working on this, so wanted to file an issue for awareness. I'm open to other contributors if there are any.
Phase 1
These functions offer the base functionality for podcast features, and are the most straightforward to implement. They only read or write records in the db. All of the heavy lifting is done by the items in
Phase 2
. A deviation from the Subsonic/Airsonic implementation is that these functions do not handle any disc IO including downloading or deleting episodes. The daemon will need to be running, orrefreshPodcasts
called using the CLI. This keeps the web server from suffering resource constraint due to big downloads, and allows the long-running work to be free from the limits of a request/response cycle.API
PR: #190 - closed; merged to spl0k/podcasts
Phase 2
These functions are expected to handle more data and take longer to run, and are offloaded to the CLI and daemon.
API
podcast:
, and stream details frompodcast_episode
table.CLI
Daemon
Later
This should be delayed until API compatibility upgrades past 1.9.0.
Open Questions
Q1: Can episodes be streamed to the client (e.g. Jamstash) from the source and not be stored on the server?
This would save HDD usage on the server, but relies on the source always being available. If streaming from source is not an option,
refreshPodcasts
should download episodes by default.The text was updated successfully, but these errors were encountered: