[Bug]: Phone/battery gets really hot #1056

New Issue

Open

opened 2026-04-24 23:47:01 +02:00 by adam · 23 comments

adam commented 2026-04-24 23:47:01 +02:00

Owner

Copy Link

Copy Source

Originally created by @mdeeter on GitHub (Oct 7, 2024).

What was the Problem?

I've been listening to a book while the phone is locked sitting on the couch. After about an hour, I went to check something on my phone and when I picked it up, my phone was extremely hot (like hotter than a typical magsafe-charging temperature).

I had noticed it occurred this morning as well, but assumed it was a fluke, I woke up with 95% battery... chilling on the couch listening to a book while working on the computer... after a couple of hours, I picked up my phone and it was super-hot... and the battery was down to less than 70%.

Steps to Reproduce the Issue

Play book while phone locked.

What was Expected?

Not to make the phone hot or drain battery.

Phone Model

16

Phone OS

18.0.1

Audiobookshelf App Version

iOS App - 0.9.76

Installation Source

Testflight

Additional Notes

No response

Originally created by @mdeeter on GitHub (Oct 7, 2024). ### What was the Problem? I've been listening to a book while the phone is locked sitting on the couch. After about an hour, I went to check something on my phone and when I picked it up, my phone was extremely hot (like hotter than a typical magsafe-charging temperature). I had noticed it occurred this morning as well, but assumed it was a fluke, I woke up with 95% battery... chilling on the couch listening to a book while working on the computer... after a couple of hours, I picked up my phone and it was super-hot... and the battery was down to less than 70%. ### Steps to Reproduce the Issue Play book while phone locked. ### What was Expected? Not to make the phone hot or drain battery. ### Phone Model 16 ### Phone OS 18.0.1 ### Audiobookshelf App Version iOS App - 0.9.76 ### Installation Source Testflight ### Additional Notes _No response_

adam added the bugiOS labels 2026-04-24 23:47:01 +02:00

adam commented 2026-04-24 23:47:02 +02:00

Author

Owner

Copy Link

Copy Source

@mdeeter commented on GitHub (Oct 7, 2024):

In both occurrences, I was at home on 5Ghz wifi. Iirc, I was listening to a book that was downloaded... but not disconnected from the server.

@mdeeter commented on GitHub (Oct 7, 2024): In both occurrences, I was at home on 5Ghz wifi. Iirc, I was listening to a book that was downloaded... but not disconnected from the server.

adam commented 2026-04-24 23:47:02 +02:00

Author

Owner

Copy Link

Copy Source

@aidan-gibson commented on GitHub (Oct 12, 2024):

Seconded. This app uses an obsene amount of power. Pardon my french, but what the fuck

@aidan-gibson commented on GitHub (Oct 12, 2024): Seconded. This app uses an obsene amount of power. Pardon my french, but what the fuck

adam commented 2026-04-24 23:47:03 +02:00

Author

Owner

Copy Link

Copy Source

@aidan-gibson commented on GitHub (Oct 12, 2024):

Receipts:

@aidan-gibson commented on GitHub (Oct 12, 2024): Receipts: 

adam commented 2026-04-24 23:47:05 +02:00

Author

Owner

Copy Link

Copy Source

@drabgail commented on GitHub (Oct 14, 2024):

Same here. iPhone 15 Pro. I am streaming a book on wifi from a server on the same network, last two night have looked like this.

4hr playback, 76% battery drain (down to zero)
2hr playback. 45% battery drain (down to zero)

Phone Model
15 Pro
Phone OS
18.1 beta
Audiobookshelf App Version
iOS App - 0.9.76
Installation Source
Testflight

@drabgail commented on GitHub (Oct 14, 2024): Same here. iPhone 15 Pro. I am streaming a book on wifi from a server on the same network, last two night have looked like this. 4hr playback, 76% battery drain (down to zero) 2hr playback. 45% battery drain (down to zero) **Phone Model** 15 Pro **Phone OS** 18.1 beta **Audiobookshelf App Version** iOS App - 0.9.76 **Installation Source** Testflight 

adam commented 2026-04-24 23:47:06 +02:00

