In version 0.10-beta for android, the following happens when I press play on a podcast episode:
[2025-07-22 13:16:37.568] INFO: [SocketAuthority] Socket Connected to /socket.io -RO1jaaerLjbMu0LAAAN
[2025-07-22 13:16:46.699] ERROR: [SessionController] Unable to find audio track with index=0
[2025-07-22 13:16:46.718] ERROR: [SessionController] Unable to find audio track with index=0
[2025-07-22 13:16:47.807] ERROR: [SessionController] Unable to find audio track with index=0
[2025-07-22 13:16:49.896] ERROR: [SessionController] Unable to find audio track with index=0
[2025-07-22 13:16:49.989] INFO: [PlaybackSessionManager] startSession: Closing open session "Make Fun Of Them, Pt. 2" for user "administrator" (Device: Pixel 7a SDK 35 / v0.10.0-beta)
[2025-07-22 13:16:49.992] INFO: [STREAM] START STREAM - Num Segments: 304
[2025-07-22 13:16:50.002] INFO: [INFO] FFMPEG transcoding started with command: ffmpeg -seek_timestamp 1 -f concat -safe 0 -i /metadata/streams/f1412786-3d77-4848-bb18-4668fbc45e1d/files.txt -y -loglevel error -map 0:a -c:a copy -f hls -copyts -avoid_negative_ts make_non_negative -max_delay 5000000 -max_muxing_queue_size 2048 -hls_time 6 -hls_segment_type mpegts -start_number 0 -hls_playlist_type vod -hls_list_size 0 -hls_allow_cache 0 -hls_segment_filename /metadata/streams/f1412786-3d77-4848-bb18-4668fbc45e1d/output-%d.ts /metadata/streams/f1412786-3d77-4848-bb18-4668fbc45e1d/final-output.m3u8
[2025-07-22 13:16:50.003] INFO:
[2025-07-22 13:16:50.439] FATAL: [Server] Unhandled rejection: TypeError: Cannot read properties of null (reading 'path')
at PublicRouter.getTrack (/app/server/controllers/SessionController.js:307:88)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
promise: Promise {
<rejected> TypeError: Cannot read properties of null (reading 'path')
at PublicRouter.getTrack (/app/server/controllers/SessionController.js:307:88)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
}
This crashes the server and I need to restart the podman container.
Steps to Reproduce the Issue
Go to a podcast
Click play
What was Expected?
The server shouldn't crash and the episode should play.
Phone Model
Pixel 7a
Phone OS
Android 15
Audiobookshelf App Version
Android App - 0.10.0
Installation Source
Google Play Store
Additional Notes
The server is running v2.26.2 as a container on podman on MacOs
Originally created by @smithmd on GitHub (Jul 22, 2025).
### I have verified that the [bug is not already awaiting release](https://github.com/advplyr/audiobookshelf-app/issues?q=is%3Aissue%20label%3A%22awaiting%20release%22)
Yes
### What was the Problem?
In version 0.10-beta for android, the following happens when I press play on a podcast episode:
```
[2025-07-22 13:16:37.568] INFO: [SocketAuthority] Socket Connected to /socket.io -RO1jaaerLjbMu0LAAAN
[2025-07-22 13:16:46.699] ERROR: [SessionController] Unable to find audio track with index=0
[2025-07-22 13:16:46.718] ERROR: [SessionController] Unable to find audio track with index=0
[2025-07-22 13:16:47.807] ERROR: [SessionController] Unable to find audio track with index=0
[2025-07-22 13:16:49.896] ERROR: [SessionController] Unable to find audio track with index=0
[2025-07-22 13:16:49.989] INFO: [PlaybackSessionManager] startSession: Closing open session "Make Fun Of Them, Pt. 2" for user "administrator" (Device: Pixel 7a SDK 35 / v0.10.0-beta)
[2025-07-22 13:16:49.992] INFO: [STREAM] START STREAM - Num Segments: 304
[2025-07-22 13:16:50.002] INFO: [INFO] FFMPEG transcoding started with command: ffmpeg -seek_timestamp 1 -f concat -safe 0 -i /metadata/streams/f1412786-3d77-4848-bb18-4668fbc45e1d/files.txt -y -loglevel error -map 0:a -c:a copy -f hls -copyts -avoid_negative_ts make_non_negative -max_delay 5000000 -max_muxing_queue_size 2048 -hls_time 6 -hls_segment_type mpegts -start_number 0 -hls_playlist_type vod -hls_list_size 0 -hls_allow_cache 0 -hls_segment_filename /metadata/streams/f1412786-3d77-4848-bb18-4668fbc45e1d/output-%d.ts /metadata/streams/f1412786-3d77-4848-bb18-4668fbc45e1d/final-output.m3u8
[2025-07-22 13:16:50.003] INFO:
[2025-07-22 13:16:50.439] FATAL: [Server] Unhandled rejection: TypeError: Cannot read properties of null (reading 'path')
at PublicRouter.getTrack (/app/server/controllers/SessionController.js:307:88)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
promise: Promise {
<rejected> TypeError: Cannot read properties of null (reading 'path')
at PublicRouter.getTrack (/app/server/controllers/SessionController.js:307:88)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
}
```
This crashes the server and I need to restart the podman container.
### Steps to Reproduce the Issue
1. Go to a podcast
2. Click play
### What was Expected?
The server shouldn't crash and the episode should play.
### Phone Model
Pixel 7a
### Phone OS
Android 15
### Audiobookshelf App Version
Android App - 0.10.0
### Installation Source
Google Play Store
### Additional Notes
The server is running v2.26.2 as a container on podman on MacOs
adam
added the bug label 2026-04-24 23:55:22 +02:00
Is this reproducible every time? Is it reproducible with other podcasts?
Can you switch to debug logs so we can see this log
Logger.debug(`[SessionController] Serving audio track ${audioTrack.index} for session "${req.params.id}" belonging to user "${user.username}"`)
It also seems that the podcast episode is not able to get direct played on your device, so it is falling back to transcoding. Can you share the format and codec of the audio file?
@advplyr commented on GitHub (Jul 22, 2025):
The audio track is being found on the session but it doesn't have a metadata object. I'm not sure how that could happen.
https://github.com/advplyr/audiobookshelf/blob/878f0787ba39ff82f9d5b6b5b5bb397ec667f010/server/controllers/SessionController.js#L291-L310
Is this reproducible every time? Is it reproducible with other podcasts?
Can you switch to debug logs so we can see this log
```
Logger.debug(`[SessionController] Serving audio track ${audioTrack.index} for session "${req.params.id}" belonging to user "${user.username}"`)
```
It also seems that the podcast episode is not able to get direct played on your device, so it is falling back to transcoding. Can you share the format and codec of the audio file?
yea, it seems to happen with every podcast episode. Only streaming ones. If I download the episode first it's fine. Also the web player works fine.
@smithmd commented on GitHub (Jul 22, 2025):
yea, it seems to happen with every podcast episode. Only streaming ones. If I download the episode first it's fine. Also the web player works fine.
Can you share the file format and codec of the audio file you are trying to play? It is uncommon that a podcast episode cannot be direct played since they are typically mp3 or mp4.
@advplyr commented on GitHub (Jul 22, 2025):
On the logs page
<img width="1390" height="274" alt="Image" src="https://github.com/user-attachments/assets/7bceab92-04cb-462b-8e3b-c1f98e7208f6" />
Can you share the file format and codec of the audio file you are trying to play? It is uncommon that a podcast episode cannot be direct played since they are typically mp3 or mp4.
no, I've never touched the database directly. The drive I have connected gets removed by podman every once in a while somehow. I've been trying to track that down before filing a bug report on it. I'm guessing it got corrupted when that happened.
I keep my audiobooks/podcasts on a USB drive and podman and docker both disconnected that physical drive on the host, so I suspect something is weird with the container. None of my other containers do that and I have lots of things running on USB drives.
@smithmd commented on GitHub (Jul 22, 2025):
no, I've never touched the database directly. The drive I have connected gets removed by podman every once in a while somehow. I've been trying to track that down before filing a bug report on it. I'm guessing it got corrupted when that happened.
I keep my audiobooks/podcasts on a USB drive and podman and docker both disconnected that physical drive on the host, so I suspect something is weird with the container. None of my other containers do that and I have lots of things running on USB drives.
I don't see how an audio file could get saved in the db that doesn't have a metadata object on it.
If you are comfortable opening up the database the podcastEpisodes table has an audioFile column that has the audio file objects.
If you can look at the podcast episode that failed to play and see what the audio file object looks like that could be helpful
@advplyr commented on GitHub (Jul 22, 2025):
I don't see how an audio file could get saved in the db that doesn't have a metadata object on it.
If you are comfortable opening up the database the podcastEpisodes table has an `audioFile` column that has the audio file objects.
If you can look at the podcast episode that failed to play and see what the audio file object looks like that could be helpful
<img width="1808" height="741" alt="Image" src="https://github.com/user-attachments/assets/9e0e7f64-eab3-4d71-ad9b-7c17175e9617" />
I see the issue now. The index for that episode is null instead of 1.
How are you adding episodes to your server? Are you downloading with Abs or are you scanning in the episodes from the file system?
@advplyr commented on GitHub (Jul 22, 2025):
I see the issue now. The `index` for that episode is `null` instead of `1`.
How are you adding episodes to your server? Are you downloading with Abs or are you scanning in the episodes from the file system?
The timestamp on that episode shows July 9th. Do you know what version of the server you used to download the audio file?
@advplyr commented on GitHub (Jul 22, 2025):
The timestamp on that episode shows July 9th. Do you know what version of the server you used to download the audio file?
In server v2.21.0 a bug was fixed where index was getting set to null for episodes getting scanned in from the file system. So it is possible to have episodes with null.
In the latest android app, v0.10.0-beta, the audio player was updated to use the new API endpoint for streaming.
One last thing, can you try playing that audio file in the web client again and share the logs? Mainly looking for this one:
[SessionController] Serving audio track 1 for session "8c8fb502-1cf4-4d41-b40b-aa0013a7cea5" belonging to user
to see the audio track index
@advplyr commented on GitHub (Jul 22, 2025):
In server v2.21.0 a bug was fixed where `index` was getting set to `null` for episodes getting scanned in from the file system. So it is possible to have episodes with `null`.
In the latest android app, `v0.10.0-beta`, the audio player was updated to use the new API endpoint for streaming.
One last thing, can you try playing that audio file in the web client again and share the logs? Mainly looking for this one:
```
[SessionController] Serving audio track 1 for session "8c8fb502-1cf4-4d41-b40b-aa0013a7cea5" belonging to user
```
to see the audio track index
Thanks for helping to track this down. It is actually 2 separate bugs. This will be fixed in the next server release or the next android app release depending on which comes first.
@advplyr commented on GitHub (Jul 22, 2025):
Thanks for helping to track this down. It is actually 2 separate bugs. This will be fixed in the next server release or the next android app release depending on which comes first.
https://github.com/advplyr/audiobookshelf/pull/4520
https://github.com/advplyr/audiobookshelf-app/pull/1636
@alxgarci commented on GitHub (Jul 23, 2025):
Awesome thank you! Meanwhile I downgraded to previous version and everything is working again (i'm on Android), just for if anyone is looking here https://github.com/advplyr/audiobookshelf-app/releases/tag/v0.9.81-beta
@bjhiltbrand commented on GitHub (Aug 2, 2025):
links to other bug reports (same bug I think) that will be covered by this update:
[https://github.com/advplyr/audiobookshelf/issues/4555#issuecomment-3146654885](https://github.com/advplyr/audiobookshelf/issues/4555#issuecomment-3146654885)
[https://github.com/advplyr/audiobookshelf-app/issues/1642](https://github.com/advplyr/audiobookshelf-app/issues/1642)
I'm still seeing this issue on version 0.10.0-beta of the Android client, and version 2.26.3 of the Docker container.
@bjhiltbrand commented on GitHub (Aug 2, 2025):
I'm still seeing this issue on version 0.10.0-beta of the Android client, and version 2.26.3 of the Docker container.
@advplyr commented on GitHub (Aug 3, 2025):
Oh actually the server crash was fixed in v2.26.3 https://github.com/advplyr/audiobookshelf/releases/tag/v2.26.3
I just updated the server, but the container is still crashing.
I had a video up, but I didn't want to expose my server name. Let me know if you want to see it and I can send you a link.
@bjhiltbrand commented on GitHub (Aug 3, 2025):
I just updated the server, but the container is still crashing.
I had a video up, but I didn't want to expose my server name. Let me know if you want to see it and I can send you a link.
@advplyr I also had someone contact me trough Discord with this issue (non podcast). I will contact them and ask if the issue is fixed with v2.27.0, but from the changelogs it doesn't look like it
@Vito0912 commented on GitHub (Aug 3, 2025):
@advplyr I also had someone contact me trough Discord with this issue (non podcast). I will contact them and ask if the issue is fixed with v2.27.0, but from the changelogs it doesn't look like it
@github-actions[bot] commented on GitHub (Sep 4, 2025):
Fixed in [v0.10.1-beta](https://github.com/advplyr/audiobookshelf-app/releases/tag/v0.10.1-beta).
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @smithmd on GitHub (Jul 22, 2025).
I have verified that the bug is not already awaiting release
Yes
What was the Problem?
In version 0.10-beta for android, the following happens when I press play on a podcast episode:
This crashes the server and I need to restart the podman container.
Steps to Reproduce the Issue
What was Expected?
The server shouldn't crash and the episode should play.
Phone Model
Pixel 7a
Phone OS
Android 15
Audiobookshelf App Version
Android App - 0.10.0
Installation Source
Google Play Store
Additional Notes
The server is running v2.26.2 as a container on podman on MacOs
@advplyr commented on GitHub (Jul 22, 2025):
The audio track is being found on the session but it doesn't have a metadata object. I'm not sure how that could happen.
https://github.com/advplyr/audiobookshelf/blob/878f0787ba39ff82f9d5b6b5b5bb397ec667f010/server/controllers/SessionController.js#L291-L310
Is this reproducible every time? Is it reproducible with other podcasts?
Can you switch to debug logs so we can see this log
It also seems that the podcast episode is not able to get direct played on your device, so it is falling back to transcoding. Can you share the format and codec of the audio file?
@smithmd commented on GitHub (Jul 22, 2025):
yea, it seems to happen with every podcast episode. Only streaming ones. If I download the episode first it's fine. Also the web player works fine.
@smithmd commented on GitHub (Jul 22, 2025):
how do I turn on debug logs?
@advplyr commented on GitHub (Jul 22, 2025):
On the logs page
Can you share the file format and codec of the audio file you are trying to play? It is uncommon that a podcast episode cannot be direct played since they are typically mp3 or mp4.
@smithmd commented on GitHub (Jul 22, 2025):
actually, if I delete the episode and redownload it, it will play. Is there a way to rebuild my metadata?
@advplyr commented on GitHub (Jul 22, 2025):
It seems like you may have made manual updates to the database that is causing the issue
@smithmd commented on GitHub (Jul 22, 2025):
no, I've never touched the database directly. The drive I have connected gets removed by podman every once in a while somehow. I've been trying to track that down before filing a bug report on it. I'm guessing it got corrupted when that happened.
I keep my audiobooks/podcasts on a USB drive and podman and docker both disconnected that physical drive on the host, so I suspect something is weird with the container. None of my other containers do that and I have lots of things running on USB drives.
@advplyr commented on GitHub (Jul 22, 2025):
I don't see how an audio file could get saved in the db that doesn't have a metadata object on it.
If you are comfortable opening up the database the podcastEpisodes table has an
audioFilecolumn that has the audio file objects.If you can look at the podcast episode that failed to play and see what the audio file object looks like that could be helpful
@smithmd commented on GitHub (Jul 22, 2025):
@advplyr commented on GitHub (Jul 22, 2025):
Is that the one you re-downloaded or is that specific episode still causing the crash?
@smithmd commented on GitHub (Jul 22, 2025):
that's the one that's still causing a crash. Here's the one I re-downloaded:
@advplyr commented on GitHub (Jul 22, 2025):
Can you share the logs playing that one you said is crashing now that you have enabled debug logs
@smithmd commented on GitHub (Jul 22, 2025):
Here is the failing one trying to play from the android app:
@advplyr commented on GitHub (Jul 22, 2025):
I see the issue now. The
indexfor that episode isnullinstead of1.How are you adding episodes to your server? Are you downloading with Abs or are you scanning in the episodes from the file system?
@smithmd commented on GitHub (Jul 22, 2025):
I'm downloading them through ABS, usually using the web interface or the cron jobs.
@advplyr commented on GitHub (Jul 22, 2025):
The timestamp on that episode shows July 9th. Do you know what version of the server you used to download the audio file?
@smithmd commented on GitHub (Jul 22, 2025):
I'm really not sure. If the scan logs
lastScanVersionis the server version, it says 2.25.1@advplyr commented on GitHub (Jul 22, 2025):
In server v2.21.0 a bug was fixed where
indexwas getting set tonullfor episodes getting scanned in from the file system. So it is possible to have episodes withnull.In the latest android app,
v0.10.0-beta, the audio player was updated to use the new API endpoint for streaming.One last thing, can you try playing that audio file in the web client again and share the logs? Mainly looking for this one:
to see the audio track index
@smithmd commented on GitHub (Jul 22, 2025):
Here's the one that was failing. I don't see that line.
@advplyr commented on GitHub (Jul 22, 2025):
Thanks for helping to track this down. It is actually 2 separate bugs. This will be fixed in the next server release or the next android app release depending on which comes first.
https://github.com/advplyr/audiobookshelf/pull/4520
https://github.com/advplyr/audiobookshelf-app/pull/1636
@smithmd commented on GitHub (Jul 22, 2025):
awesome, thank you!
@alxgarci commented on GitHub (Jul 23, 2025):
Awesome thank you! Meanwhile I downgraded to previous version and everything is working again (i'm on Android), just for if anyone is looking here https://github.com/advplyr/audiobookshelf-app/releases/tag/v0.9.81-beta
@bjhiltbrand commented on GitHub (Aug 2, 2025):
links to other bug reports (same bug I think) that will be covered by this update:
https://github.com/advplyr/audiobookshelf/issues/4555#issuecomment-3146654885
https://github.com/advplyr/audiobookshelf-app/issues/1642
@bjhiltbrand commented on GitHub (Aug 2, 2025):
I'm still seeing this issue on version 0.10.0-beta of the Android client, and version 2.26.3 of the Docker container.
@advplyr commented on GitHub (Aug 3, 2025):
Server v2.17.0 was just released https://github.com/advplyr/audiobookshelf/releases/tag/v2.27.0
@advplyr commented on GitHub (Aug 3, 2025):
Oh actually the server crash was fixed in v2.26.3 https://github.com/advplyr/audiobookshelf/releases/tag/v2.26.3
@bjhiltbrand commented on GitHub (Aug 3, 2025):
I just updated the server, but the container is still crashing.
I had a video up, but I didn't want to expose my server name. Let me know if you want to see it and I can send you a link.
@Vito0912 commented on GitHub (Aug 3, 2025):
@advplyr I also had someone contact me trough Discord with this issue (non podcast). I will contact them and ask if the issue is fixed with v2.27.0, but from the changelogs it doesn't look like it
@github-actions[bot] commented on GitHub (Sep 4, 2025):
Fixed in v0.10.1-beta.