So what's the root issue behind the 4k 60fps lag when playing BBB on a Rockchip board? Definitely skipping some frames, and I know there's been some discussion surrounding the issue. Just wondering what's actually causing it and if there's any plan to resolve?
Posts by Mrfixit2001
-
-
Any chance you could point me to the file I'm looking for? I can find it in the code but haven't had any luck finding the file
-
I agree and prefer the idea of editing the LE settings. Which package file or add on file holds this setting that I should edit?
-
Leia has it configured but the user still needs to manually toggle it on. I want to enable this by default after compile.
-
All excellent feedback, thank you all. It makes sense, and I understand if the storage partition gets erased there's no way to restore those files, but just like any computer a good backup is important in those cases. I understand it's not the "normal" way of doing things, but it's good to know it's an option that I can explore. Love the expert feedback in this forum. thanks again
-
Is there a setting somewhere in the source that will enable SSH by default so it's enabled, just like samba, immediately after the first boot without the user having to toggle it on?
-
What I'm referring to is modifying this script so that on first boot it doesn't remove and recreate the storage partition before it resizes. It would just resize. Hopefully leaving all content intact. Thoughts?
LibreELEC.tv/fs-resize at master · LibreELEC/LibreELEC.tv · GitHub
-
-
-
I've been working on some custom compilation for LibreElec and my OCD is getting the better of me. I Understand on first boot the storage partition is deleted, resized, and recreated, so I can't really store anything there before then. But is it possible to configure some files to LIVE on the storage folder/partition? For example, there's some binaries and supporting files that get installed into /usr/bin and /usr/share that I really want to live in /storage, but I have to manually copy them over after the first boot is completed. Is it possible to automate this to run after storage is resized and then remove them from their original location so they only live in the /storage location? I'm guessing not since the file system is read only, but couldn't hurt to ask.
-
Hello,
I am using a Rock64 board (from PINE64) with a dedicated Libreelec 8.2 rom and it work really great,
BUT
When I try to launch Retroarch or Emulation Station, Libreelec ask me if I want to qui Kodi to run Retroarch or EmuStation.
I say yes and then I have the main logo page (for both programs) but few seconds later it go back to home screen of kodi....
It seems it can not quit kodi to launch emulators....
Does anybody know what I should do?
Thanks
I just opened this issue for the ROCK64 compatibility, in case anyone wants to follow or add detail: EmulationStation and RetroArch won't start · Issue #94 · bite-your-idols/Gamestarter · GitHub
-
escalade your guidance of editing that patch to ensure the paths were being used was gold. Thanks! On to the next error haha
Now I get unable to initialize SDL and no avail video device. Lots of posts on this one all over the internet, so this may take awhile haha the good news is I've encountered this error before when I compiled emulationstation on stretch and resolved it by force overwriting some packages. The bad news is I can't do that on libreelec. I tried display=:0 but it had no effect. If you have any previous experience resolving this or have thoughts, I'd welcome them. Thanks!
-
escalade - thanks, that was helpful. Based on the below link to the implementation of the RPI specific setting that your patch utilizes, im thinking I need to create a patch to force override cmakelists setting VIDEO_RPI to ON so your patch is picked up. Do you think I need to override the paths in sdlchecks.cmake as well?
SDL: changeset 9077:28e6de55eb07
Also, do you have a shortcut to creating patches? The only sure way I know of is to upload the source to github, make the change, and use the commit to generate the patch. I understand the syntax in the patch file content but the first few lines I don't know how to set.
-
Thank you for that! The ROCK64 uses the mali-rockchip drivers, and below is an except from the makeinstall_target function within that package.mk. From what I can tell, the paths are the same as they are on the RPI. I did have to manually add the links for libGLESv1 and libglesv1_cm, since it was complaining about those. So it appears to be finding them.
mkdir -p $SYSROOT_PREFIX/usr/lib
cp -PRv lib/$PKG_MALI_ARCH/$PKG_MALI_FILE $SYSROOT_PREFIX/usr/lib
ln -sfv $PKG_MALI_FILE $SYSROOT_PREFIX/usr/lib/libmali.so
ln -sfv libmali.so $SYSROOT_PREFIX/usr/lib/libMali.so
ln -sfv libmali.so $SYSROOT_PREFIX/usr/lib/libEGL.so
ln -sfv libmali.so $SYSROOT_PREFIX/usr/lib/libGLESv2.so
ln -sfv libmali.so $SYSROOT_PREFIX/usr/lib/libGLESv1.so
ln -sfv libmali.so $SYSROOT_PREFIX/usr/lib/libGLESv1_CM.so
ln -sfv libmali.so $SYSROOT_PREFIX/usr/lib/libgbm.so
mkdir -p $INSTALL/usr/lib
cp -PRv lib/$PKG_MALI_ARCH/$PKG_MALI_FILE $INSTALL/usr/lib
ln -sfv $PKG_MALI_FILE $INSTALL/usr/lib/libmali.so
ln -sfv libmali.so $INSTALL/usr/lib/libMali.so
ln -sfv libmali.so $INSTALL/usr/lib/libEGL.so
ln -sfv libmali.so $INSTALL/usr/lib/libGLESv2.so
ln -sfv libmali.so $INSTALL/usr/lib/libGLESv1.so
ln -sfv libmali.so $INSTALL/usr/lib/libGLESv1_CM.so
ln -sfv libmali.so $INSTALL/usr/lib/libgbm.so
It looks like that patch you listed is referencing one link I didn't add, for libGLES_CM, so I'll add that and cross my fingers. Do you have any other thoughts or ideas? Do you agree the paths look the same? -
escalade I have been working to take your customized work and integrate it with a LibreELEC build from GDPR-1 that's meant for my platform, the ROCK64. I basically added your OEM settings, your escalade packages folder, and then worked through each compile error one at a time. I've also omitted all but a handful of emulators for this first version. I've got everything successfully compiling and it boots just fine but I'm stuck with EmulationStation throwing this error: "SDL not built with video support".
I've reviewed the SDL2 package.mk that you use and compared it to raybuntu's and he has a lot of custom flags that you don't which I initially blamed for this error, so I recompiled using your exact SDL2 package.mk and patches. I had to add a dependency to libXext but it compiled fine, however I still get the exact same SDL error.
So I'm at a point where I need some advice from escalade or from GDPR-1. Maybe this error is referring to SDL1 and not SDL2? Running EmulationStation --debug doesn't provide any additional information.
When SDL2 compiles, here's the output Configure Summary:
Enabled modules : atomic audio video render events joystick haptic power filesystem threads timers file loadso cpuinfo assembly
Assembly Math :
Audio drivers : disk dummy oss alsa(dynamic) pulse(dynamic)
Video drivers : dummy x11(dynamic) opengl_es1 opengl_es2 vulkan
X11 libraries : xdbe xshape
Input drivers : linuxev linuxkd
Using libsamplerate : NO
Using libudev : YES
Using dbus : YES
Using ime : YES
Using ibus : NO
Using fcitx : NO
As a workaround, I'm considering just trying to import over a compiled version of emulationstation and libraries that I already built for ROCK64 on a stretch release that I know runs and copy it into the OEM files instead of letting LibreELEC compile them. No idea at all if this will work haha I'd prefer to fix the SDL issue.
Any and all feedback would be greatly appreciated! -
Thanks for the feedback all. The build instructions are clear I'm just trying to avoid having to use a git repository. I edited the necessary scripts manually and just removed any reference to git. So that Problem is solved. On to the next! Haha Thanks anyways!
-
Thanks, but those instructions involve cloning and checking out from the repository. I already have my customized source ready and built up to the point where the image needs to be generated. So what commands will allow scripts/image to run without me having to clone and checkout? I bit the bullet and created a git account and ran those commands (minus clone and checkout because I don't want to override any of my existing source) but I'm still stuck not able to run with the below error:
Ambiguous argument HEAD: unknown revision or path not in the working tree
-
well that's great to know! So what commands do I run to get the folder ready to generate an image? I ran init but it clearly wasn't enough.