Skip to content
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

[Enhancement]: Option to mark as played based on percentage listened #837

Closed
Jdiesel87 opened this issue Jul 14, 2022 · 12 comments
Closed
Labels
enhancement New feature or request

Comments

@Jdiesel87
Copy link

Jdiesel87 commented Jul 14, 2022

For me this has mainly been coming up with podcasts where the end credits can be quite long. It would be nice to have the ability to mark episodes as complete after a configurable amount of playback completion, say 90% or 95%.

I think it makes sense to limit it to podcasts as audiobooks are digested differently and are less likely to have end credits.

@Jdiesel87 Jdiesel87 added the enhancement New feature or request label Jul 14, 2022
@advplyr
Copy link
Owner

advplyr commented Oct 1, 2022

Do you think this should be configurable per podcast or is this a library setting?

@Jdiesel87
Copy link
Author

Jdiesel87 commented Oct 1, 2022

I think library setting should be sufficient. Personally I doubt I would spend the time to set it for each podcast. In my case I would probably set it at 95% and forget it.

@Catsrules
Copy link

Another vote for this feature! I know It is dumb but seeing a big list of book at that are 96-99% finished under my "Continue Listening" drives my OCD crazy. :) I end up just having to make sure I go to the very end on everything or mark it finished and delete the bookmark.

As for how to implement it. I agree a global library setting should be fine. However percent remaining doesn't work very well when we are looking at very long duration content. For example 98% completed on a 2 hour book is only a few minutes that is totally reasonable. But 98% on a 30 hour book is 36 minutes. That to long to assume the book is finished.

We might be better off just having a user defined minutes remaining instead of a percentage remaining. For example If there is less than 5 minutes remaining assume it is finished. I think that works much better when you have content that has such a huge variation in duration.

What are your thoughts?

@MattBlackOnly
Copy link

I think a global setting of 90% or 95% should be fine

@aether-coder
Copy link

Same problem, gotta go back and manually check as finished every once in a while since I leave when I start hearing the credits but that doesnt seem to be enough for it to be considered finished.

@advplyr
Copy link
Owner

advplyr commented Apr 16, 2024

@aether-coder When you mark an item as finished it isn't actually considered finished?

@aether-coder
Copy link

@aether-coder When you mark an item as finished it isn't actually considered finished?

Yes, when I manually mark the audiobook as finish the progress bar goes from yellow to green, they are removed from continue listening and are moved to listen again section. This is great.

What I meant to say is that I almost always end up manually marking the audiobook as finished. Many audiobooks have credits or maybe even bonus content. For that reason there's always a minute, sometimes a few minutes left when I close the player and move on to the next audiobook.

I get there are some pros and cons to impletementing a system that marks audiobooks (not to even mention podcasts) finished a few minutes earlier. In my opinion it would be best for everyone to have the option per library to consider audiobooks finished earlier. This could be percent based like 98%, and people can the percentage.

@lunik1
Copy link

lunik1 commented Apr 17, 2024

This would be a nice to have for me too. I agree that absolute time remaining is a better metric than percentage remaining: a podcast's outro will be about the same length every time.

@vahtos
Copy link

vahtos commented Aug 20, 2024

Do you think this should be configurable per podcast or is this a library setting?

I think the ideal option is both. The default value for a library should be the current default (100%), and can be overridden by the same setting on individual series or files within a library, with the most granular setting value (file --> series --> library) that has been explicitly set taking priority. For example:

File: undefined
Series: 96%
Library: 98%

Result: 96%

This would address differences between series within a library where one series might have a long end credit/ads sequence, and another does not. However, it wouldn't be a very clean way to handle this issue:

98% completed on a 2 hour book is only a few minutes that is totally reasonable. But 98% on a 30 hour book is 36 minutes. That to long to assume the book is finished.

There isn't a 100% precise answer for this sort of thing, but adding the functionality to use a static amount of time left as the threshold would at least remove some loss of precision as the content length scales. This would get a little tricky since the app would need to convert the relative amounts (percents) to the same time unit and compare, it's doable though.

advplyr added a commit that referenced this issue Oct 21, 2024
…shed. By time remaining or progress percentage #837
@advplyr advplyr added the awaiting release Issue is resolved and will be in the next release label Oct 25, 2024
@advplyr
Copy link
Owner

advplyr commented Oct 25, 2024

Upcoming release library settings:
image

Copy link

Fixed in v2.16.0.

@advplyr
Copy link
Owner

advplyr commented Oct 27, 2024

For downloaded media items in the mobile app the setting isn't respected for the offline copy of the media progress. The server will still show the item as finished but when in offline mode on the device the media item may still show as in progress.
I've opened an issue for this in the mobile app repo
advplyr/audiobookshelf-app#1356

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

7 participants