I have the same issue on up-to-date Arch. Now using last stable version working for me - 65.0.3467.69.
I also think it's an engine issue - seems other browsers based on Chrome/Chromium, Vivaldi i.e., are affected by the exact same problem.
Thank you for your quick answer.
I was just getting ready to rename the profile when a security update for opera snowed in.
It was Version 66.0.3515.44 on Ubuntu 18.04.3
So I decided to reinstall it completely with the new version - and now it works!
And thank you also for the backup tip - I saved my bookmarks before which is the most important for me.
@thomasmca Thank you. In fact it was just a matter of time: I left it over the night, and in the morning it was synced. Still, weird that the process was completely blocked for over an hour. I'm not sure your approach would have worked, since the OS is different - and I didn't really backup my dot folders. blush
@metarhyme You're welcome ;-)
Please keep in mind, that in some other cases in the future, you can try to disable some lists in the ad-blocker, to check which one exactly causes a trouble. That way (disabling a list, instead of switching off ad-blocker for a specific site), it may help to avoid the same or similar issue on the other sites.
It is actually happening on all videos, not just 60fps. opera://media-internals report this:
debug ISO-BMFF container metadata for video frame indicates that the frame is a keyframe, but the video frame contents indicate the opposite
I think this error is related to the frame drop. I installed Opera through Manjaro software center (pamac). opera-ffmpeg-codecs 78.0.3904.108-1 installed with it.
@inuxl said in Zombie process associate with "Opera autoupdate":
I am encountering the same problem on Arch Linux. The parent Opera process is spawning zombies with the process name "opera_autoupdate"; 41 zombies before system halt. Is there a configuration flag that can be set to turn off the autoupdater?
@leocg Opera really should reconsider this. At least let people enable it in opera://flags/ if security is the issue. This is really annoying because there are multiple problems with locking the default engines.
I can't even edit/remove the keyword. For example I can't use "y something" to make a youtube search because y is locked to yahoo.
I can't disable default search engines. So if I search for example "y u no meme", again, it will take me to yahoo.
I can't set the URL. Even though I use duckduckgo as default, it's still a problem because I can't set URL parameters like ?kae=d to use dark theme in incognito mode (making the feature useless).
And, like others said, they can't use startpage or other engines. What if I want to use Google, but the japanese version or whatever? Where's my freedom? I though I had the right to make my own choices...?
All of this would be solved if they would just let users freely choose their defaults, like every other browser does. Sure, if Opera has a deal with those companies to list them as default, that's fine, but don't make it IMPOSSIBLE to change it.
It doesn't matter if it's cumbersome and non-intuitive, and if I have to use admin/root, edit some obscure file, change the registry, konami cheat code or whatever, at least let people have SOME WAY to do it.
Enabling a flag would be a good solution, since the page already warns you that changes might compromise your security anyways.
The .build-id is a directory of softlinks and they look like this:
lrwxrwxrwx. 1 root root 54 20. Dez 22:23 e9a8d27f5302d758a054547555d5d651bbfcab -> ../../../../usr/lib64/opera-beta/swiftshader/libEGL.so
You see the related opera-beta in there. So the softlink links to this directory:
[burni@f31 swiftshader]$ pwd
[burni@f31 swiftshader]$ ls -la
drwxr-xr-x. 2 root root 4096 11. Jan 05:14 .
drwxr-xr-x. 5 root root 4096 11. Jan 05:14 ..
-rwxr-xr-x. 1 root root 244592 20. Dez 22:23 libEGL.so
-rwxr-xr-x. 1 root root 3256368 20. Dez 22:23 libGLESv2.so
Ok! So, when i try to update, this happens:
Fehler: Transaction test error:
Datei /usr/lib/.build-id/1d/e9a8d27f5302d758a054547555d5d651bbfcab aus der Installation von opera-stable-66.0.3515.27-0.x86_64 kollidiert mit der Datei aus dem Paket opera-beta-66.0.3515.21-0.x86_64
...which basically means in my opinion, that the softlink that referred to opera-beta would refer to opera-stable after an update. From a technical point of view, it may be possible to run opera-stable and it silently uses the libGL.so from opera-beta (or the other way around)
BUT... dnf doesn't like those kinds of work ethics.
And therefore Opera should do, what the have done before, in older Opera versions:
Letzte Prüfung auf abgelaufene Metadaten: vor 0:47:12 am So 12 Jan 2020 18:24:58 CET.
opera-beta.x86_64 66.0.3515.21-0 @opera
opera-developer.x86_64 67.0.3523.0-0 @@commandline
opera-stable.x86_64 65.0.3467.69-0 @@commandline
opera-beta.i386 45.0.2552.634-0 opera
opera-developer.i386 46.0.2573.0-0 opera
opera-developer.x86_64 67.0.3564.0-0 opera
opera-stable.i386 45.0.2552.898-0 opera
opera-stable.x86_64 66.0.3515.27-0 opera
As you can see, the older versions are installed (installed from downloaded rpm-Packages, not from repository, you recognize it by the @@commandline) they dont have a problem with .build-id at all. And it managed to have at least opera-beta installed from opera-repository.
So, Opera Software should consider reverting their changes back to where they came from.