search

LeoKlaus / plappa

An Audiobook client for Jellyfin and AudioBookShelf, written in Swift/SwiftUI.
https://plappa.me
237 stars 1 forks source link

[BUG] Audiobooks cannot be played #158

Open mrburns-42 opened 4 months ago

mrburns-42 commented 4 months ago

Describe the bug Since the last update in Testflight, version 1.4.0 (37), newly downloaded audio books cannot be played. I can start audiobooks before the update, regardless of whether they were already running at some point or are being started for the first time. I can also listen to audiobooks in the stream. However, audiobooks that I downloaded after the update to the named version cannot be started. The audio book remains in exactly the same position as in the photo.

To Reproduce Steps to reproduce the behavior:

  1. Download an audio book.
  2. Try to start this audiobook after the download.
  3. See error

Expected behavior That the audio book can be started.

Screenshots IMG_7618

Logs [1.8.2024, 12:13] [CoreDataHandler] Initializing core data store... [1.8.2024, 12:13] [CoreDataHandler] CoreData store initialized [1.8.2024, 12:13] [PlaybackStateHandler] Syncing playback states through server [1.8.2024, 12:13] [PlaybackSessionHandler] Syncing playback sessions through server [1.8.2024, 12:13] [SoundHandler] Paused: name = AVPlayerRateDidChangeNotification, object = Optional(<AVPlayer: 0x300a13120>), userInfo = Optional([AnyHashable("AVPlayerRateDidChangeReasonKey"): AVPlayerRateDidChangeReasonSetRateCalled]) [1.8.2024, 12:13] [SoundHandler] Debug information: name = AVPlayerRateDidChangeNotification, object = Optional(<AVPlayer: 0x300a13120>), userInfo = Optional([AnyHashable("AVPlayerRateDidChangeReasonKey"): AVPlayerRateDidChangeReasonSetRateCalled]) [1.8.2024, 12:13] [SoundHandler] Paused: name = AVPlayerRateDidChangeNotification, object = Optional(<AVPlayer: 0x300a13120>), userInfo = Optional([AnyHashable("AVPlayerRateDidChangeReasonKey"): AVPlayerRateDidChangeReasonSetRateCalled]) [1.8.2024, 12:13] [SoundHandler] Debug information: name = AVPlayerRateDidChangeNotification, object = Optional(<AVPlayer: 0x300a13120>), userInfo = Optional([AnyHashable("AVPlayerRateDidChangeReasonKey"): AVPlayerRateDidChangeReasonSetRateCalled]) [1.8.2024, 12:13] [AudioBookShelfAPIHandler] Successfully posted session [1.8.2024, 12:13] [AudioBookShelfAPIHandler] Successfully pushed playbackstates [1.8.2024, 12:13] [SoundHandler] Paused: name = AVPlayerRateDidChangeNotification, object = Optional(<AVPlayer: 0x300a13120>), userInfo = Optional([AnyHashable("AVPlayerRateDidChangeReasonKey"): AVPlayerRateDidChangeReasonSetRateCalled]) [1.8.2024, 12:13] [SoundHandler] Debug information: name = AVPlayerRateDidChangeNotification, object = Optional(<AVPlayer: 0x300a13120>), userInfo = Optional([AnyHashable("AVPlayerRateDidChangeReasonKey"): AVPlayerRateDidChangeReasonSetRateCalled])

Environment(please complete the following information):

LeoKlaus commented 4 months ago

Thank you for the feedback, the logs don't indicate any issues with the download.

I've tried multiple different configurations, both split (multiple MP3s) and single (MP3 and M4B) and all downloaded files play as expected.

Can you check if this also happens on other devices / a fresh install?

mrburns-42 commented 4 months ago

Can you check if this also happens on other devices / a fresh install?

I will do that and get back to you.

mrburns-42 commented 3 months ago

I have tried it on a second device and the audiobook works here.

mrburns-42 commented 3 months ago

