but if i want to restore an backup, the system crashes...
A backup of an image or a backup of your settings? The system hangs because of a wrong configured mount file which you can't repair by restoring some settings.
Either you reboot the system several times until it randomly boots up under upload the update or you pull the sdcard and copy the update with a Linux distribution.
Or what do you mean exactly?
does the new builds works better on rockchip? There was a bug, and i cant restore from backup or copy file to the box...
Systemd handles some file system mount points now differently which lead to some quirks. If you have access to the sdcard filesystem you can copy the new image directly into the .update folder and boot then. Use any Linux live distribution for that and open the filesystem as root for that.
Otherwise just reboot the system a few times it then randomly comes up with the broken image and apply an update then.
Anyway I have to upload a clean build tomorrow first. Otherwise the build should basically work fine. It lacks some refresh rate setting functionality for standalone emulators which I have to implement in some way later.
Build RR-20190522-5448d50 | Generic testbuild | Index of /testing/nvidia-430.14/
It's doctor crazy, back again. You know, making up a lot of stuff doesn't actually make you right you know? For your information, ninja didn't exist in LE 8.2, I manually backported it and as a result I turned it off in packages that already compiled.
Unlike you, I can actually use my brain and figure things out. The isystem sed is my original as you can see here: Problems cross compiling Dolphin for LibreELEC
I found hints to the issue in the GCC bugtracker and experimented with the compiler command. This was copied by Lakka (which is mentioned when they added it) and yourself. Oh yeah, great thinking, of course I wouldn't be able to apply my own sed expression to flags.ninja instead of flags.make. You're a genius!!
Get back to your version bumping and copying ok, and stop polluting my thread.
Again, you're welcome for everything that's in your build.
So when I stop reacting here you start to write private messages. Congrats. I'm pretty sure it's obvious who's craving for attention & maybe has some ADHD issues. 
About the rest -> check the date of the commit & the topic it resolves. Months before you came up with your solution others already used quite the same and since you've asking for help in the dolphin forum I suspect you haven't been able to fix this instantly on your own.
It's not like other packages hadn't similiar problems with -isystem flags which resulted in missing <stdlib.h> and it's not like others were able to solve these problems independently. Whether you backported ninja or not doesn't matter you disabled it for a package that builds with ninja once you apply "your own sed expression" with slightly changes which amazes me because you could have easily fixed this issue. But you didn't.
Once again I'm tired of this whole thing. I see you can't or won't stop making up stories which is fine as long as you don't bother me about that.
Well I tried to stay out of this and thought he will grow up at some point and stop to constantly spread so stories he made up. To make things clear when I started to rebase his project he wasn't quite active at all. He played not a crucial part when I rebased nor provided crucial help over time. I was able to fix things up in the past and will be able to introduce new stuff if it makes sense or someone asks for it as in the past. Normally I would keep him bullshitting because for unknown reasons it looks like he's satisfied by this but I thought at least that he'll keep his opinion to this thread.
So here we are for some humiliation 
These flags fixed the compilation of the dolphin & ppsspp package with cmake & ninja. I'm not sure why he highlights both lines because he never used the ninja fix in the past but rather disabled this toolchain. 
LibreELEC.tv/package.mk at libreelec-9.x-rr-working-tree · 5schatten/LibreELEC.tv · GitHub
LibreELEC.tv/package.mk at libreelec-9.x-rr-working-tree · 5schatten/LibreELEC.tv · GitHub
The interesting point is that while he uses the ninja fix in his current ppsspp package too
RetroELEC/package.mk at le9 · escalade/RetroELEC · GitHub
he was not able to fix this stuff back in the days for dolphin
RetroELEC/package.mk at le82 · escalade/RetroELEC · GitHub
Now maybe someone else used this fix before in his packages....
dolphin: updated to r5.0-9275 / fixed ninja build · 5schatten/LibreELEC.tv@7030e05 · GitHub
So let's check when he added this cmake, not ninja, fix to the good old dolphin package... this happened here
dolphin: update to c259469 · escalade/RetroELEC@de87168 · GitHub
and not really a surprise for me others used pretty much the same fix for a similar purpose
build-style cmake: replace -isystem with -I · void-linux/void-packages@8679124 · GitHub
So as we all see this was pretty much humiliating. I hope you aren't to harsh to "pullmoll" when you tell him that he used a quite similar code for a similar problem before you did.
And about the rest I would really appreciate if you either stop making up stories or if you would at least tell the people who inspired you if you had a "genius idea" how to fix some build problems.
I've learned a lot from you guys and I am sure you guys learned even a little bit from me, even if you didn't knew it. I have the upmost respect for all the people working in LE, CE, LERR, RetroELEC and other builds/distros, and I appreciate it a lot. So lets just all keep sharing and creating which helps us learn and make better things!
On point and without your work I probably wouldn't have Pegasus too 
We _are_ forks, and insignificant to the LibreELEC project. Relax.
OK, then just do the change log part right, and everything is fine.
Compared to the amount of actual users we are pretty much just the 0.x% of generic users so in fact not that important for vanilla LE.
But since we build based on the master branch we're like milhouses testbuilds good bug catchers because we'll run into issues at first.
escalade
I remember a former Trolltech employee who failed to build Qt5. About the other stories well as I said I'm out 
Well I don't need a medal, I do it for free and normally without trying to get attention for it...
It's funny how you mix up some things. Retroarch failed and not SDL2. Retroarch stated that no platform was defined in eglplatform.h and gave you this error add include, lib and pkgconfig files · LibreELEC/libmali@128aeea · GitHub so it's time for captain obvious that either -DWL_EGL_PLATFORM or -D__GBM__had to be defined to select the platform which is in use. You did this in project CFLAGS iirc and I in Retroarch independently from your solution. I added it later to project CFLAGS too because Qt5 also failed to detect the correct platform but already talked to kwibo about a proper solution, so fix up libmali and not enforcing some flags. You know that and I know that too.
You just brought up the topic that SDL2 fails for you but so I added these symlinks just in case others have the same problem. My platform detection looks like this
Rebasing does not mean copying "your" stuff and if your stuff is basically a 1:1 copy of Lakka packages in many cases. I'm not sure if it should be called your stuff at all. If it comes to your scripts you see yourself what I reused which basically comes down to the basic launch command and some opts if any. And fun fact even once I've rewritten the whole script I still kept "your" copyright which basically means they share /usr/bin/start.sh opts "@" in most cases
Again I didn't took your "solutions" which meant local fixes. I've talked to others about the libs which might be needed and later my PR was partly changed install glesv1_cm pkg-config · LibreELEC/libmali@edf6f17 · GitHub to have proper pkgconfig too. The point is if we ran into somewhat similar problems it does not mean that you're the only one who is able to read some manuals and docs or browse some header files find the fix.
I said you copied my stuff (which you did) and then you got all triggered for some reason.
Well I don't know if copy has different meaning for you but it implies I just copied all your files to LE 9 and that's it. The question was what the difference between these builds are and saying my build is just a copy of yours with some frontends is pretty much wrong. If you really think there are not much differences as you stated then feel free to think that but as I pointed out there are plenty of benefits & fixes compared to your builds from the past. Well beside the fact that you did not even mentioned missing Qt5 in your builds which means no recent Dolphin or Citra standalone emulators which either allow proper Wii gaming or double the performance for N3DS games... if this is "not much" then well yeah...
Hey guys, this looks like a fight before a fork. Scary. Don't forget: users don't care about intellectual ownership, and you both know (or belief to know) what you did. So, forget the past and start writing change logs. Peace!
As I said it's not a secret that I used rebased packages for my build and reworked basically everything I reused so saying there is not much different just copied packages & "several frontends" is quite offending if you ask me.
I guess everyone has his point proven and in the end I only care that there is a proper image which brings some fun. So I'm out of here. 
Hold your horses there, I'm not the one having a real hard time admitting he copied my stuff. I did indeed borrow and straight up copy a lot of things, you want to tell me where I try taking credit for it?
Here's you PR'ing what I gave to you without any mention: CMakeList.txt: added symlinks for libGLES_CM.so.1 & libGLESv1_CM.so.1 by 5schatten · Pull Request #4 · LibreELEC/libmali · GitHub
It's funny that you bring up PCSX2, adding some verbosity to my pcsx2.start script does not change the fact that I'm the one who wrote it in the first place. The relevant part is exactly the same. I put in the time reading Docker documentation, creating containers and experimenting with ALSA and Pulse to see what I needed to pass to the container, here you are acting like you did anything meaningful. Like bumping the Docker version, as if that's rocket scienc3. The real work was done by lrusak back in the day, which I'm very thankful for.
I could go on and pick apart all the ridiculous claims you are making, but I'm gonna save you the embarassment. It's indeed completely immature, and I have other things to do with my time than "proving" that you copied my stuff which you very clearly did. It's great, take what I have made and improve it any way you can but trying to take credit for it is simply pathetic.
As you said... rocket scienc3... bumping Docker 18.09.03 to 18.09.04 is simple. Bumping major versions not. You would know that if you had done this lately.
It's not like minimal Docker images for arch were around for quite some time... https://github.com/yantis/docker-archlinux-tiny/blob/master/dockerfileAnd as I said I'm updating Docker not that I created it in the first place. But nobody else cares about it, it's basically like Nvidia and X11. I also never said that I was the guy who "developed" the Docker image but I reworked the start script to install defined versions, clean up & update the image as needed. Well the stuff you call verbosity. Again it's totally fine if you're maintaining your htpcs per terminal & ssh but if you're a Nvidia user you need a defined version which matches your LE driver. Without this PCSX2 won't work for them, I know you never bothered much about these users but I did.
Beside that it's not like I haven't already talked to others about libmali changes... CMakelists.txt add symlink for libmali.so.0 by chewitt · Pull Request #2 · LibreELEC/libmali · GitHub eglplatform.h: if WL_EGL_PLATFORM is not defined use GBM by 5schatten · Pull Request #3 · LibreELEC/libmali · GitHub so congrats adding OpenGLES 1.0 compat files which basically nothing uses would not have been possible, nobody already thought about symlinks for files the khronos documentaion mentioned. But I guess we have a different perspective about these topics. You apply some patches or CFLAGS to locally fix some flaws while I try to fix them upstream so that everyone benefits and somewhat proper functionality is given.
The point is I know that others use my packages too, as you do, i.e. for builds niabi supplies or the upcoming lakka branch does. I do the same and if I just copy paste them then I keep the copyright or add it. Something you've not done in the past iirc. But I don't say meh they just copied my packages, my work and added some frontends. But that's exactly what you do. You don't mention that you copied my fixed packages or took them as "inspiration", i.e. what about ppsspp? Is it a coincedance that you end up with this patch RetroELEC/ppsspp-fix-fmv-stutter.patch at le9 · escalade/RetroELEC · GitHub so you tell me that you ended up here and created a patch that used the same name scheme without numbers or do you admit that you might have taken some inspiration elsewhere ppsspp: switch to PPSSPP (SDL2) standalone build · 5schatten/LibreELEC.tv@5650c99 · GitHub?
Instead of admitting that everyone benefits from everyone you act as if you've invented the wheel which is just not true. But well such a behaviour is probably pathetic, indeed. So let's end this waste of time. Keep on silently copying and blame others that they just copy your entire work...
Feel free to post as much pathetic nonsense you want, quite entertaining.
Unless you proof me wrong I wouldn't exactly say it's pathetic. It's more like you tried to take credit for work others did and once someone points this out you behave somewhat immature. Anyway this will lead to nothing so have fun & you're welcome
Probably looks like that to a delusional copycat like yourself. Yes let’s get back on topic and you can go back to watching my commit log and figuring out how to take credit for it. I’m flattered.
Feel free to ignore the facts Where are your standalone packages for DolphinQt, Citra, PPSSPP, Mupen64Plus or Hatari? Where is a config tool? Where are autoupdates? Where is the whole Qt5 stuff? Don't you think I'm aware where you've got the "inspiration" of a lot of your packages? I guess I wouldn't have recognize the similarities to Retropie or to the Lakka branch if I hadn't reworked every single package...
Basically you accuse me that I just have copied your packages so you tell the users that this
RetroELEC/pcsx2.start at le82 · escalade/RetroELEC · GitHub
equals this
what is In my humble opinion pretty much incorrect and I think everyone who is not blind will see that I've reworked the package to improve the functionality.
I started my work on a LE 9 based build over one year ago so it's quite funny why I would need to watch your commit log while my builds with stable Kodi point releases where available for months before you even started your rebase? And have you checked LE upstream code where is your late contribution? Some SAMBA fixes back in 2017? Congrats.
Last time I've ran your build in 2017 not even the splash screen worked, so much about that 
Feel free to think whatever you like but let's get real.
It’s becoming clear to me that you are either smoking some next level drug or stopped taking your medication. Hope you get well guy.
Looks like I hit the bullseye I'm fine thx & hope you're well too.
So let's end this rather pointless discussion & back to the main topic.
Oh yeah, correction, you copied my packages and added a PKG_TOOLCHAIN=make/configure/autotools here and there. Pretty much everything you mention you've also gotten from me, down to the launcher scripts, configure options and methods I have used to deal with different things. Much like I copied a lot of things from Lakka when I started, which I certainly give them credit for.
You're seriously trying to take credit for the Docker addon that lrusak created as well? This is getting ridiculous. You bumped the version variable on somebody else's work, congratulations. All I'm seeing is 0 respect for the work others have put in, you've even PR'ed stuff you got from me without so much as a mention. Good job!
You are welcome by the way.
Last time we talked in slack you were pretty surprised about the multithreaded build or the LTO changes that broke your build obviously it's enough to PKG_TOOLCHAIN=make/configure/autotools here and there Seems like you either forget about your own problems or pretend that rebasing is just a matter of copy and paste 
I know that a lot of packages were direct copies from other projects because that's the way it goes.
AlexELEC-AML/package.mk at master · AlexELEC/AlexELEC-AML · GitHub
RetroELEC/package.mk at le82 · escalade/RetroELEC · GitHub
Even the superflous lua dependency was copied and also the wrong lib installation path because if you update the package the vlc libs won't update too in that path.
Have you ever read my start post in my thread that literally states:
I really enjoyed Escalades LE 8.0 Remix which was an attempt to melt all good stuff into a single system but if you look into detail the 8.2.x base is pretty outdated. I've felt it's time to rebase the Remix build.
I never claimed the copyright in the first place when I rebased the packages which meant reworking most of them. I even kept the copyright in my vlc package that was inspired by "yours" LibreELEC.tv/package.mk at libreelec-9.x-rr · 5schatten/LibreELEC.tv · GitHub and I asked you in the past if you're fine when I add your copyright in the addons too. You could have mention that you've just copy & pasted the packages and I would have probably used the correct one. Nowadays I drop it once the package is basically completely different from where it started and if it does not even contain any config opts a copyright is probably not necessary at all.
I took credit for updating it not creating it. Last time Lukas bumped Docker was back in february 2017 & rayelec bumped it last time in november 2017. If you think updating Docker is just changing the PKG_VERSION why did you never do it? I asked in the slack Docker channel for some support and guidance and basically nobody cared about Docker and I even dropping it was an option if it would not work anymore. The reason why nobody cares is simple. Docker is a mess & unfortunately I couldn't just copy and paste these commits.
docker: update to 18.06.1-ce · LibreELEC/LibreELEC.tv@3f6bf98 · GitHub
docker: updated to 18.09.1 · LibreELEC/LibreELEC.tv@040024f · GitHub
No offense but I know the origin of many if not all packages and you know it too. I appreciate your work but don't pretend that you've reinvented the wheel neither did I or did you. We all check other projects, how they solved problems and adjust those solutions if necessary.
Feel free to explain me what I could have PR'ed what you have created? You're probably referring to wayland? Well this was my PR [Wayland] updated all Wayland packages, dependencies & patches by 5schatten · Pull Request #3497 · LibreELEC/LibreELEC.tv · GitHub so explain me:
Where is your libva-utils patch?
RetroELEC/packages/debug/libva-utils at le9 · escalade/RetroELEC · GitHub
Where is the fix to build Kodi?
RetroELEC/package.mk at le9 · escalade/RetroELEC · GitHub
Where is your updated Kodi audio patch?
RetroELEC/kodi-100.14-use-alsa-and-pulse-together.patch at le9 · escalade/RetroELEC · GitHub
Where is your intel-vaapi-driver patch?
RetroELEC/packages/multimedia/intel-vaapi-driver at le9 · escalade/RetroELEC · GitHub
Where is your pugixml package?
waylandpp: update to 0.2.5 · escalade/RetroELEC@64c0996 · GitHub
Where did you update the weston toolchain?
weston: update to 6.0.0 · escalade/RetroELEC@74622ad · GitHub
Shall I go on? Or what did you have in mind? At the current state I hardly doubt that your wayland build will compile and run fine on generic systems, maybe audio works because of your PA config but then again passthrough is broken. I'm talking for ages now to Lukas and others and do some lobbying for X11 so maybe a branch keep the displayserver or at least a working alternative like Wayland/Weston is available for non-libretro stuff & add-ons like Chrome or Spotify.
By the way I started on a PR for Wayland because of this Kodi PR X11: remove vdpau and glx by lrusak · Pull Request #16057 · xbmc/xbmc · GitHub and not because you've randomly bumped some Wayland related packages.
EDIT: I can add that as I'm basically leeching off the excellent work the LE team is doing,
On point. So don't pretend you've reinvented the wheel. To me this discussion in pretty much pointless. If you think I just copy & pasted your work then well go on and think what you want. If you would have ever tried my build then you would have known that there are plenty of under the hood changes that make things easier.
You are welcome too.
Not much I suppose, as he copied most of my packages. He also includes several other frontends and afaik some configurability of settings through Kodi. I'm focused on simplicity and optimization, also I will mostly be releasing builds without Kodi.
Well it is indeed true that I forked the LE 8.x remix build and just updated the packages which were provided by the original build but I wouldn't exactly say I've copied them for the Le 9 build because that just wouldn't work. As you know the build system has been reworked fundamentally and most of the old packages would not build without reworking them. In the end everyone who tries to achieve the same experience and functionality will have to satisfy the same package dependencies and so will use somewhat similar packages. In the end many of my packages were inspired by other distros which is obvious since you need them to build other packages too. I guess you agree that you've taken a lot of inspiration from Lakka or Retropie, Recalbox or Arch Linux Many packages were LE libretro packages which needed to be reworked because Retroplayer does not support OpenGL/ES so they have never been used in Kodi/LE.
Soon i'll try your build but i really don't know what the difference is between your build and 5schatten his build.
The main difference is that I also build images for Amlogic & Rockchip devices and I'm focused on an extended LibreELEC build so I'll stick as closely as possible to LE. Since one of my main emulation priority is Dolphin I had to add the Qt5 framework which allows me to add additional standalone emulators like Citra, a mupen64plus-gui for standalone mupen64plus, useful tools like Skyscraper to scrape game assets and also an additional frontend like Pegasus.
If it comes to the emulated systems I added oldschool Atari 2600 & 5200 stuff and Hatari as standalone Atari ST emulator because user asked for this. I've added a variety of libretro cores to allow users to pick their prefered core to satisfy their needs and solve some problems. For example on oldschool Intel devices which lack the latest OpenGL version libretro-mupen64plus won't start but you can use mupen64plus instead.
I reworked basically all scripts to use functions in profile.d instead of repeating these scripts over and over in every start script which makes it easier to debug stuff and speeds up builds because if I change some PulseAudio init the depending package doesn't rebuild and just the profile script will be copied for example.
Basically all standalone emulation start scripts were completely overhauled by me to allow proper handling of different file types. For example all of them should handle ipf, zip or conf files without any user interaction. For ARM based systems Amiberry is used which also fully supports WHDLoad and detects automatically if a file is just a compressed floppy image or a whdload file.
Because users asked for video snaps I fixed the VLC package which was originally broken for this particular usecase, I added mmal patches to allow RPi systems to play videos without black screens too. Because of this changes it was for my usecase inevitable to use PulseAudio for audio mixing so I also reworked to scripts & emulator configs to use either ALSA or PulseAudio depending on your needs. Since PA was used for emulation as a benefit I added FluidSynth as synthesizer which allows you to use MIDI emulation in RA out of the box and also DOSBox can play MIDI sound without any other bios or rom files.
The main difference to escalades recent build is that I only use PA for emulation so I automatically create sinks once the frontends or emulators start & delete them once you finished playing. This approach makes sure that standard LibreELEC configs work fine and also addons won't run into trouble. Another reason to use it this way is that without further PA plugins audio passthrough won't work once you use PA instead of the ALSA sink which is pretty bad if you use Kodi for home entertainment. Another point is that I offer two options for PA so either autodetection which works fine on simple system configurations but once you have different audio cards attached or use your dedicated GPU as output device you should be able to chose a proper output instead of relying on autodetection. Same goes for the tsched option, some sound devices need tesched to be disabled to avoid crackling sound, some need it to have proper sound. Well so it makes sense to allow you to enable or disable it depending on your needs.
Since the standalone emulators need specific refresh rates for PAL or NTSC games I added scripts that make sure that they start with correct rates. For example if you start Dolphin PAL60 or NTSC games while your refresh rate is still set to 50Hz it stutters like hell.
I added Vulkan libs for Nvidia drivers which allow you to use the Vulkan backend too. Since we're talking about Nvidia I've also tested and tinkered until I found out why PCSX2 did not run for them. The reason was that the Docker container and the LE Nvida drivers differed and so PCSX2 failed to init OpenGL. So I further reworked the PCSX2 start scripts which now pull a specific Docker image version instead of just the latest one, it also cleans up old Docker images and makes sure that it'll update if a new version if available. It's indeed true that escalade was the first who created a Docker image for PCSX2 And I'm glad he makes use of the Docker addon I regularly update for LibreELEC 
I just ironed out some stuff I did not liked or which were not suitable for everday usage. For example when I tried to fix the Nvida drivers I've rebuild the image countless times but so every user who tried to run a game ended up with a black screen because they all tried to grab the "latest" image which was updated. In the end experiences like these lead to reworked scripts which improve over time.
Talking about updated I reworked the start scripts for Chrome & Spotify do check if an update is available and update those apps without the need of manually deleting the old installations, also you can now switch between the stable & dev channel for Spotify.
Becaus I'm pretty lazy and tired of terminal work for basic settings I adopted awiouy audio addon for my needs and added basic config options for video audio & emulation. So normally you should be able to set up your system without any terminal magic.
So all in all there is a variety of under-the-hood changes that you might not see on first sight but they make everyday usage somewhat convenient and avoid trouble or allow "proper" emulation.
In the end use whatever suits your needs. It's open source after all and one hand washes the other.
May i ask if tearing in your chrome addon is still present with this build?
As far as I can say it's still present. I've checked the flags of my Linux Thinkpads and they are pretty much equal. Maybe I haven't noticed it before but if it was introduced after a Chrome update it's probably "their" part to solve it.
I made some tests after Kodi was shut down too. Changing the refresh rate moved the tearing point but still the video had visual tearing.
Build RR-20190511-8da09c7 | Generic & RPi testbuilds Index of /testing/
Important!
Systemd & boot should be fixed now. Nevertheless if you use the tmp-emulation.mount then you have to disable & delete the file before you update. So remove /storage/.config/system.d/tmp-emulation.mount it will be restored after the update and you can enable it again.
Tested with the Generic 9.0.1 build and the Chrome program add-in from the LibreELEC repo, GPU acceleration is behaving again.
chrome://gpu looks like: https://ibb.co/6vprxtv
then it's maybe kernel or mesa related
EDIT: tested it with my current build and my chrome://gpu looks exactly the same but still tearing is present.
5schatten is it possible to disable auto update for chrome?
Not really. Might be something that could be added but it was never necessary until now because normally I don't expect Google to release bugged Chrome versions
