Headless Plexamp - tricky but possible to get multichannel working on HDMI out of a Pi3

Thank you so much. I’ve been digging in more, and am finding more understanding, and more questions. Let me sum up where I am now, and hopefully we can figure something out.

I’ve determined that my inconsistent test results are because in testing, caches sometimes build up, and give me a false working test.

I’m finding the clear cache button doesn’t seem to be resetting things as I expect. Not sure if the behavior of that button isn’t straightforward - it still considers the last played album to be playing and refrains from clearing it perhaps? Dunno, just a guess…

I found the /home/pi/Library/Caches/Media/ folder to better clear and track what is building up.

I’ve determined that my max bandwidth requirement of 192kHz 24bit 5.1 flac files are requiring more bandwidth than my wi-fi is providing at the moment - some of co-pilot’s tests gave it and myself a false sense of networking issues not being the issue, but we finally determined the bandwidth that is being used between the server and the pi is less than the bitrate of the files requires.

If I pause playback, and let the cache build up, I can then playback - it’s basically a cheat to get an offline copy. Not ideal, but helpful in understanding what I"m up against here.

This means tweaking the caching settings isn’t really going to help me much, the bottom line is if my bandwidth doesn’t cache faster than I play, it ain’t gonna work.

Yes, 192kHz is extreme. It’s also what the Rhino Quadio blu-ray discs provide. And I rip as-is, and maintain bit perfect copies as redundancies and backups. Making reduced copies of every purchase isn’t an ideal solution.

As I take this more remote, I am going to want to reduce the bandwidth and data usage here though.

Under “Streaming Quality” is the “Ethernet or Wi-Fi” setting, that lets me set bitrates. Even the highest bitrate of 2Mbps should get me under the bandwidth limitations of my home Wi-Fi. I’ve set it to this. I’ve restarted the service to ensure the setting is taking effect. I’ve monitored the cache folder. I started and paused the first track of an album. I watched the caching folder build up to the size of the first 6 songs of the album (current + next 5 I guess?). This suggests caching doesn’t follow the 2Mbps bitrate. Is this by design? If the setting doesn’t apply to what it caches, then what’s the point? It wouldn’t reduce the data being used, which would defeat the purpose, so I don’t expect this is the intended outcome, but I also don’t fully understand how this setting is meant to behave.

So that’s where I’m at at the moment. Heading to bed, and will resume testing tomor…er…later today.

Actually - the caching folder of /home/pi/Library/Caches/Media/ is still growing, and growing bigger than the first 6 songs of the album I started and paused the first track of. And caching is set to next 5 songs. I can’t make sense of how caching and bitrate settings are working, but they don’t seem to reflect my expectations at all. Perhaps co-pilot has found me the wrong folder, which would explain why it doesn’t empty when I clear the cache.

Ok - more insider knowledge would be most helpful at this point to help nudge things further along here.

That is setting the level above which it will convert to Opus (when not on LAN).

Best advice: Get faster networking and storage.

yes, an nvme ssd hat would probably help quite a bit (tho it adds to hardware cost and power draw, and to run from the ssd means reinstalling everything) …

faster storage to reduce bottlenecks, and more storage to keep a large amount of music cached at whatever quality level you want (over time, as more cached files accumulate, this will reduce frequent network use to fetch new tracks)

however, you already have a dac hat … stacking multiple hats might be an option ? (not sure) … if that won’t work, you might try adding a high capacity usb thumb drive (preferably rated for fast writes) to your existing setup, mapping it to ~/Library, and increasing the headless cache size setting … expect some of the same benefits as using an nvme ssd, but cheaper/easier to add

I’m not sure what I can fit in my enclosure, but I have ordered a NVMe hat to play around with.

However - I do want to know more about the finer details of how the Streaming Quality setting works. I guess the key phrase there is “when not on LAN”. So when I’m off my network, it will convert to Opus? Is that done server side - and then will cut down on network bandwidth?

Will do more experimenting with that today. hat will come tomorrow, and then I can play with that.

Thanks again for your help, this has all been most helpful, really appreciate it.

Yep. I should have read up-thread a few posts. I didn’t realize they were testing with 192 kHz, 24-bit, 6-channel FLAC :upside_down_face:. Lesson learned.

@armyofquad1 I still think it would be interesting for you to test the cache settings above, but adjusted slightly. Instead of 5 or 10 Mbps for networks speed, try 50 and 100 Mbps. Even if your FLAC files are uncompressed it would be ~28 Mbps (~3.5 MBps). Leave the caching to next track only. For science.

And, if you watch the bandwidth graphs in the Plex Web app dashboard while playing some tracks, you’ll gain a better understanding of exactly how Plexamp works with regard to its caching. I think you might find it interesting.

You could also test it with various Quality settings (above 32 Kbps convert to 256 Kbps, for example) to see what effects it has on the streaming.

Thanks for the suggestions, will play around more and try these specific settings, for science - but I’ve played with a lot of combinations, and it seems to be consistent that the current setup cannot keep up when it comes to 192 kHz 24-bit 6-channel FLAC.

Also for science, I put things on my phone hotspot, to test what Streaming Quality of 2Mbps would do. And the flaw with that is, at this time the conversion downmixes any 5.1 to stereo.

When remote, it would be desirable to have an option to have bandwidth controls without sacrificing 5.1, so I would like to request a future feature enhancement of allowing the Stream Quality conversion to preserve 5.1 in that conversion. Would I need to submit this somewhere to make it official?