The problem is now reproducible, the following has happened to me with several audiobooks:

  1. I have added several audiobooks in MP3 format to ABS.
  2. I have started the conversion to m4b file for all of them.
  3. Immediately afterwards I opened Plappa to continue listening to another audiobook.
  4. Plappa has downloaded the updates from ABS, the new audiobooks in mp3 format are listed under the heading new audiobooks.
  5. A few hours / days later I want to download the converted audiobooks. Start the download, which seems to have finished at some point.
  6. I try to start the downloaded audiobook. It does not work.

When I updated Plappa, the download of the audiobooks in question suddenly disappeared, so I started a new download. I saw that Plappa was trying to download the MP3 files that were no longer available. At some point the download is shown as complete, although the files are no longer available on the server. The audiobook cannot then be started.

Now I clicked on the audiobook and dragged it down to force Plappa to update everything to the audiobook. After running it once, Plappa still tries to download the MP3 files, but the m4b file is downloaded correctly the second time.

I see two problems:

  1. Manually updating the data for an audiobook has to be done twice instead of once.
  2. It would be better if there was a mechanism for Plappa to do this automatically when metadata or files for an audiobook have been changed. Does the ABS API perhaps provide the possibility that only the updates are regularly retrieved by Plappa? For example, every x minutes and that the updates are then updated as a cron job in the background, for example whenever the device is loaded?
mrburns-42 commented 3 months ago

Update:

  1. Manually updating the data for an audiobook has to be done twice instead of once.

Yesterday I had to update the audiobook in Plappa five times before Plappa updated it.

LeoKlaus commented 3 months ago

The problem is now reproducible, the following has happened to me with several audiobooks:

  1. I have added several audiobooks in MP3 format to ABS.
  2. I have started the conversion to m4b file for all of them.
  3. Immediately afterwards I opened Plappa to continue listening to another audiobook.
  4. Plappa has downloaded the updates from ABS, the new audiobooks in mp3 format are listed under the heading new audiobooks.
  5. A few hours / days later I want to download the converted audiobooks. Start the download, which seems to have finished at some point.
  6. I try to start the downloaded audiobook. It does not work.

When I updated Plappa, the download of the audiobooks in question suddenly disappeared, so I started a new download. I saw that Plappa was trying to download the MP3 files that were no longer available. At some point the download is shown as complete, although the files are no longer available on the server. The audiobook cannot then be started.

Now I clicked on the audiobook and dragged it down to force Plappa to update everything to the audiobook. After running it once, Plappa still tries to download the MP3 files, but the m4b file is downloaded correctly the second time.

Thank you very much for looking into this, did you convert these files with ABS? I didn't even know that was an option. As the download link in ABS depends on the file ino, changing the file itself will always invalidate the links. In this case, streaming shouldn't work either, as the player uses the same link to stream the file(s).

  1. Manually updating the data for an audiobook has to be done twice instead of once.

This (and you having to retry five times) might be caused by the misrepresentation of the loading progress. The loading spinner disappears before the actual task is done. Depending on your connection speed and the size of the book, the metadata update could take several seconds.

  1. It would be better if there was a mechanism for Plappa to do this automatically when metadata or files for an audiobook have been changed. Does the ABS API perhaps provide the possibility that only the updates are regularly retrieved by Plappa? For example, every x minutes and that the updates are then updated as a cron job in the background, for example whenever the device is loaded?

AFAIK, the ABS API doesn't provide any sort of tracking for changes. One option would be to fetch changes whenever the detail view of a book is opened, but that could lead to some more complicated problems (what should plappa do when the files on the server side changed but the book is already downloaded?). Another option (I planned on doing this anyway) is fetching the most recent metadata before starting the download.

For example, every x minutes and that the updates are then updated as a cron job in the background

iOS is extremely limited in terms of what can be done in the background. As a developer you have very limited control about when or even if background tasks are executed and longer running tasks (~60s+) can be cancelled by the OS without warning.

I'm currently contemplating just skipping the local copy of the metadata entirely and only saving it when the actual book is downloaded.

This would fix issues like this but also require some significant changes to the entire app and change the UX quite a bit.

mrburns-42 commented 3 months ago

