Closed ztec closed 1 month ago
Very interesting feature. As a big podcast consumer I can help to test the feature or to help to develop it :)
I'm also very much looking forward to this feature. Recently, Google Podcasts shut down, and I haven't found a suitable alternative yet. Currently, Miniflux seems to be the most suitable option; it just lacks this feature.
Hello @shepherdwind, I still interested to help with this feature but I didn't find free time to make any advance.
You can already use miniflux as a podcast player some interesting features were already developed:
Moreover Miniflux offers some interesting features such as rewrite rules, media proxy, categories or shares.
I also miss this feature. My workflow today is to directly press the "unread" button when I open a podcast episode :sweat_smile:
I have some time next week, I will probably look into it. But my (not so trustful) memory remind me that the "mark as read" feature is tricky to change to accommodate this feature. I'll get back to you here next week if I make any significant progress. Maybe a PR.
My approach is the opposite; I turn off the auto-read feature and manually mark each message as read after listening.
Thank you all very much for your responses. It's not very urgent, so I can also try to solve this problem on my own when I have time.
What do you think of doing it this way:
User
model. This solution would imply adding a new field in the DB and on the model alongside this one: https://github.com/miniflux/v2/blob/main/internal/model/user.go#L37
Also the markOnView
here https://github.com/miniflux/v2/blob/main/internal/ui/entry_feed.go#L44-L52 would not happen if there is any audio/video enclosure. A bit of JavaScript
code would then call the backend to make the entry as read when the enclosure has reach the end (or 80-90% of playback)
Enclosure analysis would rely on MimeType
to detect audio and video. This may not be perfect as not every rss feeds provide them correctly tho, but would effectively exclude "images" enclosure to trigger this mechanism as I don't think we want to enable this feature in this situation.
As this setting would be on the User
model it would be enabled for all feeds. I personally consider it acceptable for my workflow.
What are your opinions ? I drafted a PR of this change. I will polish it next week. https://github.com/miniflux/v2/pull/2684
I imagined a per feed setting (some feeds sometimes contain media attachment but are not podcasts for example) but I am ok with a global setting. I would prefer an absolute value instead of a percentage for the end of playback (some episodes are 3 minutes long and other are 3 hours long for example and the length the advertisement is not necessarily proportional to the length of the episode).
some feeds sometimes contain media attachment but are not podcasts for example
In my PR I considered entries without enclosures (no audio/video media) out of the scope. This mean the mark as read on view
is applied in this case.
mark as read on view
enabeld => Mark as read on viewmark as read on view
enabeld => Does not mark as read on viewI can make it more obvious by renaming the option For entries with audio or video enclosure, delay mark as read when playback is completed
I would prefer an absolute value instead of a percentage for the end of playback
This would be possible on a feed by feed basis, but at a global scale, this feel impossible to get right. Even on a feed by feed basis I'm not convinced by an absolute value. It would be hard to manage and pretty useless if duration variation between episode is high.
I've made the PR ready for review. Any comment is welcome there.
For any feed by feed options, I suggest we wait and see. If needed we could open an another issue to track that. I will be happy to do the development for it.
Following this PR I made https://github.com/miniflux/v2/pull/1843 , ~If it make it to the main~ it did:
I'm suggesting to allow via a feed option to change the behavior of "marking an entry as read" to only do it when all or one enclosure is played to the end. Also I think we should consider the end as something like 90% or anything alike as many podcast contains advertisement at the end and not listening to them should still be consider the podcast listened to. The actual % is yet to be defined.
I open this issue to check if people are interested and if it checks out with the minimalist philosophy of miniflux.
I volunteer to take care of the development of the feature but this one might be tougher as it involve the read status behavior and I have no idea how it works under the hood.