Excellent point, I will include communication around Podcast 2.0 and all it’s features in the future.

There’s an offline mode on the clients to listen to downloaded episodes locally. That does not work on android just yet. That’s part of what makes the android client beta. All the clients (including android) are built with Tauri, so they all build from the same code. It does however introduce some challenges when finding libraries that will compile to both desktop and mobile.

I like it a lot. It’s not particularly difficult to write and once you get a feel for building components it’s pretty simple to conceptualize just about anything you’d need to build. I’d probably say difficulty is about the same to write react/svelte etc… Primary difference is that I don’t need to deal with webpack/npm dependencies. Absolute worst. web_sys support is great in rust and does absolutely everything you’d need to interact with a browser.

Go is simpler to write and is great for apis. Also has strong library support for interacting with databases. That’s the primary reason. They both create compiled binaries which means no library dependencies taking up space on the container. That’s the primary issue with python currently. I have no problem using actix in rust and that might be a good direction to go honestly, the primary concern is removing the compile at runtime language.

Significantly upgraded just about everywhere. More features, supports modern podcasting 2.0 support, works great on mobile devices, sync support. The list goes on.

You can, on your local device. Pinepods syncs progress between devices instantly. I like to switch between laptop and phones. If you only listen on your phone and the app works for you that sounds like a great solution already.

Absolutely true. And if you only listen to podcasts on your phone that’s a great solution. I like to switch between phone and laptop, and Pinepods syncs progress of everything on any client nearly instantaneously.

With the android App in Beta I’d continue using AntennaPods along with it. With Nextcloud/Gpodder sync or RSS feed exporting Pinepods is built to be great along with your current favorite apps. Not completely replace them. The goal is that it it could replace apps, but it doesn’t have to. You should be able to listen however you want to.

Same reasons for any Self hosted projects. Own your data, Archive the content, I like Self-hosting. Pick your favorite reason. Podcasting is built to be an open platform. It deserves open and Self Managable clients.

It’s a carryover from the original project. I did a complete rebuild of the frontend at one point to wasm due to rust having good frontend support with Yew. I plan to rebuild the backend too. All in due time.

I’m likely to rebuild the backend in Go, and while there will be a speed difference to a degree, the api isn’t sending complicated data. The bottleneck in response times usually isn’t what you’d make up for using a lower level language. Usually it’s more likely query times and Frontend processing. The Frontend rebuild MASSIVELY sped things up. Which is why I started there.

And yeah, doc site needs a refresh. I spend too much of my Pinepods time programming.

That sounds like sleep. Not hibernate. Hibernate is the process of moving your working ram onto disk. It’s similar to a full power off except your current state is saved. Hibernate doesn’t usually work oob. Sleep does.

Hi there, I sent you a reply over on the discord post. Let’s continue the conversation there. Should be an easy enough fix. Thanks!

Matrix room is a go! I’ve got a badge created on the repo Readme to join so hopefully anyone interested in matrix will see that and join over discord. I’ll get a link added to the documentation site as well. Thanks for the tips!

Honestly you guys have easily convinced me. I’d much prefer matrix personally anyway. I’ll get a matrix server up and running this weekend!

I mentioned that first for a reason 😁 I figured it’d be a selling point.

Nice! What isn’t already implemented is on the roadmap! Jump on the discord or open an issue if you have any troubles with the setup!

I sure am glad I posted about this here. Lemmy users are full of seriously good ideas. Can’t believe I didn’t think of that. That’s a really good idea. Straight to the roadmap!

All the reasons you gave are all the reasons I took on this project for sure. Thanks for giving it a go! Let me know if you have any troubles with the setup.

Ugh… It is unfortunate isn’t it… Here’s the history of the name.

I started development on Pinepods back when I was learning about python’s fastapi. It originally was built in pure python. And as you can probably imagine the UI was dog slow because python isn’t exactly fast. At that point it was called Pypods. Because python. I wanted to then change the name away from being a reference to a programming language. Only the nerdiest people would get that, plus I wanted it to have it’s own identity instead of being tied to a language. So I went with Pinepods, which itself is a reference to the pine snake (kept the snake thing despite moving away from python) and at that point I started adopting the forest theme. Which is why if you visit try.pinepods.online you’ll see rotating images of pine forests.

At this point, it’s been over a year and I’ve invested somewhat in the tree/forest idea. I would struggle to move away from it because I love the forest undertones.

Changing the name is feasible. And might be a good idea. It kinda stinks I’d need to change the domains along with it but I suppose it is what is there. The challenge that I struggle with is coming up with something that keeps the forest theming. I really like that aspect of it.

Extremely good call on the tagging. I love that. I’ve implementing saving for some basic essentially bookmarking of episodes so far but taking that one further and allowing the user to define custom save tags that they can associate without episodes and quickly access is a fantastic idea.

I’ll have to give your backlog queuing idea some thought. I think there’s absolutely room for that feature. There’s also a lot to considering with implementing it in the most effective way possible. I wondering about maybe taking a look at what podcasts you listen to the most, checking which episodes from those you haven’t listened to, and then aggregating them into a cohesive backlog. These kinds of computational tasks like refreshing for example already happen on the backend so adding more things like that doesn’t affect the user experience at all.