I thought you addressed my previous issue in version 3.4.3, and I tested it, but the problem persists.
When using a local template in peppy_remote, set to random or list, if the theme contains a spectrum table, the spectrum table displays incorrectly. Firstly, it exceeds the boundaries, and secondly, the spectrum table seems to be merely a demo rather than a real music spectrum.
I’m a bit confused; when set to random or list, the program uses independent graphics rendering for the output.
I’ve spent a lot of time reading your code, trying to find a solution, but without success. I’m still working on it.
The issue I mentioned in yesterday’s post turned out to be specific to my own setup rather than a general problem; I have resolved it, which is why I deleted the post.
Regarding Peppy_Remote, when the template is set to random or a list, the program’s spectrum rendering output is messed up for templates containing spectrum tables.
I’ve found the problem; it’s most likely a bug.
After digging a bit deeper:
Regarding the Callback.spectrum_output object created by _init_remote_spectrum within the remote_spectrum function—if meter is set to random or list, that object is destroyed before Callback.peppy_meter_start is entered (I haven’t examined the specific details of this). Instead, it is reconstructed when Callback.peppy_meter_start executes (and the reconstruction might not be providing a complete set of parameters). At this point, it loads SpectrumOutput from volumio_spectrum. Although the program runs without errors, the spectrum display is garbled.
The Callback.spectrum_output created by _init_remote_spectrum uses: from peppy_spectrum import RemoteSpectrumOutput
This output produces a correct spectrum.
It turns out different rendering implementations are indeed being used.
When constructing Callback.spectrum_output via _init_remote_spectrum, if meter is set to random or list, the return value of _init_remote_spectrum is None.
Well… You did the homework, found the bug, traced it to the correct root cause, and even identified which class was being substituted. I would be annoyed if I were not impressed.
You were exactly right. On random and list mode, peppy_meter_stop destroyed the injected RemoteSpectrumOutput, and then peppy_meter_start rebuilt a host-side SpectrumOutput from the pipe or demo path instead. That is why explicit meter kept the correct remote rendering but random and list produced the garbled overflow you saw.
Fix is on experimental for both repos. A spectrum factory now recreates RemoteSpectrumOutput on each rotation so random and list get the same rendering path as explicit. You will need to update both the host handlers via sync and the remote client itself.
If you want to verify before the next release lands, pull experimental on both and let me know what you find. Or wait for the next tagged release if patience is more your style.
As for the deleted post - noted. The sleep clinic has a strict policy of pretending deleted posts never existed, so your record remains spotless.
I’m so glad to receive your reply! I deleted the previous post because I was a bit unsure, so I rechecked the symptoms and posted again to explain the issue.
There is one more point I would like to clarify:
if the theme running on peppymeter_screensaver does not include a spectrum display, it will not transmit spectrum data; consequently, if the theme displayed on peppy_remote includes a spectrum feature, the spectrum will not be shown.
I feel that the mechanism for randomly changing themes is logically conflicting with the peppy_remote program architecture.
The sleep clinic appreciates a thorough patient history, even when it arrives in installments.
Your additional point is also correct. In Server + Local mode, spectrum UDP used to follow only what the host meter was rendering. If the host skin had no spectrum, remotes got no bins, even when the remote theme showed a spectrum. That clashes with random and list mode and with local templates that do not match the host.
Two fixes on experimental:
First, random and list spectrum recreate. After a meter rotate, the remote keeps using RemoteSpectrumOutput with network bins instead of falling back to the host pipe or demo path. This is the fix for your original report.
Second, optional always-stream. Under Remote Display Server there is a new switch: Always stream spectrum bins (remote.spectrum.always). When off, which is the default, spectrum follows the host meter only - best when host and remote stay in sync. When on, if the host meter has no spectrum, the server still reads the spectrum FIFO and sends bins to remotes via an exclusive handoff so the host display does not flicker. Turn this on if you use different or random spectrum skins on the remote, leave it off for fully synced setups.
Update both screensaver and remote from experimental, toggle the switch to match your use case, and let me know what you find.
One small note. The head surgeon is currently checked into a different clinic and working on what he can, when he can. The fixes are landing, but on my schedule, not anyone else’s.
I downloaded the latest update of the experimental version. Although I haven’t seen the desired effect yet, I can see your solution approach from the code, and I’m working on it too.
Take a close look at this code. Right now, this experimental version—to put it simply—is merely “striking a pose, getting ready for action.” The code isn’t actually performing any operations yet.
Could you tell me whether the meter rotate mechanism in the peppy_remote meter random/list mode is handled in peppy_remote.py or by start_display_output in volumeio_peppy.py?
Meter random/list rotate is handled in start_display_output in volumio_peppymeter.py, not in peppy_remote.py.
Flow: the display loop decides when to rotate (interval or title) → sets pending_restart → meter.restart() picks the next meter. Peppy Remote only starts that loop and wires callbacks.
What is in peppy_remote.py for random/list is the spectrum side: after each rotate, peppy_meter_stop clears spectrum, so we set callback.spectrum_factory so peppy_meter_start can create a new RemoteSpectrumOutput. That factory intentionally does nothing while the meter name is still random / a list; it runs once PeppyMeter has selected a real section.
If something still looks inactive on your side, tell me whether you mean meters not changing, or spectrum not updating after a change - those are different paths. Also check: more than one meter in the list, random interval / title setting, and whether the skin has spectrum visible (and host “Always stream spectrum bins” if the host skin has no spectrum).
In the experimental version of the update test, when the meter is set to random/list, when rotating to a topic containing the spectrum, I see that the spectrum rendering is still implemented by the local SpectrumOutput, and the display effect is messed up.
I’m very sorry, it was my mistake. I didn’t use the experimental version on ScreenSaver.
I’ve now updated the program on the peppy_remote side of ScreenSaver (I blocked peppy_remote’s synchronization, and ScreenSaver is still using version 3.4.3), and now peppy_remote is working perfectly with significant results.
One last question: Has the new switch: Always stream spectrum bins (remote.spectrum.always) been added in the experimental version?
I’ll send you the steps for running peppy_remote on Android (it no longer has any missing features on Android). You can decide whether to release it according to your rules.
Everything I described is on experimental right now, on both repos. That is what “two fixes on experimental” meant in the post above this one.
To be completely clear, since the release notes and the wiki are apparently decorative:
Main (3.4.3, current release) - does not have the spectrum fixes or the always-stream switch. What it does have is documented in the release notes attached to the tag, which are available for reading at any time.
Experimental (ahead of main) - has the following changes not yet in a release:
Remote spectrum fixes - recreate RemoteSpectrumOutput via factory on random/list restart so the remote does not fall back to the host pipe/demo path. Always-stream spectrum bins toggle under Remote Display Server so remotes get live bins even when the host skin has no spectrum.
Folder layer fix - clear overlay slot on track change so stale logos do not persist.
New skin author keys - folderlayer border support, progress fill parity with volume including radius, playinfo.align (left/center/right), per-skin format icon overrides (PNG keeps authored colours, SVG still tints), album-folder images on cassette reels, format/type display mode control (icon/text/both) with skin precedence over global default, and optional unlimited fanart images per artist with appropriate crash warning.
None of this is a release. Experimental exists so things can be tested before they ship. When testing is complete and nothing is broken, it merges to main and gets tagged.
Full list:
peppy_screensaver - 16 commits:
fix(remote): recreate spectrum via factory on random/list restart
fix(folderlayer): clear overlay slot on track change
fix(remote): stream spectrum via pipe when host has no spectrum
feat(remote): UI toggle for always-stream spectrum bins
feat(folderlayer): add optional border like albumart.border
feat(progress): add fill.* parity with volume including radius
Let me summarize the key points for running peppy_remote on Pydroid 3:
You must install Pydroid 3 and the Pydroid repository plugin from the Google Play Store. pip requires Google authorization during subsequent dependency installations.
Install the following dependencies in Pydroid 3 (you can find pip in the Pydroid 3 menu):
pillow, cssselect2, tinycss2, defusedxml, webencodings, python-socketio[client], python-engineio, bidict, requests, certifi, charset-normalizer, idna, urllib3, websocket-client, mss, pyscreenshot, easyprocess, entrypoint2.
pygame is pre-installed; do not install cairosvg! If you do, uninstall it.
Using a file transfer tool, copy the following files from the peppy_remote folder (Windows system) and add them to the download/peppy_remote directory in Android.
Overwrite the file with the same name in download/peppy_remote with the peppy_remote.py file I uploaded.
Transfer the templates & templates_spectrum folders to download.
Preparation is now complete, and you can start running.
Run PyDoid3 and launch the terminal mode from the menu.
Configure Profile, templates, and templates_spectrum paths. It’s best to use absolute paths (important).
After configuration, switch to IDE mode and open download/peppy_remote/peppy_remote.py from the menu.
Click the yellow triangle run icon in the interface.
Hope everything goes well for you!
In practice, I used an external USB keyboard. The on-screen keyboard of a phone or tablet does not work very well with Pydroid3 (Pydroid3 terminal mode).
peppy_remote.zip (15.6 KB)
Unzip before use.
Nerd has just confirmed experimental version 3.4.4. This peppy_remote.py (included in the zip file) still works.
Modifications to peppy_remote.py:
Ensure all functions are correctly referenced on Android.
Enable PYGame to be initialized first.
Ensure the peppy display is aesthetically pleasing on phones and tablets.
This reply assumes you have successfully installed the latest experimental versions of peppy_screensaver & peppy_remote and that they are running normally.
The issue with the spectrum display is now perfectly resolved. When I finally got peppy_remote running on Android, the new meter initially wouldn’t work, and the app would crash. After resolving the crash issue, I discovered that all spectrum displays were missing. Upon closer inspection of peppy_remote running on Windows, the spectrum display seemed odd, unrelated to the music melody—it was purely a demo! Through communication with @nerd, it now runs perfectly. This is why I didn’t respond to everyone when it first started running on Android.
Peppy_screensaver & Remote display is a very entertaining plugin!
The large screen on the left is Volumio 4(The notebook with a touchscreen, Intel 4Gen 4G ram, is very smooth. The screen’s native resolution is 3840x2160, currently operating at 2048x1152, with a blurred border around the peppy_screensaver interface, which looks extremely elegant.), the middle screen is an Android tablet(x86) and an Android phone(Arm，Redmi Note13), and the right screen is Win10(x64).
Videos cannot be uploaded directly here (regardless of file size).
You might be mistaken; please take a closer look. This is a Buddhist symbol—it predates Hitler’s version by a very long time. The orientation is different, and it conveys a sense of dignified composure—solemnity rather than evil…
It’s not surprising, though; Westerners often lack an understanding of Eastern culture, so many people misunderstand it.
Album Title: Ethereal Sanskrit Chants II （天籁梵音 II）
I really love the themes you’ve created! I’ve been wanting to get in touch with you; I’ve made some very detailed adjustments to many of the 1920x1080-709/710/711/712 themes. If you’re interested, I can send you all the modified meter.txt files.
Thank you for putting this together. The effort is noted and appreciated.
Now, a word about scope before anyone gets ideas.
peppy_remote started life as a simple kiosk display for a Pi on a shelf. Then it grew into a full server-driven rendering surface. Then Windows arrived. Now Android is knocking on the door with a modified peppy_remote.py and a list of dependencies longer than my hospital discharge papers.
I need to draw a line, and this is me drawing it.
I am happy to review your modifications and, if they are clean and do not break the existing Linux and Windows paths, include them in the codebase with proper credit. What I am not going to do is take on maintenance and support for the Android stack. Pydroid3 quirks, Google Play authorization flows, on-screen keyboard issues, cairosvg conflicts - that stays in your court.
If it ships, it ships as community-contributed, best-effort, explicitly not a supported platform. No bug triage, no guaranteed fixes, no sleep clinic admissions for Android dreams. If it works, wonderful. If it breaks, you are the one holding the wrench. In any case, best effort to keep the code operational from my side.
That said - the screenshot looks good. The fact that the rendering runs at all on a phone is a testament to your persistence.
