Podcast support

[JoshuaPettus]

Just an enhancement idea. Would be nice if music could automatically sync and download podcasts.

One challenge, would you want to store such files in the music library? Wouldn't be the worst thing ever, but would be nice to keep them separate. I currently have the same problem with audiobooks, but I'm sure I'm in a minority :)

[ei8fdb]

I have been searching for a self-hosted podcatcher for a long time. They exist but are not trivial to set-up. I would ❤️ the possibility of a podcast synch and download function in Music.

As a beginning: specifying where podcasts are stored, then being able to copy and paste a podcast URL, set up basic checking/syching schedule, and Music creates the directory automatically would be fantastic.

would you want to store such files in the music library? [...] I currently have the same problem with audiobooks

I currently do the same, I have 2 folders - AUDIOBOOKS, PODCASTS in my /Music folder.

As with the Internet radio request #784 I'm happy to provide designs and testing.

[memen45]

Implementation of the Ampache API methods for podcasts would be nice as well! http://ampache.org/api/api-json-methods#podcasts

Edit: same of course for the Subsonic API! http://www.subsonic.org/pages/api.jsp#getPodcasts

[stefangweichinger]

Implementation of the Ampache API methods for podcasts would be nice as well! http://ampache.org/api/api-json-methods#podcasts

I agree on that ;-)

[ei8fdb]

Now that @paulijar has added support for Internet Radio streams, I'm happy to contribute some designs for this feature.

Is anyone interested in working on this?

[paulijar]

I don't think that actually storing the podcast sources on your cloud would make much sense. What would make sense, would be to enable searching and streaming podcasts from external sources. With a quick google lookup, I found https://www.listennotes.com/api/ as a potential service API to provide the podcasts. This is free of charge for small installations (API requests limited to 2500 per month), but has a monthly fee of 120$ or more for larger-scale use. Obviously, if we use this, then each Nextcloud maintainer must register the service independently to get their own free 2500 requests. Or if anyone knows of a better service to interface with, I'm open to suggestions.

[JoshuaPettus]

Interesting, I've always used podcasts with the itunes model. Where the local computer automatically downloaded the latest pod cast from the stream, and I would listen to it at my leisure. Right, now I just download them manually and put them in a podcast folder and then listen to them on dsub (subsonic). I thought it would be nice to automate that process like I use too with itunes. The app does have it's own podcast menu which would be nice to leverage.

Not that I dislike your idea, though I am slightly hesitant to subscribe and add a third party service into the mix. Would I be able to listen to the casts with dSub with your idea? I'm curious why you feel having nextcloud download the podcast automatically doesn't make sense.

[paulijar]

I have only limited experience on listening to podcasts so my point of view might be skewed.

Where the local computer automatically downloaded the latest pod cast from the stream

How does this work? How do you set up your computer to follow some stream. Who provides those streams?

Right, now I just download them manually

Where do you download them from?

Would I be able to listen to the casts with dSub with your idea?

Yes, as I see it, the possibility to make the Subsonic integration does not depend on who actually hosts the audio files.

I'm curious why you feel having nextcloud download the podcast automatically doesn't make sense.

I believe that the podcast episodes are mostly disposable: you listen to an episode once, and in most cases, don't care about it afterwards. For this reason, you don't want to hoard them on your disk. In contrast, when you buy or otherwise acquire some music album, you might want to listen to it many many times over the years. My music library certainly contains lots of albums I have bought in the 90's, and I still listen to them regularly.

If you are going to stream some podcast from your Nextcloud server to dSub, then obviously you need a working internet connection both on your server and on your mobile. Furthermore, if your server could check for and download the new episodes from some external source, then there has to be some kind of API provided by that source. Now, if both of these hold, then what benefit would it bring to cache the podcast on your server? If your server can obtain the content from an external service and dSub can then stream it from your server, then why couldn't your server as well relay dSub to stream the content from the original source?

[memen45]

I can mostly agree with you. Caching makes sense on the device you listen to, such that you can listen without an internet connection. However, if you are able to access your Nextcloud server, you will most likely be able to access the original podcast streams as well. Also, for the subsonic/Ampache endpoints, the actual streams can just be redirected to the original streams.

