Plexamp skipping/popping after it's been playing a bit


#1

Basically this presents as if Plexamp retains a cache and it can't keep it filled - it will play fine for a bit, eventually starting to stutter in playback as if it can't keep a buffer full. Pausing appears to fix it for a time loosely proportional to the time paused.

Checking the connection back to my plex server, I see no packet loss, low latency, and approximately 10Mb available in each direction. The server itself is idling with plenty of CPU and memory resources available.

This was not a problem I don't believe until 1.02.

Somewhat related (from a network troubleshooting perspective) is there any interface in Plexamp to get more detailed info for troubleshooting? For example, I (as needed) will VPN home from my work machine for various things. At times I have issues connecting to plex stuff with SSL, that always seems to resolve itself when I let my work machine talk to my plex server over the VPN instead of the web.

Is there any way to surface in Plexamp whether it is connecting back to the server as a "Local" connection, traversing the VPN tunnel, or whether it is picking up the connection from plex.tv and going over the public web?


#2

There shouldn’t have been any buffering-related changes in 1.0.2 that I know of.

is there any interface in Plexamp to get more detailed info for troubleshooting?

On UNIX (macOS/Linux) you can look at /tmp/mpd.log and/or edit mpd.conf to increase verbosity of that log, which can be helpful.

Is there any way to surface in Plexamp whether it is connecting back to the server as a “Local” connection, traversing the VPN tunnel, or whether it is picking up the connection from plex.tv and going over the public web

You should be able to see that from either Application.log or Server.log, look for the server name in question and you’ll see which connection it’s using.


#3

I am having the same exact issue as Verio. I’m using windows 10 with more than enough resources on the plexamp and server ends.

To see if it’s a server or network issue I started playing both Plexamp and a plex web session at the same time to see if both are affected when plexamp starts stuttering. The issue looks to be with the plexamp since the music through the browser is unaffected and is playing when I turn the volume up on the web session.

I don’t know where to look to see where the issue could be, but I have stopped using plexamp after the issue starts each day. Waiting on some solution and it’s good to see someone else is having the issue since I though it was an isolated issue to my install.


#4

Thanks elan - that helped. I can see for example that Plexamp is using the private IP of the vpn connection when it should be, which is good to know. I’m going to eyeball those two files if/when I see this issue re-occur and will update this thread if I can provide any additional info.


#5

I am seeing the same stuttering playback issue and have been since at least the second release. I’m on Windows 7 Pro 64-bit. All is well for some time, usually an hour or more, but eventually stuttered playback begins. CPU and memory usage is normal/unchanged. I have been closing and restarting Plexamp many times a day, which always fixes the issue, but I’ll try pausing for a while as mentioned by Verio to see if I get the same results.


#6

Same issue on macOS High Sierra 10.13.3

Buffering problems after a while of good playing. Restarting plexamp will fix the issue.


#7

I’m still having the same issue - checking the logs, I don’t see anything terribly noteworthy. Server.log has a ton of these while the issue occurs, though it also seems to have a ton of them when it ISNT occurring so no idea if this is the case:

Feb 07, 2018 14:58:13 DEBUG - HTTP: Issuing request to https://public IP and port redacted/:/timeline?state=playing&duration=294220&time=12128&playQueueItemID=13354&key=%2Flibrary%2Fmetadata%2F303382&ratingKey=303382&playQueueID=1100&playQueueVersion=1&containerKey=%2FplayQueues%2F1100&hasMDE=1

The log at the moment has 30-35 lines of this over the course of 3m or so.


#8

@fortiter ~ local or remote playback? I play all day and night routinely on Plexamp without restarting (local server) and never experience this.


#9

@fortiter said:
Same issue on macOS High Sierra 10.13.3

Buffering problems after a while of good playing. Restarting plexamp will fix the issue.

@elan said:
@fortiter ~ local or remote playback? I play all day and night routinely on Plexamp without restarting (local server) and never experience this.

