Bookplayer: Jump back in playback

[sprig]

Hi!

My books are split into many files and I listen to them as playlists.
A common problem that happens to me is that my headset buttons would get pressed while in my pocket and then playback continues while I'm not listening. This way it can play through several files.

When I go back to real listening and find the location where I really stopped, after said file is finished, playback goes back to the farthest location where it played. This is quite inconvenient and contrary to how I would expect a playlist to behave - I'd expect that if I start playback from somewhere in the middle, it would continue playing from there rather than jump after finishing one item/song/chapter.

Fix Suggestion: Keep track of "current location" separately from "farthest played location" and continue playing from the former in normal circumstances.

[GianniCarlo]

Hey @sprig !, mmmmm true 🤔, that would be a better way to handle it, if the item is selected manually by a user, then from that point forward, the next items get their playback reset back to 0

[GianniCarlo]

I currently took up the bookmarks branch again. Once I finish that, I'll look into this, in the mean time, anyone is welcome to take a stab at this 👌

[pichfl]

We have to be careful with this, not everyone uses playlists to represent books. We discussed marking a playlist as a book before, maybe it's time to look more closely into that.

[sprig]

Sorry about the bug label :-)

I'm trying to look into this myself as well (even for a private build) but I'm not really familiar with the codebase. Pointers would be welcome!

[pichfl]

A PR would be very welcome 👍

You may want to look into the PlayerManager → https://github.com/TortugaPower/BookPlayer/blob/master/BookPlayer/Player/PlayerManager.swift

And also the Playlist model →
https://github.com/TortugaPower/BookPlayer/blob/master/Shared/Models/Playlist%2BCoreDataClass.swift

If you can, this should probably be a "per playlist" setting, so maybe having a cell at the very end of a playlist that contains a toggle for this behavior (which should be on by default) would be a great way of managing this.

The toggle could read:

Treat Playlist like a single Book (Progress of later files will be reset if an earlier file is selected)

[GianniCarlo]

@pichfl you're right, this is better solved by the merged/bound books.

Not sure about having a toggle cell at the end of the playlist, I was thinking we could do it instead in two steps:

• First implementation would just tackle the action upon importing, in the alert, add a new option, to treat those books as one (actually this option could be added to the creation playlist alert whenever more than one book is involved).
• Second step would be to have the info view for book or playlist, and among those settings, give the option to convert into a bound book.

[GianniCarlo]

Mmmmm we may need to add top level functions to LibraryItem to get/set playback info so the current item can have a better abstraction in relation to the PlayerManager (e.g. current time, etc). There would be a new class (BoundBook?), not sure now if it should inherit directly from LibraryItem or one of the children Book or Playlist

[pichfl]

😯 bound books is the perfect name for that feature (which has nothing to do with this issue, but I had to write it somewhere)

[Paxo50]

Could it be as simple as allowing the tick to be removed? Catching up in the correct order is a pain after nodding off while listening if you haven’t set the sleep timer

[pichfl]

@Paxo50 you can do so, but you need to do so manually for each file.

I don't think this is a high priority feature (as it will be solved by a much more powerful solution in the future anyway), but if someone wants to tackle this all that's necessary would be an additional button to the menu of an item that allows you to reset the completion state of all files including and below the selected playlist item (Mark this and below as unread)

[pichfl]

389 will solve this, but is a bigger project. Keeping this open as there is no reason not to have the quicker fix in first.

[pichfl]

A bit related to #349

[GianniCarlo]

This should be already fixed in one of the interations of 3.7.x 🙂. Feel free to reopen if you find a case where it doesn't 👍