Author

Owner

Copy Link

Copy Source

@timshannon commented on GitHub (Dec 13, 2024):

Apologies for adding another "me too" post but I'm on android and also seeing the issue, so I thought I'd include my data.

Android 14

@timshannon commented on GitHub (Dec 13, 2024): Apologies for adding another "me too" post but I'm on android and also seeing the issue, so I thought I'd include my data. Android 14 

adam commented 2026-04-24 23:47:07 +02:00

Author

Owner

Copy Link

Copy Source

@holly-hacker commented on GitHub (Apr 14, 2025):

This still seems to be an issue, with the app using 50-60% of my battery over 4 hours, requiring me to bring a battery bank if I want to use audiobookshelf.

Has any research happened on this field? It's really quite annoying.

@holly-hacker commented on GitHub (Apr 14, 2025): This still seems to be an issue, with the app using 50-60% of my battery over 4 hours, requiring me to bring a battery bank if I want to use audiobookshelf. Has any research happened on this field? It's really quite annoying. 

adam commented 2026-04-24 23:47:07 +02:00

Author

Owner

Copy Link

Copy Source

@drabgail commented on GitHub (Apr 14, 2025):

I solved this problem and it turned out to be a config issue on my server. The server uses a websocket connection but I hadn't enabled websockets in my reverse proxy or in the cloudflare tunnel.

I debugged first by exposing my server internally on my lan and connecting directly, I didn't see the battery drain issue. I then went through my reverse proxy locally and saw the issue, enabled websocket there and it went away, then the same test and solution on cloudflare.

@drabgail commented on GitHub (Apr 14, 2025): I solved this problem and it turned out to be a config issue on my server. The server uses a websocket connection but I hadn't enabled websockets in my reverse proxy or in the cloudflare tunnel. I debugged first by exposing my server internally on my lan and connecting directly, I didn't see the battery drain issue. I then went through my reverse proxy locally and saw the issue, enabled websocket there and it went away, then the same test and solution on cloudflare.

adam commented 2026-04-24 23:47:09 +02:00

Author

Owner

Copy Link

Copy Source

@mdeeter commented on GitHub (Apr 14, 2025):

I wouldn't suggest that that's the only cause of this issue. My server with reverse proxy has always been set up to support websockets. I think the issue is related to the app losing that connection and spinning out of control trying trying to get reconnected (or something of that sort). Imo, it'd be nice if it timed out and showed an error or warning instead of just eating away at the battery.

I've had the battery drain occur randomly a few times over the past several months. It's not often, but annoying when it happens (iOS).

@mdeeter commented on GitHub (Apr 14, 2025): I wouldn't suggest that that's the only cause of this issue. My server with reverse proxy has always been set up to support websockets. I think the issue is related to the app losing that connection and spinning out of control trying trying to get reconnected (or something of that sort). Imo, it'd be nice if it timed out and showed an error or warning instead of just eating away at the battery. I've had the battery drain occur randomly a few times over the past several months. It's not often, but annoying when it happens (iOS).

adam commented 2026-04-24 23:47:09 +02:00

Author

Owner

Copy Link

Copy Source

@advplyr commented on GitHub (Apr 14, 2025):

The battery drain for iOS and Android will be completely different. There is a known battery drain issue for Android that has been identified. So far there has been no iOS battery drain issue confirmed.

@advplyr commented on GitHub (Apr 14, 2025): The battery drain for iOS and Android will be completely different. There is a known battery drain issue for Android that has been identified. So far there has been no iOS battery drain issue confirmed.

adam commented 2026-04-24 23:47:10 +02:00

Author

Owner

Copy Link

Copy Source

@timshannon commented on GitHub (Apr 14, 2025):

FWIW, here's my nginx websocket config, which as far as I can see is working fine in a browser. Not sure about the android app, but I assume it is there too.

server {
        listen   80;

        server_name mywebsite.com;
        return 301 https://$host$request_uri$is_args$args;
}