The problem is now reproducible, the following has happened to me with several audiobooks:

  1. I have added several audiobooks in MP3 format to ABS.
  2. I have started the conversion to m4b file for all of them.
  3. Immediately afterwards I opened Plappa to continue listening to another audiobook.
  4. Plappa has downloaded the updates from ABS, the new audiobooks in mp3 format are listed under the heading new audiobooks.
  5. A few hours / days later I want to download the converted audiobooks. Start the download, which seems to have finished at some point.
  6. I try to start the downloaded audiobook. It does not work.

When I updated Plappa, the download of the audiobooks in question suddenly disappeared, so I started a new download. I saw that Plappa was trying to download the MP3 files that were no longer available. At some point the download is shown as complete, although the files are no longer available on the server. The audiobook cannot then be started. Now I clicked on the audiobook and dragged it down to force Plappa to update everything to the audiobook. After running it once, Plappa still tries to download the MP3 files, but the m4b file is downloaded correctly the second time.

Thank you very much for looking into this, did you convert these files with ABS? I didn't even know that was an option. As the download link in ABS depends on the file ino, changing the file itself will always invalidate the links. In this case, streaming shouldn't work either, as the player uses the same link to stream the file(s).

Since I have been using ABS, I also convert my audio books with it ... this function is available and very convenient. I always add the audiobooks as MP3 files, pull the metadata, cover, chapter markers with ABS and then convert it into an m4b file. I would have to work out how to stream it.

  1. Manually updating the data for an audiobook has to be done twice instead of once.

This (and you having to retry five times) might be caused by the misrepresentation of the loading progress. The loading spinner disappears before the actual task is done. Depending on your connection speed and the size of the book, the metadata update could take several seconds.

That would explain it. An m4b file is around 1 GB in size and limited by the WLAN I have something between 400 and 600 MBit/s.

  1. It would be better if there was a mechanism for Plappa to do this automatically when metadata or files for an audiobook have been changed. Does the ABS API perhaps provide the possibility that only the updates are regularly retrieved by Plappa? For example, every x minutes and that the updates are then updated as a cron job in the background, for example whenever the device is loaded?

AFAIK, the ABS API doesn't provide any sort of tracking for changes. One option would be to fetch changes whenever the detail view of a book is opened, but that could lead to some more complicated problems (what should plappa do when the files on the server side changed but the book is already downloaded?). Another option (I planned on doing this anyway) is fetching the most recent metadata before starting the download.

I have just looked in the documentation of the API, if I see it correctly, there might be a possibility:

https://api.audiobookshelf.org/#library-item

Bildschirmfoto 2024-08-06 um 13 29 13

There is the info "The time (in ms since POSIX epoch) when the library item was last updated. (Read Only)", this could be retrieved for each audiobook and stored in Plappa's local database for each audiobook. Plappa could then regularly check whether there are any discrepancies between the local timestamp and that of ABS. If this is the case, Plappa would have to pull an update for the audiobook.

One idea would be to do it similarly to Prologue, where all changed audiobooks are sorted into a queue and the metadata is only pulled when the app is on and the iPhone is loaded or after a manual trigger in the settings. Wouldn't that also be something for Plappa? - A queue would also give you the option of downloading the chapter information for the individual audiobooks in the background. This would make Plappa feel even smoother when opening an audiobook that has not yet been opened.

For example, every x minutes and that the updates are then updated as a cron job in the background

iOS is extremely limited in terms of what can be done in the background. As a developer you have very limited control about when or even if background tasks are executed and longer running tasks (~60s+) can be cancelled by the OS without warning.

I've heard that before.

I'm currently contemplating just skipping the local copy of the metadata entirely and only saving it when the actual book is downloaded.

The fact that there is a copy of the metadata locally in Plappa makes the decisive difference for me compared to the other apps. Plappa feels as if you are working completely locally. When I look at other apps like the ABS app or Shelfplayer, it always feels like a web browser, which I find quite unpleasant.

This would fix issues like this but also require some significant changes to the entire app and change the UX quite a bit.

I'm just wondering whether I should turn the bug into a feature request, what do you think?