How about force install ( apt-get -fy install chromium-browser ) ?
gonna try macmpi maybe that works…
volumio@volumio:~$ sudo apt-get -fy install chromium-browser
Reading package lists… Done
Building dependency tree
Reading state information… Done
chromium-browser is already the newest version (78.0.3904.108-rpt1).
0 upgraded, 0 newly installed, 0 to remove and 23 not upgraded.
both did nothing… new guess please …
so the by hand installed plugins show but the one the official plugin store not…
bit funny first we have it other way around …
Reason for my test was to find out if the same error (“E: Unable to correct problems, you have held broken packages.”) ashthespy experienced on a buster beta also occurs on a Jessie based system.
The “-f” option could be interesting for future install scripts though I am hesitating because it might complicate hunting down errors if packages get installed despite missing/broken dependencies and then not working.
I guess macmpi’s post about force installing was not directed at your issues.
Why did you try to install chromium-browser again? According to your earlier post I thought the touch display plugin was working now…
Edit: Culprit is the version number “1.1.9beta02”, specifically the “beta02” part…
The new zip file you find below was packaged on the latest buster beta image 3.010-2020-08-21-pi and has the plain version number 1.1.9. Its files are identical with version 1.1.9 of the plugin from the plugin store with the exception of the install and uninstall scripts which take care of the differing hardware ID used in the buster betas for Raspberry Pis.
@macmpi I modified the install script of the touch display plugin by removing all fake package related lines and adding the proposed -f option to apt-get -y install chromium-browser but chromium-browser failed installing. From journalctl:
info: chromium-browser : Depends: libraspberrypi0 but it is not going to be installed
Hello to all,
Currently I am using test version 2.847. I use button plugin, led for status volumio and rpi4 status, when is powered on. My connection is wired Lan… Also I am using 4.3 inch dsi touchscreen and mpd oled script on an 1.3 inch oled.
I would like to switch to buster image due to python 3 version cause I would like to install mpd2chromecast and peppy meter.
If I will switch to beta buster image I will be able to still use the configuration from above and of course new qobuz beta mode or when new implementation from qobuz will be released officially I still be able to use it on this new buster image?
Thanks in advance
You should go with the Nodev8 version (please see the first post) build then to ensure you don’t have to recompile core modules for those plugins.
Hmm, Unfortunately at this stage there all the MyVolumio stuff is untested with Buster. I built a test image a few months back, but since it contains closed source things, I would rather someone from the core Volumio team check and then release that image
Kernel 5.x+ does not load the “rpi_ft5406” module anymore but the “raspberrypi_ts” module when a Raspberry Pi Foundation touchscreen is connected. This required an adaption of the Touch Display plugin: touch_display_1_2_1Busterbeta.zip (793,3 KB)
it’s still running over here ash it’s missing some folders for the plugin’s but
runs mutch better than the latest release i can say …
yt plugin (doesn’t search yt any more), auto start, system,
touch display, local music and radio runs well …
it’s for me the best release only you have to do all by hand…
ash are you still working on the 3.10 or is it gone?
I tested Volumio 3.0 and found that:
The operating system runs really well, and it’s fast, the sound seems pure.
Stores USB scan history
the big downside I see all volumio versions have is: the boot speed is very slow when the music files increase for example:
Hard drive contains 1T of music: boot speed is: 1 min 30 s. 2 Tb music: 2 minutes. This is bad, because I tried the Moodeaudio, it was very smart, it stored the first scan and the boot time was very fast, only 50 S, and regardless of the number of songs and hard drive space!
So can you handle this? ie the start-up speed is independent of the number of music files, and retains the first scan history ??
Thank you very much!
What pi are you running this on?
This is a pet project that I would like to investigate - the slowdown during boot due to database scanning. It’s some quirk with the async code. However, I don’t really have a large music collection, as I mostly stream these days. So if you don’t mind - could you share your /var/lib/mpd/tag_cache (privately) with me? I’d like to play around a bit to see where the bottleneck is