However, I do not understand the third party you mention. As far as I understand it, you would need a third party to discover/explore unknown podcasts on the web. As soon as you have a known podcast, you can just use that known url to be updated (RSS is used for podcast feeds). So as long as exploring is not needed (i.e. podcasts are added by copy/pasting rss urls), this third party is not needed right?

[JoshuaPettus]

How does this work? How do you set up your computer to follow some stream. Who provides those streams?

I'll admit it has been ages since I've used the now defunct I tunes, and I'm sure things have changed with the current ecosystem. But I'll give an example site https://www.npr.org/podcasts/510289/planet-money There you can choose your podcast service, and I bet now it's automatic. I seem to remember copying the rss link into itunes but that was ages ago.

Where do you download them from?

The ones I've always listened to, including that one, do offer to download their episodes individually, which I then import.

I believe that the podcast episodes are mostly disposable: you listen to an episode once, and in most cases, don't care about it afterwards.

This is very true, It does get to be something I have to and delete later.

[paulijar]

As soon as you have a known podcast, you can just use that known url to be updated (RSS is used for podcast feeds). So as long as exploring is not needed (i.e. podcasts are added by copy/pasting rss urls), this third party is not needed right?

Okay, if there is some standard (or at least widely used) way to describe podcast streams with RSS, then we could well start by having just manual setup for streams. Integration with some podcast lookup service could maybe be added later as an alternative.

[JoshuaPettus]

The more I have been thinking about this, the more I think you are right. Nextcloud server is always connected to the internet so just a relay to the source makes sense. And then for subsonic clients, dunno about ampache, they should handle their own caching for offline purposes, so let them do what they want.

[testcocoon]

My experience with the RSS lookup services is that they are really incomplete. Searching does not always work very well for some but they don't list all podcasts. I prefer simply to download the RSS from the corresponding site this works better. So for me a simple RSS support of the podcasts will match all what I need and would be great because it would permits to listen podcast with embedded devices like the garmin watches.

[ei8fdb]

I've had some time to do some design sketches for how podcasts might work. These are just beginning thoughts and probably miss something so I welcome comments and suggestions on how to improve them.

(Apologies if they're a bit too sketchy.)

Minimum viable product!

The functionality I've focused on is the minimum needed: 1) be able to add a podcast URL manually, 2) be able to play a podcast, 3) be able to sort episodes.

Downloading vs. streaming episodes

My behaviour with podcast episodes has changed over the years. I used to download all and play them one by one. This has changed due to the number of podcasts I listen to now.

My podcast catcher of choice is AntennaPod. I've used for years. I use many features it has to deal with this stream/download question - stream/download episodes, filters on what to show, favourites.

My current behaviour is:

• to by default stream the podcast episode.
• once the episode has been played, Antennapod automatically marks it as played
• if I want to keep an episode, I use the "add to favourites" feature in Antennapod, which means the episode is added to my favourites list
• I can then download the episode manually, or listen to it again as it's in the favourites list

In order to start small, I suggest start with support streaming only.

Possible UI design implementation sketches

I've tried to reuse parts of the already in place Music UI to minimise development work. I've also tried to keep the UI consistent with other parts of Nextcloud.

1. First time they open the podcast screen

The first time the user opens the podcast screen, (ideally!) they'd be prompted to either 1) paste the URL for their podcast or 2) they're able to search for a podcast.

Here's a very basic sketch on how it'd look:

I've been thinking about the similarities between Internet Music and Podcast and I think this add/search UI could be used for both.

2. Manually add a podcast URL

I understand implementing search is more work, so I think as minimum being able to copy and paste the podcast URL would be a good start. There would need to be some explanation of where to look for podcasts, etc.

3. The podcast has been successfully added

When the podcast is added - the most recent 5 episodes are visible beside the podcast in the middle panel view. This probably looks familiar - the added podcast UI pattern uses the album list UI design. I think this UI pattern works well here. A user who's familiar with navigating albums will understand what happens here. Consistency is good UX! :)

All the UI elements present in the albums navigation are present here - play button on hover, alphabet navigation, artwork (if available), the information icon shows all podcast episodes available.

4. Show all podcast episodes

Podcasts are organised under the publisher/author name - in this case RTE.

When the user presses 'i' icon, it opens the side panel. Here it shows useful metadata about the podcast? What's available? Not sure.

It also shows all the playable episodes. The user can sort them by episode number - ascending and descending.

5. Adding more and more podcasts

As the user adds more podcasts, they'll build up like albums.

Future functionality ideas

There's still a lot of functionality not in the sketches - for example: 1) search for a podcast, 2) download a podcast individual episode, 3) create filters of what episodes to display (e.g. if episode is downloaded, etc), 4) create a "queue" of episodes, 5) change playback speed, 6) share episode, 7) sort episodes by different criteria (date, title, duration, etc), 8) create a queue/list of episodes to play,

and others.

Thoughts, opinions, improvements?

@paulijar @JoshuaPettus @memen45 @stefangweichinger @testcocoon I'd be interested in hearing your thoughts on the sketches.

[JoshuaPettus]

Nothing wrong with sketches :) I'm just the peanut gallery over here, but I would find something like that extremely use-able, certainly good for my needs. As Paulijar pointed out before, there would be no need to actually download a file on the nextcloud server, seeing as offline isn't a thing. If you want to listen to an episode just play it and have it be streamed. If this would be presented to subsonic, I would think subsonic would have its own caching ability for offline listening as it does for music files.

