Fixed Playback advanding multiple chapter; Playbar Improvments#144
Fixed Playback advanding multiple chapter; Playbar Improvments#144rstewa merged 4 commits intorstewa:mainfrom
Conversation
…next When a media file ended, AudioPlayer_MediaEnded used CurrentChapterIndex + 1 to determine the starting chapter of the next file. Due to a race with the PositionChanged handler (which fires rapidly near the end of a file and could leave CurrentChapterIndex in a stale or wrong state), this caused the player to skip 2-3 chapters past the correct position. Fix: instead of incrementing the chapter index, explicitly find the first chapter whose ParentSourceFileIndex matches the next source file.
|
This is awesome. I just tried it out and it seems to work great. I want to take a little more in depth look in a day or so but unless something changes, I should be able to put this in the next release. |
PositionChanged fires many times per second and was calling SaveAsync on every tick. Each save creates a new DbContext, queries the full audiobook with all chapters and source paths, then writes — an expensive operation. When seeking backward in m4b files (which already requires decoding from an AAC keyframe), these saves pile up and stall the app for 60+ seconds. Fix: throttle saves to at most once every 2 seconds in PositionChanged. This is sufficient for resume bookmarking and eliminates the freeze.
|
Hey, just wanted to flag that I added a third commit to this branch after you started reviewing. While investigating the chapter-skip bug I found an unrelated but significant issue: rewinding in m4b files causes the app to freeze for 60+ seconds. Root cause: PlaybackSession_PositionChanged was calling SaveAsync() on every tick. Each save creates a new DbContext, queries the full audiobook with all chapters and source paths, then writes, which is a very expensive operation. When seeking backward in m4b (which already requires decoding from an AAC keyframe), these saves pile up and stall the app. Fix: throttle saves in PositionChanged to at most once every 2 seconds, which is still sufficient for resume bookmarking. I can split this into a separate PR if you prefer, just let me know. |
…ync calls" This reverts commit e2393f7.
|
I reverted the above changes since it didn't actually always fix the problem, as far as I can tell the real root cause problem is that windows media player just takes 30s to load my 400mb m4b file, the only real fix would be to swap out windows media player for another library to do playback. |
|
I think this fixes #142 |
It might but I think I have encountered #142 once myself even with this fix once (I'm not 100% I didn't just left it playing for longer then I think I did and can't reproduce it, also I'm on a different single file audio book now). Advancing multiple chapters at once problem fixed here might be a separate bug from sometimes starting playback mid chapter after advancing. |
|
I think this PR looks good. Gonna merge it. |
2 participants
This PR Fixes a bug that made the player sometimes jump ahead multiple chapter after reaching the end of a file,
Additionally:
I also made some changes to how the playbar function, previously if you held your mouse down and dragged while the audio book was playing the bar would constanly jump between where you want to drag it and where the current playback position, the bar also was unusable on touch screen.