server {

        listen 443;

        server_name mywebsite.com;
        ssl on;
        ssl_certificate /etc/ssl/certs/cert;
        ssl_certificate_key /etc/ssl/certs/key;

        ssl_session_timeout 5m;

        # Configure SSL with forward secrecy and other goodies.
        # Ciphersuite taken from https://wiki.mozilla.org/Security/Server_Side_TLS
        # "Intermediate compatibility" as of 2015-06-04
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
        ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA;
        ssl_prefer_server_ciphers on;

        # HSTS prevents attackers from tricking you into connecting via HTTP in the
        # future, but if you actually intend to access the server via non-SSL in the
        # future then you should probably delete this line.
        add_header Strict-Transport-Security max-age=31536000;

        location / {
                proxy_pass http://127.0.0.1:13378;
                proxy_set_header X-Real-IP         $remote_addr;
                proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto https;
                proxy_set_header X-Forwarded-Host  $http_host;
                proxy_set_header Host              $http_host;
                proxy_max_temp_file_size           0;
                proxy_redirect                     http:// https://;

                # Forward WebSocket.
                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection $connection_upgrade;
        }

}

@timshannon commented on GitHub (Apr 14, 2025): FWIW, here's my nginx websocket config, which as far as I can see is working fine in a browser. Not sure about the android app, but I assume it is there too. ``` server { listen 80; server_name mywebsite.com; return 301 https://$host$request_uri$is_args$args; } server { listen 443; server_name mywebsite.com; ssl on; ssl_certificate /etc/ssl/certs/cert; ssl_certificate_key /etc/ssl/certs/key; ssl_session_timeout 5m; # Configure SSL with forward secrecy and other goodies. # Ciphersuite taken from https://wiki.mozilla.org/Security/Server_Side_TLS # "Intermediate compatibility" as of 2015-06-04 ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA; ssl_prefer_server_ciphers on; # HSTS prevents attackers from tricking you into connecting via HTTP in the # future, but if you actually intend to access the server via non-SSL in the # future then you should probably delete this line. add_header Strict-Transport-Security max-age=31536000; location / { proxy_pass http://127.0.0.1:13378; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto https; proxy_set_header X-Forwarded-Host $http_host; proxy_set_header Host $http_host; proxy_max_temp_file_size 0; proxy_redirect http:// https://; # Forward WebSocket. proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $connection_upgrade; } } ```

adam commented 2026-04-24 23:47:11 +02:00

Author

Owner

Copy Link

Copy Source

@advplyr commented on GitHub (Apr 14, 2025):

I can't see how the websocket connection would affect battery drain

@advplyr commented on GitHub (Apr 14, 2025): I can't see how the websocket connection would affect battery drain

adam commented 2026-04-24 23:47:12 +02:00

Author

Owner

Copy Link

Copy Source

@drabgail commented on GitHub (Apr 14, 2025):

@timshannon you left your domain on the ssl part of the config

@drabgail commented on GitHub (Apr 14, 2025): @timshannon you left your domain on the ssl part of the config

adam commented 2026-04-24 23:47:12 +02:00

Author

Owner

Copy Link

Copy Source

@timshannon commented on GitHub (Apr 14, 2025):

@timshannon you left your domain on the ssl part of the config

I appreciate that. I quick glanced and thought I grabbed them all.

