I’m trying to determine what information I may have at my disposal to troubleshoot the more-often-than-not pausing/hanging of playing tracks via Carplay.
I have an iPhone 12 mini for use in this instance. I would assume Carplay is Carplay, but for the purposes of having all information, vehicle is an M4 via iDrive6.
I would sometimes attribute this to signal issues and the like, but if nothing else, the service I’m now on is better than what I’d come off of, and while I expect some drops here and there, I have a complete inability to resume playing unless I go to a different artist or the like. When I shuffle play any particular artist, it will get through two, three, maybe four songs and stops playing. The interface still works, it just will not play.
So I’m trying to determine if this is a Carplay issue or Plexamp issue.
I have logs from the app and as I’m reading through it, it’s generating more questions, but I’ll deal with that later. I’d rather not attach my logs here given the data within. Happy to send them where required to shed any light.
almost certainly an issue in the app buffering the track. logs will help if you send them after you see the issue (after a drive, e.g.), feel free to DM.
you can also eliminate the possibility of a signal issue by downloading some items and playing them from the downloads tab in CarPlay. that would also be useful for diagnostic purposes.
The 0830-0930 hour was one issue, though the 11-12 hour also had the issue. In the latter case, after playing stopped, I did nothing, and I think you can see shortly before I ended this trip, it started playing again.
I can guarantee that there were no signal issues that would have prevented playing at all during either of these cases.
My settings are to play at the maximum rate for any connection type. In the case of tracks chosen to play, their bitrates are at most, ~1.6Mbps. I would not expect even 3G service to have issues with this, let alone 4/5G, which is what I’m on. And certainly I’ve have expected it to buffer enough to play out whatever track was selected at the time; it would not take an hour to buffer.
As mentioned, I’d expect signal issues from time to time, hence buffering to a nice degree.
To that end, I have it set to cache 15 songs with 8GB. I would expect that while playing, it will pull as much as it can, as quickly as it can to reach that limit.
In the case of the second time frame, it did absolutely nothing for 53 minutes. There is, guaranteed, zero chance my device had service insufficient enough that it couldn’t pull anything during that entire time.
As mentioned, during the first time frame, changing artists started playing again. Surely it would have continued playing the already chosen track given it had no issues starting to play the newly selected one.
As for the remote access issues, it’s a simply port forward from any source to the VM hosting PMS. Storage is on a separate VM NAS and there are no communication/performance issues here. Certainly not at this throughput.
As for downloads, that would defeat the purpose of setting this up in the first place, and should I go down that road, I have a 2TB drive I’d use. I have over 13k tracks in over 800GB. Who knows what I’ll be listening to at any given point, so DL’ing to a phone would be impractical and counterintuitive.
Is there a mechanism by which the app gives up after some time, or some interaction that’s breaking between the app and the phone to determine whether it can/should continue to pull?
Anything on PMS I can look at specific to the client in question to look at that side of it?
you seem to be running into at least some connectivity issues back to your server which will affect media streaming. I see those issues during both time periods.
Jan 09, 2021 11:08:23.680 [0x6d78b000] INFO - Cache: Buffering until offset reaches 512000 (read buffer offset: 0, size: 512000).
Jan 09, 2021 11:11:02.753 [Javascript] INFO - Error loading: http://xx.xx.xx.xx:32400/:/timeline?state=buffering&duration=27000&time=0&playQueueItemID=37238&key=%2Flibrary%2Fmetadata%2F19614&ratingKey=19614&playQueueID=2058&playQueueVersion=1&containerKey=%2FplayQueues%2F2058&hasMDE=1&includeFields=thumbBlurHash&X-Plex-Device-Name=CD12: timeout of 30000ms exceeded
Thanks, and I understand that. What I’m saying though is it didn’t not have connectivity for 53 minutes. I was between 4G and 5G service the whole trip between that time and 12:04 when it picked back up.
Given what shows here are already debug logs, I’m going to gather there is no additional logging here that can be done?
Next trip I make I will set up some additional monitoring to look at actual traffic as well as confirm data ability. I’m not convinced it’s a simple matter of I couldn’t reach my server.
Hmm, so I took another look at the logs and saw this:
Jan 09, 2021 11:11:09.724 [0x6dd8f000] INFO - Cache: Buffering until offset reaches 972966 (read buffer offset: 353446, size: 619520).
Jan 09, 2021 12:04:33.146 [0x6dea7000] INFO - Cache: Buffering complete as offset is now greater than 972966 (995658) and read completed: 0.
As you can see, over 50 minutes goes on without another log. My new suspicion is that the OS is putting the app to sleep (aggressive battery setting?) before it can finish buffering.
Well, the screen wouldn’t be on permanently like that. It will shut of automatically at whatever time I told it. I was driving so I couldn’t/didn’t check. I only saw what was reported via the CarPlay information, which will show signal strength, etc.
Well, in honesty I’d not noticed whether the screen was on or not. If it keeps it on, I’d argue that’s not all that great. Especially with OLED displays. While relatively short times it may be in may not make a difference but the display shouldn’t have a requirement to be on IMHO.
I will try to make some sort of trip to try to replicate as soon as I can.
the setting is off by default, don’t worry. i was just wondering if the OS is putting the app to sleep in the background but it would continue to work if the screen were unlocked and the app was in the foreground.
For the record, I made the same trip under the same conditions this past weekend and it seemed to work without a hitch. Nothing had changed in my environment from that perspective so…
One good trip, one bad. We’ll see what happens next time as I’m making another trip this coming weekend.
