Hi 7o9
it would be interesting if piggz is actually on this version himself. Else start apps from cmdline and collect logs
maybe they start from cmdline but not from grid ?
i had that issue with weatherapp
maybe its the changed config settings paths ?
Now I tried to start apps from cli:
Starting deadbeef reports on CLI:
[defaultuser@VollaPhone ~]$ deadbeef
starting deadbeef 1.8.2
server_start
searching for GUI plugins in /home/defaultuser/.local/lib64/deadbeef
searching for GUI plugins in /home/defaultuser/.local/lib/deadbeef
searching for GUI plugins in /usr/lib64/deadbeef
load_plugin_dir /usr/lib64/deadbeef: scandir found 37 files
found gui plugin ddb_gui_silica.so
added silica gui plugin
load gui plugin
checking GUI plugin: silica
found selected GUI plugin: silica
loading plugin /usr/lib64/deadbeef/ddb_gui_silica.so
[W] unknown:0 - QObject::startTimer: Timers can only be used with threads started with QThread
loading plugins from /home/defaultuser/.local/lib64/deadbeef
loading plugins from /home/defaultuser/.local/lib/deadbeef
loading plugins from /usr/lib64/deadbeef
load_plugin_dir /usr/lib64/deadbeef: scandir found 37 files
loading plugin /usr/lib64/deadbeef/aac.so
loading plugin /usr/lib64/deadbeef/adplug.so
loading plugin /usr/lib64/deadbeef/alac.so
loading plugin /usr/lib64/deadbeef/dca.so
loading plugin /usr/lib64/deadbeef/ddb_dumb.so
loading plugin /usr/lib64/deadbeef/ddb_mono2stereo.so
loading plugin /usr/lib64/deadbeef/ddb_shn.so
loading plugin /usr/lib64/deadbeef/dsp_libsrc.so
loading plugin /usr/lib64/deadbeef/ffap.so
loading plugin /usr/lib64/deadbeef/flac.so
loading plugin /usr/lib64/deadbeef/gme.so
loading plugin /usr/lib64/deadbeef/in_sc68.so
loading plugin /usr/lib64/deadbeef/lastfm.so
loading plugin /usr/lib64/deadbeef/m3u.so
loading plugin /usr/lib64/deadbeef/mms.so
loading plugin /usr/lib64/deadbeef/mp3.so
loading plugin /usr/lib64/deadbeef/mpris.so
loading plugin /usr/lib64/deadbeef/musepack.so
loading plugin /usr/lib64/deadbeef/nullout.so
loading plugin /usr/lib64/deadbeef/opus.so
loading plugin /usr/lib64/deadbeef/psf.so
loading plugin /usr/lib64/deadbeef/pulse.so
loading plugin /usr/lib64/deadbeef/sid.so
loading plugin /usr/lib64/deadbeef/sndfile.so
loading plugin /usr/lib64/deadbeef/supereq.so
loading plugin /usr/lib64/deadbeef/tta.so
loading plugin /usr/lib64/deadbeef/vfs_curl.so
loading plugin /usr/lib64/deadbeef/vfs_zip.so
loading plugin /usr/lib64/deadbeef/vorbis.so
loading plugin /usr/lib64/deadbeef/vtx.so
loading plugin /usr/lib64/deadbeef/wavpack.so
loading plugin /usr/lib64/deadbeef/wildmidi.so
loading plugin /usr/lib64/deadbeef/wma.so
starting plugin Silica GUI plugin
starting plugin AAC player
starting plugin Adplug player
starting plugin ALAC player
starting plugin dts decoder
starting plugin DUMB module player
starting plugin Mono to stereo
starting plugin Shorten player
starting plugin Resampler (Secret Rabbit Code)
starting plugin Monkey’s Audio (APE) decoder
starting plugin FLAC decoder
starting plugin Game-Music-Emu player
starting plugin SC68 player (Atari ST SNDH YM2149)
starting plugin last.fm scrobbler
starting plugin M3U and PLS support
starting plugin mms vfs
starting plugin MP3 player
starting plugin MPRISv2 plugin
starting plugin MusePack decoder
starting plugin Null output plugin
starting plugin Opus player
starting plugin PSF player using Audio Overload SDK
starting plugin PulseAudio output plugin
starting plugin SID player
starting plugin WAV/PCM player
starting plugin SuperEQ
starting plugin tta decoder
starting plugin cURL vfs
starting plugin ZIP vfs
starting plugin Ogg Vorbis decoder
starting plugin VTX player
starting plugin WavPack decoder
starting plugin WildMidi player
starting plugin WMA player
starting plugin stdio vfs
streamer_set_output
selected output plugin: PulseAudio output plugin
INFO: from file /home/defaultuser/.config/deadbeef/playlists/0.dbpl
resume: track -1 pos -1.000000 playlist -1
(process:7370): GLib-GIO-CRITICAL **: 19:26:23.688: g_dbus_connection_emit_signal: assertion ‘G_IS_DBUS_CONNECTION (connection)’ failed
[D] unknown:0 - Using Wayland-EGL
library “libpq_cust.so” not found
streamer_set_output
selected output plugin: PulseAudio output plugin
Then the Deadbeef starts but no user interaction, screen stucks.
Then a black pulldown comes:Deadbeef doesn’t react?, wait or close.
Waiting brings nothing, after closing, the following adds to the cli output:
Beendet
[defaultuser@VollaPhone ~]$
Is this helpful to find the bug, al least on this app?
It reports that ‘libpq_cust.so’ could not be found. In fact, this lib is not listed in Settings/ProductInfo/InstalledPacketsInfo. Can I get it from somewhere?
another thing that doesn’t look good is:
[W] unknown:0 - QObject::startTimer: Timers can only be used with threads started with QThread
edit: Another important thing is, the volume up + down buttons do nothing since the update to 4.4.0.68. Nothing, never, also not with the working apps.
nope:
start of harbour-olive-goes-shopping …
[defaultuser@VollaPhone ~]$ harbour-olive-goes-shopping
[D] unknown:0 - Using Wayland-EGL
library “libpq_cust.so” not found
you see missing libpq_cust.so is pretty standard
the dbus connection is more interesting
i am really no expert and dont want to fuck up my phone. somewhere in the forum is stated how to start from command line using the sailjail args
i would try that just for the fun
and i would try to modify the desktop file of deadbeef that it does not use sailjail
Adding the magic
[X-Sailjail]
Sandboxing=Disabled
to the desktop file didn’t help. With disabled Sailjail it still doesn’t work and libpq_cust.so is still missing.
I’m still on 4.4.0.64 - I’m monitoring this page:
https://repo.sailfishos.org/obs/nemo:/testing:/hw:/volla:/yggdrasil:/
after a month i have decided to give it a try again and install an older image for waydroid
however, now i can not download, or unzip the image
my system is out of space
when i do that:
rm -rf /var/lib/waydroid /home/.waydroid ~/waydroid ~/.share/waydroid ~/.local/share/applications/aydroid ~/.local/share/waydroid
i end up with 700 mb of space in system data, which is hardly sufficient to download and unzip the image
any ideas what i could clean up ?
I have only 550M space in my / so I’ve not been able to test this. Deleting stuff in .local and co. won’t really help. I wonder if the files it can be symlinked from /home/.system ? But I assume you were trying to use the
waydroid init
method? @piggz , symlinking won’t work will it?
The root filesystem on the GS290/Volla is way too small.
Yes, a problem since many years. @Jolla : Please do something that is easier to do than resizing root partition this way:
Until now, I wasn’t couraged enough to follow this howto, because I fear to brick the phone.
Also I don’t know if this howto is also working on the Volla, it’s written for the Sony.
maybe i should be more precise :
i flashed it, installed chum and then immediately waydroid so maybe that s why the installation worked in first place ?
cause now i can t download nor unzip
even though that i did remove the waydroid files before …
regarding spaceproblem:
i have solved it like that:
BUT that does not solve the issue that i would like to use an older image, not the latest and older one.
i did download it manually, but i can not tell waydroit to use it in init.
from waydroid channel i got that information
sudo rm -rf /usr/share/waydroid-extra/images
sudo ln -s /home/defaultuser/image $_
sudo waydroid init -f
creation of symlink using ln i had to do in /usr/share/waydroid-extra folder …
steps:
download wanted images (vendor and system)
unzip that
copy that into /home/defaultuser/images folder
create the symlink in waydroid-extra : devel-su ln -s /home/defaultuser/images
run waydroid init -f
btw: reset waydroid:
Reset Waydroid:
stop the waydroid-container.service # systemctl stop waydroid-container.service
cleanup sudo rm -rf /var/lib/waydroid /home/.waydroid ~/waydroid ~/.share/waydroid ~/.local/share/applications/*aydroid* ~/.local/share/waydroid
btw: i was told that one can also modify the images_path in /var/lib/waydroid/waydroid.cfg (and yes there is an entry)
and finally:
while it seems i was able to run the images that i did download, waydroid init was super quick.
runner still hangs in waiting for android ui
mental note: adb reboot-bootloader
works to send phone with antroid/vollaos to booloader mode
when fucking buttons do not work
success !!
4.3.0.15 sfos + images from 14052022
did update now to 4.4.58 with zypper and waydroid is still running
new final flow - reflashing a sfos gs290
Old Volla - GS290 / SFOS 4.4.0.72…
A few days ago, Chum reported 2 available updates for Waydroid, I installed them and now Waydroid starts and runs faster and smoother!
Many thanks to all devs!!!
Bug report - Old Volla - GS290 / SFOS 4.4.0.72…
Stock camera, Advanced camera and Fotokopierer still not working. All 3 apps crash and minimize to grid view of open apps after taking a shot.
Strange. My GS290 is running fine. I wonder if this has anything to do with the adaptation packages that both @pawel.spoon and I were missing?
I have to add (forgot to mention in previous post), that in Waydroid, the Android stock Camera and also Open Camera app is working fine.
The SF apps mentioned above also can access the cam and I can see the image on the screen. But they can’t save the image but crash as written above.
The Android cam apps are able to save the photos to Android memory.
For me it looks like all the 3 SF camera apps don’t have appropriate write access to the drive in the same way, so it is maybe not something that relies to the apps and the supporter can fix but more likely a bug in 64 bit SFOS?
The three Xperia 10’s in my family with their 32 bit SFOS are not affected by this bug, but only my 64 bit Volla.
Is there an option to install the missing packages manually via CLI and then test if the cameras bug is gone?
No, SailfishOS 4.4.0 (or in general: some A.B.C release versions) is a “stop release”. Hence one may call any point release A.B.C.x of such a “stop release” a “stop release”, but that easily confuses people into thinking that a specific point release version is relevant.
Thus you should be able to upgrade from any 4.3.0.x release to any 4.4.0.y release, i.e., from any point release of a “stop release” to any point release of next “stop release”, in general (i.e., that is how Jolla wants it to be). Release specific or device-port specific bugs may render this statement untrue.
BTW, upgrading SailfishOS in smaller steps than from a(ny) point release of the last “stop release” to the current point release or from any release to a(ny) point release of the next “stop release” sounds like voodoo to me. Again: I lack experience with community ports and release specific or device-port specific bugs may render this statement untrue.
They did: Buy an Xperia 10 II or III, flash SailfishOS and the root volume size will be 4000 MBytes. That is how they addressed this issue. Its up to the device porters to utilise the scheme Jolla developed for this, which I comprehensively described in some other Volla specific thread (“topic”) here at FSO.
Until now, I wasn’t couraged enough to follow this howto, because I fear to brick the phone.
Did you meant to address specifically the section 3.3 Increasing the “root” LVM volume size?
Well, at the beginning of section 3.3 I explicitly described how things should look, before one starts altering the LVM volumes: If they do look as described, I see no reason why this section should not be applicable.
But you cannot “brick your phone” (which means that one cannot reflash it any longer) by altering these SailfishOS specific LVM volumes: The partitioning scheme and the content of any other partition (e.g., the boot partition(s)) are not touched by following this section 3.3.
Also I don’t know if this howto is also working on the Volla, it’s written for the Sony.
Neither do I, because I do not own any of the Volla models.
Though IMO, solely the section 1.1 First steps contains mostly points, which are specifically for Sony Xperias.
If you carefully read my “Guide: Installing SailfishX on Xperias”, all sections should be applicable to any SailfishOS device, with the exception of section 1.1.
I happen to own only Xperias, hence I developed this guide on, with and for them, thus I do not claim anything else.
Feedback from users, positive and negative (e.g., criticism) is always welcome, for this guide preferably by opening a new “issue” at Gitlab.
P.S.: I still wonder why @piggz did not increase the root volume size to 4000 MBytes for his more recent ports of SailfisOS, like Jolla did for the Xperia 10 II and III. I already provided this suggestion accompanied with the technical details in some other Volla specific thread (“topic”) here at FSO.
I do see that it might turn out to be troublesome or impossible to increase the root volume size in an fully automated manner when upgrading SailfishOS etc. But to create a larger root volume when creating a new installation image for a new device appears to be quite easy: Just utilise what Jolla implemented.
Neither did I (going into details here), because I do not run any community port of SailfishOS. One porter reported years ago, that one of his users was successfully upgrading SailfishOS with sailfshos-upgrade. As stated at many places (e.g., in its README) sailfshos-upgrade is just a frontend for ssu re A.B.C.D && version --dup; if that works, one should rather use sailfshos-upgrade (because the generally recommended GUI updater cannot be used on SailfishOS ports; I always wondered why: Is it proprietary software, does it need a Jolla account to run, or is something else the reason?).
OTOH, some porters emphasise using the “zypper dance” for upgrading their port of SailfishOS. I do not know the technical details, because I do not own a device running a SailfishOS port. But I would be happy to be informed about any special requirements device ports have and will consider to take them into account in sailfishos-upgrade.
Edit: I just saw that @Seven.of.nine and @pawel.spoon both used ssu re A.B.C.D && version --dup, not the “zypper dance” ssu re A.B.C.D && zypper ref && zypper dup.
Due the usual absence of positive feedback from users, I cannot tell.
You are welcome to change that!
Side note
7o9 has already provided an unusual exception from this for another piece of software, but I general I assume that of users who experience a bug in Free Software (“FLOSS”) about every 100th reports it and of users who are fond of a specific Free Software (“FLOSS”) about every 1000th denotes this to the author(s), sometimes even spiced with some helpful information, e.g., which features are most important, what works well, what does not work well, UI design goodies and flaws etc.
A “Yes” to both aspects addressed:
these were the packages that got removed when I updated from .64 to the non-existant yggdrasil .68 …
patterns-sailfish-device-adaptation-yggdrasil
patterns-sailfish-device-configuration-yggdrasil
Try installing them.