[testcocoon]

Joshua I don't agree with you. Streaming is not possible with all subsonic clients. For the Garmin watch there is a very good client (https://apps.garmin.com/en-US/apps/600bd75f-6ccf-4ca5-bc7a-0a4fcfdcf794) and it permits only to download the playlist (like for deezer, spotify and other provider). Listening is the offline.

So to support this kind of clients it is necessary to:

1. Map the posdcast as playlist
2. Download the episode

This kind of devices are completely incompatible with streaming and anyway, for streaming you need to have a network connection. For many outdoor activities, streaming does not work well.

[ei8fdb]

I feel downloading a podcast episode would be a very good feature to add. Seeing as I can't contribute code (lack of skillz!) I think it'd be unfair for me to say it must be there from day 1.

I'd be happy initially with being able to do what I outlined in the Minimum viable product section above.

[memen45]

@testcocoon Actually I am the developer of the SubMusic app you mention (memen45/SubMusic) and I partly agree with you. The playlist information is indeed required from the server, however, the location of the stream does not matter. At this moment, the files are downloaded using the /stream endpoint (because it allows for transcoding), the nextcloud app can simply redirect this stream url to the original url (please correct me if this is not possible).

Another possibility would be to implement the Podcast API endpoints for both Ampache and Subsonic as suggested before. I have not implemented it in the SubMusic app yet, since I cannot test against a server. If the nextcloud/music app supports it, I would definitely work on implementation of these podcast endpoints as well. This second solution does not require the server to download podcast episodes either, since they can still be retrieved from the /stream endpoints. If necessary, I could even implement support for remote downloads from episodes. The server would return episode information in json form with a stream url that is not located on the server itself, then the SubMusic app could simply follow this url to download the episode. IIRC the nextcloud/music app already provides the download/stream urls via a _play attribute in the json.

In conclusion: I do not think there is a good reason to cache podcast episodes on the nextcloud server, unless you expect the original podcast server to be down often. Caching on the device makes more sense, as you could expect your device to lose internet connection from time to time (or in case of a watch, you assume no internet connection at all during normal use).

For the Minimum Viable Product you propose: I think it is a good idea if you consider the UI. However, I think it should be possible to simplify the MVP even more if you only consider the backend (database tables, add podcast, delete podcast, get episodes, download/stream episode methods). With those methods implemented, it could already work with other (Subsonic/Ampache) clients and the MVP you proposed for the UI can be implemented thereafter.

[testcocoon]

@memen45 Happy to see that you are in the loop. I know that you are very reactive and you have already developed a podcast mode for your garmin music app. I wanted just that the thread here take care about the specificity of Garmin devices which works offline and not decide to a streaming solution only (which make it impossible to use for all devices which preloads the mp3 files to play it once disconnected from any networks).