Another quirk - in some of my testings, sometimes plexamp goes rogue and will not be stopped! I’ve had multiple instances where I hit the pause button, and the display shows the music paused, but the music continues playing. My ssh session drops. My pi will not accept a new ssh session. Any efforts to control plexamp by web or app is ignored - I can get in, and it shows the paused state, but trying to play something else does nothing…the cached music just keeps going. I’ve been forced to cut power to the Pi as the only way to stop it.

Is this a normal quirk of caching?

I understand. But capping the bandwidth forces Plexamp to spread the load more evenly over time instead of trying to trying to grab it all in one bite. So instead of it potentially saturating a 150 Mbps Wi-Fi connection for a few seconds it can consume an average of 50 Mbps over several seconds.

Also, the caching of a new track takes beginning at the start of the current track. What you’ll see when you watch the bandwidth graph in the dashboard is that when Plexamp moves from one track to the next, it will pull down the next track; after that is complete, the graph basically shows no activity (except that used to show the graph itself).

This also impacts the storage I/O as well since it’s not trying to write a bunch of data all at once.

All of this is in an effort to mitigate some of the bursty-ness of the transaction. But ultimately you likely do need faster storage. Hopefully the NVMe drive will address this.

Probably, in the Feature Suggestions section of the forums. I’d recommend doing a search first to ensure that someone else hasn’t already suggested it.

I don’t know, I’ve not experienced this myself. But our setups are completely different. I have human-level hearing and so don’t bother with super-high bitrate music. So I’m likely not stressing my Pis the way you might be.

I’d start another thread and provide a detailed description and provide Plexamp logs. If you try to lump another problem into this thread it’s likely to get lost.

OK, cool - although I think you’re suggesting I"m not human, lol.

As I learn more and navigate through this, a growing concern is the desired reduction of bandwidth when remote, and a need to address that.

Currently, taking my surround music on the road requires converting files, authoring discs, and maintaining a binder of DVD-Rs. It seems these days when you pull an optical disc out to put in a car player, you get looks like you’ve just pulled out an 8-track tape.

I’m thinking some sort of compromise is going to be required to get this model to a reasonable amount of bandwidth use - streaming such large amounts of data remotely, on phone hotspots, seems a foolish idea to pursue. If I can find a compromise transport option, and create a 1 step script to convert albums to the transport option, into a “roadtrip” folder that is used to create a new “roadtrip” library in plexamp, this does still require some prep work to take albums “on the road”, but reducing it to a simpler process than authoring a DVD, and trading in my DVD binder for a server folder, are steps up.

Problem is finding an acceptable “transport” 5.1 audio option.

My first obvious thought was thinking back to discovering that I could rip 5.1 DTS audio CDs to “2 channel” .flac files that retain the DTS encoding, and that things can play back. After banging my head against some script creation, and the fact that DTS encoded .wav files seems to be a thing of the past that tools don’t know how to handle preventing me from getting a “2 channel” DTS flac test file - I decided, lets even see if this is viable, and pulled out my Ohio Players - Honey DTS CD, did a rip, threw it in my roadtrip library, and tested to see if I could get some quadraphonic love roller coaster playing out the Pi.

I got some lovely DTS encoding white noise.

Ok - plex don’t know what to do with DTS encoded .flacs.

Of course it seems the simplest solution would be to encode to lower sampling rate and bitdepth .flac files. Which should be adequate - although I’ve just hit a contradiction as I think back to why this should be adequate, as back on my Pi3 HDMI test, I successfully played the entirety of the quad mix of Dark Side Of The Moon using my phone as a hotspot, and not a single buffer, which is 24bit 96kHz, and today I can’t get my SACD rip to 24bit 88.2kHz of the 5.1 mix of 52nd Street to play without buffering issues. But - upon review - the DSOTM quad never got rechanneled to 5.1 with silent center and sub, so it’s 4 channel.

Now rethinking my decision to rechannel all quad to 5.1 with silent center and sub for consistency - although 4 channel flac identified as such should playback properly, many pieces of equipment do not play nicely with such formatting. And equipment refusing to adhere to unfrequently used standards means I’ve had to adapt to the frequently used standards to avoid being bit in the ass at some point. But - at this point it seems everything I have plays nicely with 4 channel, including this Pi, so perhaps I should take some time to rechannel my quads back to 4.

Ok - fun detour.

Either way, I can certainly include a checkbox in whatever script I build to whatever transport option I come up with for the roadtrip library, to drop center and subs when encoding.

But I guess the question for those around here is - what are your thoughts on a best reduced bandwidth 5.1 audio option that plexamp will support?

To me, qualitywise, DTS would be the best compromise - but unfortunately seems to be unsupported, unless those of you that know the inner workings of this have an idea how to get DTS encodings streaming and decoding with plexamp.

It seems the best supported options I can come up with, asking co-pilot to do a little investigating, are reduced bitrate flacs - still high bandwidth, but 16bit 48/44.1 kHz would certainly knock things down, and stripping silent channels when possible would also help. Or if I want to go down further, AAC - which these golden ears don’t like the idea of compressing further down than DTS would, but perhaps would be good enough for the car.

Any other thoughts come to mind from others?

They really need to get on this, its ridiculous not have this basic function in 2025, I paid for lifetime Plex pass & got nothing for it except basic functionality but since they require it for all cloud serving I had to shell out only to get 2 channel stereo. :roll_eyes:

What are you talking about?

Plex does not stream w/o Plex Pass from external web servers now (or for most of this year I think), but that’s not the issue I posted about.

This thread is about Plexamp headless.
And music streaming doesn’t require a Remote Watch Pass or Plex Pass.

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