I see the same issue on 10.13.3 as well, I can get through around 3-4 songs before I get stuttering/under-water quality. Restarting plexamp fixes. This is for remote playback.


#10

@elan said:
@fortiter ~ local or remote playback? I play all day and night routinely on Plexamp without restarting (local server) and never experience this.

Local seems to be fine, but remote is where I am running into buffering issues.

Also, I haven’t tried remote playing on my other devices that have plexamp, so my specifying macOS 10.13.3 is not a limiting factor, just some extra information.


#11

@Averenix said:
…before I get stuttering/under-water quality. Restarting plexamp fixes.

Can you explain what you mean by “under-water” quality? We don’t do any quality adjustments.


#12

If my issue is the same then the “under-water” quality is where the track being played slows down a bit and then it starts a pause- start affect that seems like stuttering or playing underwater. It happens everyday so I can record the output if needed.


#13

Super weird, nothing comes to mind :confused:


#14

This is still occurring for me as well, only when traversing the internet. Local playback on my home network is fine.


#15

I also ran into this. I’ve been combing some of the other issues that people are reporting related to this and I can notice a handful of similarities:

  • I experience this in Plexamp only with a remote connection to the most up to date (1.12) plex media server, plex media player and plex.tv have no issues
  • The timing is anywhere from 20 minutes to one hour of direct play, skipping tracks exasperates the situation
  • None of the aforementioned methods of playing are transcoding, direct play only
  • The logs don’t report anything strange, playback is just stuttering / buffering / choppy
  • Restarting Plexamp corrects the issue

MPD.log is loaded with:

Feb 28 15:43:54.739: replay_gain: scale=0.315864                                              
Feb 28 15:43:54.935: replay_gain: scale=0.315864                                              
Feb 28 15:43:55.129: replay_gain: scale=0.315864                                              
Feb 28 15:43:55.238: replay_gain: scale=0.315864                                              
Feb 28 15:43:55.430: replay_gain: scale=0.315864                                              
Feb 28 15:43:55.538: replay_gain: scale=0.315864                                              
Feb 28 15:43:55.730: replay_gain: scale=0.315864                                              
Feb 28 15:43:55.838: replay_gain: scale=0.315864 

I can include some logs if it is more helpful, though I don’t see anything useful there. Looking at this thread, it looked like there was some improvement with editing buffer_before_play and audio_buffer_size in the MPD conf but with the following I still saw issues.

replaygain "off"
buffer_before_play "10%"
audio_buffer_size  "32768"

I disabled replay_gain but I’m guessing it was spamming the logs due to the rapid changes in volume, though I’m not sure.

I suspect it’s related to MDP and a configuration issue, but I’m not sure what conf file Plexamp is using on OSX. I don’t think it’s picking up ~/.mpdconf or /etc/.mpdconf.

Hope this helps identify a potential root cause or helps others looking for information.


#16

I suspect it has something to do with underflow/buffering, but it’s weird that restarting fixes the issue.


#17

Over on a similar thread, I reported many of the same things as @kylekyle, including the continuous replay_gain messages (like 6 a second) once the stuttering begins. No combination of buffer_before_play or audio_buffer_size settings have improved the situation for me. I tried lots of combinations. I was able to eliminate the replay_gain log messages by adding replay_gain_handler "none" to the audio_output section of mpd.conf (which disables normalization, of course), but that didn’t affect the stuttering issue, and that section of mpd.conf seems to get overwritten anyway.

One thing not mentioned above is that (for me at least) when stuttering begins and I attempt to pause and restart playback, Server.log sometimes indicates an MPD connection error (socket is closed), and the play queue is cleared.

