[BUG] [AUDIOBOOKSHELF] Encountered an error while starting playback: <filename> does not lead to a playable file.

[nathang21]

Describe the bug I am unable to resume playbook of this audiobook (via audiobookshelf) on iOS.

Scope

• The first 3 chapters I was able to stream seamlessly previously. Now I can not play any chapter, perhaps a metadata update or something corrupted the file.
• Other books work fine via Plappa, this is the only book i've found with this issue (but other players can still read it).
• Playing directly from ABS in the browser works fine.

To Reproduce

1. Open Plappa on IOS
2. Select "Sapiens" the audiobook with this issue
3. Attempt to play/resume any section
4. See screenshot error below

Expected behavior I should be able to play this audiobook normally, as I can on other devices/players.

Screenshots

Logs abs.log plappa.log

Environment:

• Device: iPhone 14 Pro Max
• OS: 17.5.1
• Version 1.2.0
• Server Version Audiobookshelf 2.10.1

Additional context Error: message Encountered an error while starting playback: <filename> does not lead to a playable file.

Troubleshooting Steps Taken

1. Disconnect from abs server in Plappa, and re-configure. [Failed]
2. Restart app. [Failed]
3. Review abs/plappa logs for more indication on the problem [Little details]

[LeoKlaus]

Hi Nathan,

thank you for the detailed bug report.

The 1.2.0 update changed a lot in terms of how files and chapters are handled to uncouple chapters from files. I've tested a bunch of different scenarios to make sure the transition wouldn't be noticeable by the end user, but I might have missed some.

The path plappa tries to play the file from is local, so plappa assumes you have downloaded the audiobook.

My first suggestion would be to remove the download (even if you didn't actually download the file), then refresh the metadata by pulling down in the detail view (where you can see the chapters) and try if the book plays as expected now.

If you intentionally downloaded the audiobook in question, you can of course download it again now.

[nathang21]

Interesting that makes sense - I kind of figured it was something like that. I have already tried deleting/re-downloading the file (I did previously have it saved offline), but did not try the metadata refresh.

I just performed the steps you suggested, and I get a similar error, although this time it shows the remote path of my domain, and not the local file path:

Encountered an error while starting playback:
URL https://abs.<domain>.<tld>/api/
items/cfc4f0ed-dea8-4688-ac67-
aaac5130315e/file/13340/download does not lead to a playable file.

I also tried re-downloading locally + refreshing the metadata, and that didn't make any different (still shows exact same error with remote path).

Thanks for the quick reply, any other ideas?

[LeoKlaus]

That is very curious. The file link is built using the library id of the ABS item and the ino of the file. Just by looking at it, it seems to be valid.

You can try replicating the requests plappa makes to see if that works. To do so, you'll have to obtain the token for your user:

curl --request POST \
  --url https://abs.<domain>.<tld>/login \
  --header 'Content-Type: application/json' \
  --data '{
    "username": "demo",
    "password": "demopass"
}'

and then download the file like this:

curl --request GET \
  --url https://abs.<domain>.<tld>/api/items/cfc4f0ed-dea8-4688-ac67-aaac5130315e/file/13340/download \
  --header 'Authorization: Bearer <your-token-here>' 

[nathang21]

Curious indeed. I needed to add the --output <filename> flag to get the 2nd command to work, but I was able to download the file without issue.

I also tested opening the .m4b file on my Mac and it played fine.

[LeoKlaus]

I've disabled the playability check in a TestFlight release. You can download it here: https://testflight.apple.com/join/oSAekRD5

Could you try if it's possible to play the file on that release?

[nathang21]

Looks like that did the trick whatever you changed.

[LeoKlaus]

Looks like that did the trick whatever you changed.

When loading a file, plappa checks whether the URL leads to a playable file. To do this, I used the built in methods of Apples AVFoundation:

let asset = AVURLAsset(url: fileURL, options: ["AVURLAssetHTTPHeaderFieldsKey": headers])

guard try await asset.load(.isPlayable) else {
    SoundHandler.logger.error("Tried to play an invalid asset with URL: \(asset.url, privacy: .public)")
    SoundHandler.logger.info("""
         Additional information:
         Title: \(audiobook.title, privacy: .public)
         ID: \(audiobook.id, privacy: .public)
         Number of chapters: \(audiobook.chapters.count, privacy: .public)
         """)
    stop()

    throw PlaybackError.invalidFileURL("URL \(asset.url) does not lead to a playable file.")
}

The idea here is to throw an error like the one you've seen when a file is not playable instead of just doing nothing.

I have no idea what would cause this check to fail in your case, as the file clearly is playable. For the TestFlight release, I've just commented out the entire check, but that's not really a solution. If someone were to play an actual unplayable file, they'd get no feedback at all without this.

[nathang21]

Thank for you explaining, and for providing a workaround for me in the mean time.

Agreed that that is concerning, let me know if there is anything else I can do to help debug/test a permanent fix.

---

If it's helpful, i think I know the trigger of this issue. I am using Readarr --> Audiobookshelf, and this particular book had invalid metadata for the 'book' attribute causing ABS to show the wrong title and cover image. I was trying to adjust the priority of different metadata sources in ABS,as well as fix/override it in either Readarr & ABS. Eventually I got it to work after a few attempts of my changes getting overwritten. Since then (I believe the timing corresponds roughly the same) I was unable to continue to book.

[MadWalnut]

I experienced this bug in a different scenario (but also using ABS and a downloaded book). I was listening via CarPlay when I restarted the car's engine and therefore also CarPlay. After the restart the error appeared (actually on CarPlay it does not show, but I pulled over and then saw it in the app). There was no metadata change during this time and I do not use Readarr at all.

[LeoKlaus]

I experienced this bug in a different scenario (but also using ABS and a downloaded book). I was listening via CarPlay when I restarted the car's engine and therefore also CarPlay. After the restart the error appeared (actually on CarPlay it does not show, but I pulled over and then saw it in the app). There was no metadata change during this time and I do not use Readarr at all.

Thank you for reporting this. I've just submitted an update to Apple, it should release to the AppStore in the coming days. Until then, you can use the TestFlight version linked above to be able to listen to your book.

[LeoKlaus]

The update is now live on the AppStore as well. I'll close this now.

If playback for the same file still fails, please reopen.