Known from an Intel Atom configuration with the bytcr-rt5640 codec: sound “non-chipmunk” only with setting resampling to 16bit.
Doing further investigating to make this work out-of-the-box (may not work for all rt5640 devices).
Also for SBCs with only WiFi like the PiZero and OpiLite… 
Low hanging fruit, as it isn’t critical, but should be fixed in
Regarding “Plugin Lifecycle”:
If the promise is rejected in the “onStart” function of a plugin the red dot in “Plugins Management” shows the plugin “inactive” while the switch is set to “On” position.
After reloading the “Installed Plugins” page the dot is green and status shown as “active”. Accordingly in /data/configuration/plugins.json the value for “enabled” is “true” and the value for “status” is “STARTED”.
I think this is the same on Volumio 2 but shouldn’t the plugin remain disabled (switch position “Off”) and its status be “inactive” if it fails to start?
Hi all,
could it be made possible to integrate an option to „retry to start a plugin that is only available in dev mode“ ?
I guess this could be helpful for testing and therefore for the plugin devs as well
br
Josef
Hi,
when uploading a new background jpg image (appearance menu)
there is no preview icon generated
Version:
- Volumiobuster-3.053-2021-03-06-x86_amd64.img
- Volumiobuster-3.054-2021-03-09-x86_amd64.img
- Volumiobuster-3.055-2021-03-12-x86_amd64.img
It looks like this:
You are able to use the new background but the preview icon is not generated.
I am able to upload a background file “picture.jpg” and a 300x200 px “thumbnail-picture.jpg” via the UI - then it looks fine. 
It’s the generation process after the initiial upload, that’s not working.
May be this snippet out of the logfile can help… Is it because thumbnails are generated by a plugin and the plugin system is not included in this beta yet?
Mar 13 16:28:01 smx volumio[735]: Uploading: Klingenberg004.jpg
Mar 13 16:28:01 smx volumio[735]: Background Successfully Uploaded
Mar 13 16:28:01 smx volumio[735]: info: CoreCommandRouter::executeOnPlugin: appearance , generateThumbnails
Mar 13 16:28:01 smx volumio[735]: info: CoreCommandRouter::executeOnPlugin: appearance , getBackgrounds
Mar 13 16:28:01 smx volumio[735]: error: Failed to generate thumbnails: ReferenceError: f is not defined
Cheers,
Robert
edit 2021-05-11 :
This issue is solved in 2021-05-07-x86_amd64-volumiobuster-3.073
Hi,
in version Volumiobuster-3.055-2021-03-12-x86_amd64.img
there is some i18n / l10n information missing.
When navigating to a certain artist in TIDAL the chapter headlines are not available. Instead of the translated text the variable names are displayed:
TRANSLATE.COMMON.ALBUMS
TRANSLATE.COMMON.EPSINGLES
TRANSLATE.COMMON.TRACKS
I tried German and English - the texts are missing there and probably in other languages as well.
Cheers,
Robert
Same issue:
edit 2021-05-11
This issue is NOT solved in 2021-05-07-x86_amd64-volumiobuster-3.073
edit 2021-05-22
This issue has not been solved in Volumiobuster-3.077-2021-05-20-x86_amd64.zip
Not sure if this is a Buster specific problem, but it is here in both Arm & x86 that I have noticed that on the hotspot running on first boot with the ‘first config wizard’, the chosen wifi network password field is not visible on my Android mobile (but occasionally is, just to be awkward ). I can see it ok on a connected laptop, but even here the field is very far to the right (outlying the green border lines).
Tidal playback stops after playing one song (6 seconds before the end if this song) in a list of songs (i.e. an album)
http://logs.volumio.org/volumiobuster/8PzDE2t.html
Version: Volumio beta 3.055 (Volumiobuster-3.055-2021-03-12-x86_amd64.zip)
Today everything is working fine again with Tidal.
Seems to be a server-based problem that apparently has been solved…
Cheers,
Robert
Hi,
now I see the “Tidal problem” again. Every time I start a sequence of songs (i.e. an album) playback of Tidal stops after he first or the second song in the list. After that playback is not possible until I wait a few minutes and start a single song or I change the Playback Potions to another output device.
Since I didn’t see such things over the last couple of months I’m now tending to the opinoin that this issue has its cause in the beta program.
May be somewhere in MPD or ALSA ?
Version: Volumiobuster-3.055-2021-03-12-x86_amd64
Log:
http://logs.volumio.org/volumiobuster/2s7PpHb.html
In a intermediate version out of december 2020 (2.857) the playback and UI (tidal, albums, webradio, etc.) is completely stable and robust.
There is definitely an issue with the beta 3.x regarding playback of tidal / albums…
Here’s a log (Volumiobuster-3.058-2021-04-10-x86_amd64.img) when this problems (playback of WEBradio and Tidal noch stable) occur:
http://logs.volumio.org/volumiobuster/8n12AL3.html
2021-04-13: (Volumiobuster-3.055-2021-03-12-x86_amd64)
Tidal is stopping again - 6s before the end of the track playback mutes, then no further playback is possible…
http://logs.volumio.org/volumiobuster/gKNyzHl.html
Cheers,
Robert
Hello
i just started installing Volumiobuster-3.073-2021-05-07-x86_amd64on my Volumio 2 Systems.
On an Intel X86 System ( Asus P5G41T/M_LX3 MB, Core 2 duo, 6GB) most of the time everything works fine ( except known issues) , but sometimes the Media Servers ( Synology 920 NAS) ist not shown - even when i play music from that NAS ( because the link is still stored from the last session) at the same time or from Internet Radio - so Networking is o.k. !.
I had that just once after app 10 restarts. I run Volumio Buster form SSD - the system has no USB 3 and boots very slow from USB 2 so i copied the system on a small SSD.
(Thats a very good option to do that from Volumio itself)
Waiting for some minutes did not help.
This post is a “Volumio 3 beta for x86” issue, not a general one.
Please post this again and stick to the rules outlined in the first post of the “Volumio 3 for x86” thread.
We need hardware info and logs, without it we are not able to offer support.
The user interface had numerous display issues when running the setup wizard. Controls, especially drop-down menus would disappear when I clicked on them, then reappear, only to disappear again after attempting again to access them.
I noticed the browser attempting to connect to external web sites. It was failing, of course, because my only network interface was attached directly to the device operating as an access point. My browser had no outside access. I eventually succeeded by attaching a second WiFi controller, a USB device, I had available, to maintain the separate WiFi connections. Plainly this option is not always available.
Generally, a device controlled through a web interface should be able to serve the entire interface internally. Expecting either the device or the client to have internet access at all times when attempting to control the device presents to me as a bad design choice.
I may be misunderstanding the design based on a few small observation available to me, but I certainly stand by the recommendation to maintain a design free from internet dependencies.
I would recommend you to read the very first post of the beta test instead of complaining. In case you have difficulties with the quality of the beta, you should not have joined the beta program.
@gkkpch: Are you referring to the post that begins with the following invitation?:
Help us improve the Volumio experience … let us know what works & what doesn’t.
Sorry, I’m not understanding your objection. A beta program involves developers receiving feedback from testers, and you have given a reference to an outline of the particular rules of the current testing program.
I had similar problems, but couldn’t figure out what was going on. Good catch! This would explain most of the setup problems I was having.