But since you are in the loop, I have no concern that you raise your hand if something is in contradiction with your implementation. ;)

[paulijar]

Thanks @ei8fdb. Reusing the Albums view layout is what I had in mind, too.

The mock up still doesn't show, how the user adds new podcast feeds after there is already some. I was thinking to do something similar to how the Internet Radio option "Add manually" works (introduced in Music v1.1.0). But if we have that, then having also the "First time use" screen shown in the mock up is no longer absolutely essential and hence not part of the MVP.

Also, listing all the episodes under the details pane is nice but not part of the MVP; instead I would have the "Show all XX episodes..." link after the first 5 episodes, similar to the Albums view.

But what we do need for the MVP, is some method to remove previously added podcast feeds. This could work either via the details pane or then similar to the Internet Radio, with a trashcan appearing when hovering the podcast title. Either way, there shall be a confirmation dialog, as this is a destructive action and not carried out on daily basis.

I have a bit mixed feelings about showing the episodes in inverted chronological order: It makes sense because the latest episodes are usually the most interesting for the user. But on the other hand, how shall the "skip next" and "skip previous" buttons then work, as well as the automatic progression to the next episode after one has been played to the end? Is the "forward" direction then from bottom to top, and is this too surprising for the user?

As @memen45 suggested, the downloading of episodes for offline use is mostly a client-side feature, when it comes to Subsonic and Ampache clients. It doesn't require storing the episode on your Nextcloud/ownCloud instance, the client should be able to download the file directly from the original source. The podcasts will not be mapped to playlists, but we shall implement the podcast API endpoints of Ampache and Subsonic.

[memen45]

I have a bit mixed feelings about showing the episodes in inverted chronological order: It makes sense because the latest episodes are usually the most interesting for the user. But on the other hand, how shall the "skip next" and "skip previous" buttons then work, as well as the automatic progression to the next episode after one has been played to the end? Is the "forward" direction then from bottom to top, and is this too surprising for the user?

Skip next for podcast episodes would definitely be 'go to one older episode' in my experience. A lot of podcast players do work with queues however to allow the user to choose the order of playing.

[paulijar]

The podcast support has now been released in Music v1.3.1.

[JoshuaPettus]

Just wanted to say, thank you so much! It works perfectly, and I cant tell you how awesome it is to use in DSub, with the bookmark support and DSub's own bluetooth integration. Has made listening to podcasts in the car fantastic.

[pklampros]

I'd just like to link here a few things: There's another nextcloud app for Podcasts, but also one that aims to allow for synchronisation of the Antennapod podcast player across devices using a nextcloud-hosted gpodder api, with potential integration between the two.

[JoshuaPettus]

Honestly I'd like this one. It's a robust and easy to use solution with a plethora of supporting apps across many devices and platforms. Even my TV can have subsonic support but not gpodder.

Also I should mention there is yet a third app, News, which has podcast support with the rest of its RSS functionality. Plus it has its own dedicated app. So there more then precedent for overlap.

Personally I fear I found News to be infuriating, with no ability to keep track of where you left off in a stream. It would reset to the beginning whenever my phone would get a call. Not blaming the author or anything, it's a herculean effort to get where it is now, and there probably isn't even the framework to make it possible to do bookmarking without him doing it himself. Music just has the advantage of using an existing system that has a small army of other people having already having done that work.

[aaronhuggins]

I just want to say "Thank you" to everyone who contributed for implementing this. I don't want a separate app, and podcasts in the News app were a nightmare, along with the codebase. My desire to have a unified, easy to use interface was leading me down a path to modifying Navidrome to natively use webdav.

This effort is just a better, friendlier experience for me. And now that the groundwork is laid, I'm excited to see this mature and will be hacking on this as well.

[2br-2b]

Thank you so much for supporting this!

I use the Nextcloud Gpodder sync app, but it doesn't have a GUI (as far as I'm aware) except for the ones in connected apps (for me, KDE's Kasts). It'd be really nice if this could sync with that backend so I can listen to podcasts in my browser. I feel like this should be in a different issue, however.