Feb 26, 2018 15:13:24 DEBUG - GET /player/playback/pause?commandID=3219 200 2 - 0.724 ms
Feb 26, 2018 15:13:24 DEBUG - State changed from playing to paused
Feb 26, 2018 15:13:24 DEBUG - HTTP: Issuing request to https://[ip address]:13556/:/timeline?state=paused&duration=311928&time=269653&playQueueItemID=132710&key=%2Flibrary%2Fmetadata%2F42068&ratingKey=42068&playQueueID=5073&playQueueVersion=1&containerKey=%2FplayQueues%2F5073&hasMDE=1
Feb 26, 2018 15:13:33 DEBUG - GET /player/playback/play?commandID=3226 200 2 - 0.586 ms
Feb 26, 2018 15:13:37 ERROR - [MPD] Error connecting:Error: write ECONNRESET
Feb 26, 2018 15:13:37 DEBUG - Lost connection to MPD, reconnecting
Feb 26, 2018 15:13:37 ERROR - [MPD] Error getting status! This socket is closed
Feb 26, 2018 15:13:37 ERROR - [MPD] Error getting status! This socket is closed
Feb 26, 2018 15:13:37 ERROR - [MPD] Error getting status! This socket is closed
Feb 26, 2018 15:13:37 ERROR - [MPD] Error getting status! This socket is closed
Feb 26, 2018 15:13:37 ERROR - [MPD] Error getting status! This socket is closed
Feb 26, 2018 15:13:38 INFO - [MPD] Connecting...
Feb 26, 2018 15:13:38 INFO - [MPD] Ready!
Feb 26, 2018 15:13:38 DEBUG - GET /proxy/file.mp3?source=[alphanumeric string]&endpoint=%2Flibrary%2Fparts%2F44395%2F1236048802%2Ffile.mp3%3Fdownload%3D1%26X-Plex-Client-Identifier%[alphanumeric string]%26X-Plex-Session-Identifier%[alphanumeric string] 200 5924196 - 174.374 ms
Feb 26, 2018 15:13:38 DEBUG - PROXY: Stream got closed after sending 5422044 bytes.
Feb 26, 2018 15:13:38 DEBUG - State changed from paused to stopped
Feb 26, 2018 15:13:38 DEBUG - HTTP: Issuing request to https://[ip address]:13556/:/timeline?state=stopped&duration=311928&playQueueItemID=132710&key=%2Flibrary%2Fmetadata%2F42068&ratingKey=42068&playQueueID=5073&playQueueVersion=1&containerKey=%2FplayQueues%2F5073&hasMDE=1
Feb 26, 2018 15:13:38 DEBUG - PlayQueue: Skipping audio update for NaN, it was too old.
Feb 26, 2018 15:18:24 WARN - [POWER] Turning power off!

Other times, the playback begins playing without stuttering for approximately the amount of time it was paused, then begins stuttering again. Only by completely restarting the app does a long period of non-stuttering playback result.


#18

In case anyone else is curious, I ended up resolving this by editing by mpd.conf in the plex helpers directory ( https://forums.plex.tv/discussion/comment/1632593#Comment_1632593 ). I was editing the home directory in OSX or the /etc/ path, which would explain why it had no effect.

:expressionless:


#19

I can confirm that the issue persists with 1.04 Windows version at least when playing over internet.
I tested also by modifying mpd.conf and set the:
audio_buffer_size “16384”
buffer_before_play “35%”
But it did not affect the shuttering/chopping issue, it appeared again.
The buffering is probably not the root-cause.

I get also an enormous number of

    Mar 13 13:19:22.661: replay_gain: scale=0.362660
    Mar 13 13:19:22.893: replay_gain: scale=0.362660
    Mar 13 13:19:23.202: replay_gain: scale=0.362660
    Mar 13 13:19:23.354: replay_gain: scale=0.362660
    Mar 13 13:19:23.659: replay_gain: scale=0.362660
    Mar 13 13:19:23.863: replay_gain: scale=0.362660
    Mar 13 13:19:24.097: replay_gain: scale=0.362660

at log.log at C:\Users estuser\AppData\Local\Programs\plexamp\log.log.

Increasing the buffer to 35% has a negative effect when trying to play flac over internet , it takes awful lot of time start the playback.


#20

I’m still seeing the same issues as @nkef with 1.04 on Windows.