@timshannon commented on GitHub (Apr 14, 2025): > [@timshannon](https://github.com/timshannon) you left your domain on the ssl part of the config I appreciate that. I quick glanced and thought I grabbed them all.

adam commented 2026-04-24 23:47:13 +02:00

Author

Owner

Copy Link

Copy Source

@drabgail commented on GitHub (Apr 14, 2025):

I can't see how the websocket connection would affect battery drain

Surely this activity will drain the battery. Same server with websocket enabled on the left through npm and same server on another domain through the same npm on the right but with websocket disabled. This is about 40 seconds of requests..

@drabgail commented on GitHub (Apr 14, 2025): > I can't see how the websocket connection would affect battery drain Surely this activity will drain the battery. Same server with websocket enabled on the left through npm and same server on another domain through the same npm on the right but with websocket disabled. This is about 40 seconds of requests.. 

adam commented 2026-04-24 23:47:14 +02:00

Author

Owner

Copy Link

Copy Source

@drabgail commented on GitHub (Apr 14, 2025):

@timshannon you left your domain on the ssl part of the config

I appreciate that. I quick glanced and thought I grabbed them all.

No problem. If you want to check your websocket connection is working open your instance in chrome and check it looks like the left one of my example above.

@drabgail commented on GitHub (Apr 14, 2025): > > [@timshannon](https://github.com/timshannon) you left your domain on the ssl part of the config > > I appreciate that. I quick glanced and thought I grabbed them all. No problem. If you want to check your websocket connection is working open your instance in chrome and check it looks like the left one of my example above.

adam commented 2026-04-24 23:47:15 +02:00

Author

Owner

Copy Link

Copy Source

@advplyr commented on GitHub (Apr 14, 2025):

I suspected the retry attempts could have some battery drain but I was offsetting that with when the websocket is connected you are getting events from the server.

On the web app you will get a red toast message that isn't dismissible if web sockets aren't connected, so you can't miss it if using the web client.
On the mobile app you will see the connection status icon change in the toolbar and when clicking on that it will tell you that the websocket isn't connected.

After the 4th reconnection attempt the reconnection attempts will happen every 5 to 10 seconds and only while the app is in the foreground.

@advplyr commented on GitHub (Apr 14, 2025): I suspected the retry attempts could have some battery drain but I was offsetting that with when the websocket is connected you are getting events from the server. On the web app you will get a red toast message that isn't dismissible if web sockets aren't connected, so you can't miss it if using the web client. On the mobile app you will see the connection status icon change in the toolbar and when clicking on that it will tell you that the websocket isn't connected. After the 4th reconnection attempt the reconnection attempts will happen every 5 to 10 seconds and only while the app is in the foreground.

adam commented 2026-04-24 23:47:15 +02:00

Author

Owner

Copy Link

Copy Source

@holly-hacker commented on GitHub (Apr 15, 2025):

I'd like to add to this issue that there doesn't have to be any streamed audio for the battery usage issue to occur, as I decided not to plug in my phone this night which caused it to die in the middle of the night (which in turn caused my alarm to not go off 😅)
Android's battery usage shows that Audiobookshelf was the top battery user during the entire night, being between 63% and 83% of all battery usage.

@holly-hacker commented on GitHub (Apr 15, 2025): I'd like to add to this issue that there doesn't have to be any streamed audio for the battery usage issue to occur, as I decided not to plug in my phone this night which caused it to die in the middle of the night (which in turn caused my alarm to not go off 😅) Android's battery usage shows that Audiobookshelf was the top battery user during the entire night, being between 63% and 83% of all battery usage.

adam commented 2026-04-24 23:47:16 +02:00

Author

Owner

Copy Link

Copy Source

@camo200sx commented on GitHub (Jun 12, 2025):

Yea, holy moly. Unfortunately I'm going to uninstall for now. This thing can chew battery super fast even when not in use. Bummer.

@camo200sx commented on GitHub (Jun 12, 2025): Yea, holy moly. Unfortunately I'm going to uninstall for now. This thing can chew battery super fast even when not in use. Bummer.

adam commented 2026-04-24 23:47:17 +02:00

Author

Owner

Copy Link

Copy Source

@holly-hacker commented on GitHub (Jun 12, 2025):

It's a bit off topic, but I'd like to add that as a workaround people can temporarily use the web UI or the third-party lissen app for Android. I've found Lissen to also be more stable than the official Android client.

@holly-hacker commented on GitHub (Jun 12, 2025): It's a bit off topic, but I'd like to add that as a workaround people can temporarily use the web UI or the third-party [lissen](https://github.com/GrakovNe/lissen-android) app for Android. I've found Lissen to also be more stable than the official Android client.

adam commented 2026-04-24 23:47:18 +02:00

Author

Owner

Copy Link

Copy Source

@MichaelRPowell commented on GitHub (Dec 5, 2025):

Just wanted to add my partner is experiencing this on iOS. Their phone is getting very hot. It is happening multiple times a week, even multiple times in a day (she reads a lot). Let me know what info I can provide to assist identifying this bug.

She says she knows when it will happen. She hits plays, it shows 0:00:00 as the current position, and loses her spot (resets her progress). Then when she finds her spot and continues it gets hot after a bit.

@MichaelRPowell commented on GitHub (Dec 5, 2025): Just wanted to add my partner is experiencing this on iOS. Their phone is getting very hot. It is happening multiple times a week, even multiple times in a day (she reads a lot). Let me know what info I can provide to assist identifying this bug. She says she knows when it will happen. She hits plays, it shows 0:00:00 as the current position, and loses her spot (resets her progress). Then when she finds her spot and continues it gets hot after a bit.

adam commented 2026-04-24 23:47:18 +02:00

Author

Owner

Copy Link

Copy Source

@holly-hacker commented on GitHub (Dec 5, 2025):

@advplyr I noticed you added the iOS tag, but I'd like to mention that this occurs on Android too.

@holly-hacker commented on GitHub (Dec 5, 2025): @advplyr I noticed you added the iOS tag, but I'd like to mention that this occurs on Android too.

adam commented 2026-04-24 23:47:19 +02:00

Author

Owner

Copy Link

Copy Source

@advplyr commented on GitHub (Dec 5, 2025):

Just wanted to add my partner is experiencing this on iOS. Their phone is getting very hot. It is happening multiple times a week, even multiple times in a day (she reads a lot). Let me know what info I can provide to assist identifying this bug.

She says she knows when it will happen. She hits plays, it shows 0:00:00 as the current position, and loses her spot (resets her progress). Then when she finds her spot and continues it gets hot after a bit.

Since she can reproduce this consistently, can you give more specific steps that she takes to reproduce it. Does this happen on a specific audiobook or is there anything different about the audiobooks it happens to that can be identified?
A few things to look into:

1. Is the audiobook downloaded? If not, when the audio player is expanded to full screen there is small text at the top that indicates whether the audiobook is direct playing or transcoding. It will say "direct" or "transcode". This could be relevant since she is saying it happens when she starts an audiobook.
2. You mentioned she presses play and the audiobook loses progress. Is there any pattern she can find as to when pressing play loses progress? For example, the last listening session for that audiobook was offline, or when she presses play on an audiobook quickly after opening the app (maybe the server is still connecting and this is a downloaded book).
3. You mentioned it happens after she finds her spot again in the audiobook. What happens when she just lets the audiobook play at 0:00? If it still gets hot then we know this doesn't have to do with any actions taken after pressing play.

@advplyr commented on GitHub (Dec 5, 2025): > Just wanted to add my partner is experiencing this on iOS. Their phone is getting very hot. It is happening multiple times a week, even multiple times in a day (she reads a lot). Let me know what info I can provide to assist identifying this bug. > > She says she knows when it will happen. She hits plays, it shows 0:00:00 as the current position, and loses her spot (resets her progress). Then when she finds her spot and continues it gets hot after a bit. Since she can reproduce this consistently, can you give more specific steps that she takes to reproduce it. Does this happen on a specific audiobook or is there anything different about the audiobooks it happens to that can be identified? A few things to look into: 1. Is the audiobook downloaded? If not, when the audio player is expanded to full screen there is small text at the top that indicates whether the audiobook is direct playing or transcoding. It will say "direct" or "transcode". This could be relevant since she is saying it happens when she starts an audiobook. 2. You mentioned she presses play and the audiobook loses progress. Is there any pattern she can find as to when pressing play loses progress? For example, the last listening session for that audiobook was offline, or when she presses play on an audiobook quickly after opening the app (maybe the server is still connecting and this is a downloaded book). 3. You mentioned it happens after she finds her spot again in the audiobook. What happens when she just lets the audiobook play at 0:00? If it still gets hot then we know this doesn't have to do with any actions taken after pressing play.

adam commented 2026-04-24 23:47:20 +02:00

Author

Owner

Copy Link

Copy Source

@MichaelRPowell commented on GitHub (Dec 5, 2025):

@advplyr first, just want to say thank you for all you do. We both love that apps and software. Just added a comment because she brought up the heat issue to me today (she has mentioned the progress resetting a few times) and said it happens often.

1. Yes, the books are downloaded. I've told her to always download them in case her signal drops or whatnot (she listens to them while driving). I also suggest downloading them because the device running it does quite a few things and it relieves processing from the device (I assume).

2. I will ask. I assume your assumption might be correct. I am running the server component on a Raspberry Pi 4 inside Docker (with 3-4 other pieces of software). It does take 10 seconds or so to sometimes connect to the server and update the first page when I load the application on Android. I have found when I am too quick and hit Play before the connection to the server finalizes, I get kicked back to the library screen without it playing.

3. Good question, I'll ask her to give that a try next time. She just said it always happens when that error happens first. Knowing her lack of patience, she never listens for more than a few seconds before jumping ahead to find where she was.

I will try to follow up with more information as I get it. Thank you again for such a quick response! (Her and many others are excited for when the iOS app leaves Test Flight.)

@MichaelRPowell commented on GitHub (Dec 5, 2025): @advplyr first, just want to say thank you for all you do. We both love that apps and software. Just added a comment because she brought up the heat issue to me today (she has mentioned the progress resetting a few times) and said it happens often. 1. Yes, the books are downloaded. I've told her to always download them in case her signal drops or whatnot (she listens to them while driving). I also suggest downloading them because the device running it does quite a few things and it relieves processing from the device (I assume). 2. I will ask. I assume your assumption might be correct. I am running the server component on a Raspberry Pi 4 inside Docker (with 3-4 other pieces of software). It does take 10 seconds or so to sometimes connect to the server and update the first page when I load the application on Android. I have found when I am too quick and hit Play before the connection to the server finalizes, I get kicked back to the library screen without it playing. 3. Good question, I'll ask her to give that a try next time. She just said it always happens when that error happens first. Knowing her lack of patience, she never listens for more than a few seconds before jumping ahead to find where she was. I will try to follow up with more information as I get it. Thank you again for such a quick response! (Her and many others are excited for when the iOS app leaves Test Flight.)

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

master

fix_open_session_progress_sync

fix_android_transcode_track_url

new_jwt_auth

play_from_library_list_rows

create_bookmarks_focus

abridged_indicator

handle_android_edgetoedge

sleep_timer_chime_android

abslogger

capacitor_v7

reader-keep-screen-awake

v0.13.0-beta

v0.12.0-beta

v0.11.0-beta

v0.10.1-beta

v0.10.0-beta

v0.9.81-beta

v0.9.80-beta

v0.9.79-beta

v0.9.78-beta

v0.9.77-beta

v0.9.75-beta

v0.9.76-beta

v0.9.74-beta

v0.9.73-beta

v0.9.72-beta

v0.9.71-beta

v0.9.69-beta

v0.9.70-beta

v0.9.68-beta

v0.9.67-beta

v0.9.66-beta

v0.9.65-beta

v0.9.64-beta

v0.9.63-beta

v0.9.62-beta

v0.9.61-beta

v0.9.60-beta

v0.9.59-beta

v0.9.58-beta

v0.9.57-beta

v0.9.56-beta

v0.9.55-beta

v0.9.54-beta

v0.9.53-beta

v0.9.52-beta

v0.9.51-beta

v0.9.50-beta

v0.9.49-beta

v0.9.48-beta

v0.9.47-beta

v0.9.46-beta

v0.9.45-beta

v0.9.44-beta

v0.9.43-beta

v0.9.42-beta

v0.9.41-beta

v0.9.40-beta

v0.9.39-beta

v0.9.38-beta

v0.9.37-beta

v0.9.36-beta

v0.9.35-beta

v0.9.0-beta

v0.2.1-beta

v0.1.0-beta

Labels

Clear labels

android

android auto

backlog

bug

enhancement

ereader

help wanted

iOS

progress sync

pull-request

Mirrored from GitHub Pull Request

sleep timer

unable to reproduce

waiting

No labels bug iOS

Milestone

No items

No Milestone

Projects

Clear projects

No projects

Assignees

Clear assignees

adam (Adam Melkus)

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/audiobookshelf-app#1056