Headless Plexamp on Pi not caching as expected

Plex Labs
1

This is a separate problem, or evolution of a problem, from past posts.

I have created a test library of AAC files to playback, to avoid bandwidth issues, and buffering issues.

I am testing this on my phone’s hotspot, as that is the intended method of using this Pi. Playback works fine, bandwidth of the hotspot seems to be adequate for these purposes, this is clearly a buffering issue.

I have tested with various caching settings, but this unwanted behavior seems to be persistent, in that the player doesn’t cache. It only buffers the currently playing song, once it buffers it plays the song through without issue, and once it gets to the next song, it hesitates, and then buffers the next song. It never caches the next song. I’ve set it to the next song only, the next 5 songs, the next 10 songs, the next 40 songs - doesn’t matter, it only ever buffers the current song, and never caches anything.

Given that it is able to adequately buffer the current song, and play through the current song to the end without issue, there is no reason it shouldn’t be able to cache the next song.

I captured a screencapture of the bandwidth dashboard over the time of the logged test. Logged test was run with cache settings of only next track, 2GB cache size, 10Mbps Network Speed - but as previously stated, this behavior on the phone hotspot has been consistent at this time.

(I actually am just remembering that yesterday when testing the caching of larger files, I did see caching work as expected, so I’m not sure what changed. Yesterday’s test was on large .flac files, which I observed cache while paused on the first song - these files I’m testing on today are AAC files, should be easier to cache
Plexamp.1.log (145.5 KB)
)

image
image1168×403 47.8 KB

As can be seen in the image, there’s a peak where it buffered the first song of the album, and then went to a flat line while it played the song, only peaking up once the song finished and it was time to play the next song, resulting in silence during what should be a gapless transition - I see no reason it shouldn’t have cached the next song as set to do.

Attached is a log from the text.

2

What is the following value currently set to?
Settings -> Playback -> Audio Output -> Sample Rate Matching

If set to anything other than Smart change it (to smart) and test again. Leave it set to cache only the next track for the time being. See if the gaps are eliminated (or reduced).

For what it’s worth, the caching behavior you describe sounds correct. Remember, this is caching, not buffering. (Although a cached object could be considered a buffer.) When you start playback, Plexamp builds a queue of items to play. It begins playing the first item and immediately caches (at least) the next track.

That bump you see at the track-to-track transition is it caching the next track, not the one you’re currently hearing. You can test this by monitoring the ~/Library/Caches/Media folder. At the track transition, you’ll see it add a new file (it actually adds two, ignore the .dat file). When it’s finished caching it, check its size; it will be the size fo the next song in the queue. Here’s an example. This is the next song in my play queue:

image
image626×107 45.4 KB

This is a portion of the file details for the track:

image
image156×213 4.24 KB

And this is the file in the cache directory (the cached data always seems to be slightly larger, perhaps some additional metadata:

3.8M Apr 24 20:51 0579083b69435c736a8c5eb6fccdb322f18d870e4df8ba1de01710586b8cee86

The currently-playing track is ~8 MB:

7.9M Apr 24 20:47 11d4f35fe54edf1cc203d763185a18ecccd9947f8479cfc33ea83a130f53cebe
3

That is a logical theory, but it isn’t aligning with my observations.

I observed the cache directory grow to the size of the significantly smaller first track of the album, and stop at that point, at which point the line in the graph went to zero, with no caching.

I observed the track change not have anything ready to play, stop, the play/pause button turned into a rotating animation, it buffered, and resumed.

I’m fairly confident that it buffered the 2nd track at the transition after doing no caching for the entire length of the first track.

At the suggestion of AI, I upgraded my plexamp from 4.10 to 4.12. Now it won’t play anything.

I really hope I don’t need to figure out how to downgrade back to the working version.

New log is attached. Thanks again.

Plexamp.log (211.1 KB)

4

Nevermind the new log, reboot seemed to clear it up - testing samplerate settings as you suggested.

5

Cool. By the way, the above wasn’t theory-crafting. It was based on an observable fact (because I wanted to be certain of the behavior myself).

I completely cleared the cache directory on one of my headless Plexamp Pis. I then started playback of an album with a 4 and a half minute track followed by a 10 minute track. This is the directory listing of the cache folder after ~5-6 seconds:

image
image783×117 10.4 KB

Note that Plexamp has cached not only the first track, but the following one as well. Also note the relative sizes.

This is after the transition from the first track to the second:

image
image778×158 4.51 KB

The third track is a 124 kbps MP3 while the first two are 44.1/16-bit ALAC. Hence the huge size discrepancy. But it also illustrates the point.

6

You’re running a fairly ancient Plexamp.

Plexamp 4.10.0

Upgrade; one of the things we added recently was a multi-read-head for the cache, which avoids exactly the behavior you’re seeing.

2 Likes
7

@armyofquad1 If you watch this thread you can receive notifications whenever a new version of Plexamp is released:

image
image651×176 15.4 KB

8

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.