Posts by 5schatten

    Loving the build! I have it running in an unraid VM with a GPU pass-through. But I have 2 quick questions:

    1 - How do I add plex to the Main Menu of Kodi? I got it installed as a plugin.. but can't seem to find a way to add it to the main menu.

    2 - I can login to spotify, but i'm unable to play any tracks. When i go into a playlist and click play, it just keeps skipping to the next track.

    Thanks!

    I guess Estuary has no option to add menu entries -> I patch the skin while it is build & add some logos to achieve my custom menu buttons. Try this one Estuary MOD V2 - KODI 18 (UPDATED 26/10/18) instead and read the FAQ about the python scripts I use to start the apps & frontends.

    IMHO the Spotify client is a $%&§"! /shrug if it keeps skipping songs it's probably related to some adblock stuff? I use Pi-hole to block ads but once Spotify can't reach every single adserver or play every single ad it just stops or skips songs. So basically if you use it with a free account make sure you don't block any ads for this client. I achieved this by disabling dhcp for my htpc & manually set the router as dns server, after this Spotify works for me.

    Also you could delete the file /storage/.config/spotify/stable then the start script should try to install the Spotify dev branch which maybe works better.

    I've not tested n64 cores because I'm always disappointed.

    About the drama it reminds me of the libretro/redream drama, so much hate :(

    Well then just give it a try.


    The thing is the attitude of some people and some probably crave for admiration. So if you work on a libretro core you don't get as much attention as you might get if someone uses a standalone version. Maybe it's also just for the money? For example some great emus just added some libretro stuff and you can chose what you want to build so either standalone or a lr-core. Others maintain some lr compat forkes for RA but to be honest they are inferior for no reasons so you could use them but the standalone will be the better choice. But all-in-all if they work for free as a hobby... well they should not expect too much or push them to the limit.

    Anyway if it comes to N64 emulation it's mostly a mess... many emulators build on pretty old code and several plugins with various performance or compatibility issues... personally I don't get why they won't work together to create one working emulator.

    Let's hope the bounty will rise & draw some devs attention to have some mercy and push some updates.

    That's the whole point of the loganmc10 vs TA drama two years ago, no more mainteiner, no more updates :/

    Have you tried the "recent" lr-Mupen64plus IMHO it runs better than the old one. I've added parallel-n64 because before they pulled some upstream code it even run like crap on my generic system. Now it's quite playable on my RPi & VIM.


    Of course it's not really on par with the upstream code but hopefully someone want's to grab the bounty. I've checked out how Lakka or Retropie handle it but they either use the lr-core or mupen64plus · GitHub so basically pest or cholera.

    I guess the drama starts here?

    The problem is not the RSP but the RDP plugin.

    m64p uses GLideN64, the best HLE plugin now.

    The libretro core can't use that, it's based on old sources because it's author, loganmc10, stopped core development to create m64p (classic retroarch/TA drama).

    It seems compatibility is much better with this standalone emu.

    EDIT: Update M64p + GlideN64 and/or ParaLLEl +GlideN64 to Latest Build · Issue #57 · libretro/mupen64plus-libretro · GitHub

    Well doesn't the lr core use GLideN64?! IMHO ParaLLEl uses some diffrent plugins :/

    Bountysource

    someone already startet to push some updates:

    Mupen updates by m4xw · Pull Request #69 · libretro/mupen64plus-libretro · GitHub

    Is there anyway a chart that shows mupen64 standalone has a better compatibility? AFAIK some games are broken for basically all N64 emus.

    I prefer to use lr cores because it's easier to set them up. Dolphin or Citra lr-cores have inferior config options or performance so I use the standalone versions.

    I'll check them out but shouldn't be a problem. Most console emulators work fine, needs more effort are the home computer emus like Atari Amiga emulators. Can you name some games I should test?

    @5schatten it works fine now!

    Now would it be possible to add lcd support to your build with this?

    https://forum.libreelec.tv/thread/11736-led-vfd-displays-in-libreelec/?postID=101050#post101050

    You could also add the new kronos libretro core (Saturn)

    I've messaged the dev -> hopefully he'll find some time & creates a PR that bumps the upstream driver version. So once this is done vanilla LE will feature the latest vfd and of course my build too.

    About Kronos... looks really WIP to me. I've created a package for tests but it won't run on RPi since he relies on OpenGL ES 3.0.

    Yeaa not overly bothered but its nice to have options :cool:

    I'm not entirely sure if Retroplayer is a real alternative to Retroarch at the moment :/ :D

    Updated to the latest build and libretro compatibility isn't compatible, ironically. Has something changed with your build or is it a Kodi bug?

    I guess game.libretro needs a bump updated libretro and game.libretro packages by CvH · Pull Request #3056 · LibreELEC/LibreELEC.tv · GitHub but since this should not matter for my emulators.../shrug

    bigboo

    I suggest you let the dev know that they should update the fd628-aml driver to openvfd with all the related changes.

    You'll need different DTBs for openvfd to work on that build.

    I use the LE upstream code for my build so could you create a PR & update the fd628-aml since it build based on your repo anyway? Once the fd628 driver is updated your custom DTB & the correct config file should work if they replace the stock files? I have no AML device with attached display so I can't test it.

    Well maybe this helps:

    amdgpu#xorg_or_applications_won.27t_start

    xorg.conf.5.html

    Code
    Section "Screen"
           Identifier     "Screen"
           DefaultDepth    24
           SubSection      "Display"
                   Depth   24
           EndSubSection
    EndSection
    Quote

    DefaultDepth depth

    specifies which color depth the server should use by default. The -depth command line option can be used to override this. If neither is specified, the default depth is driver-specific, but in most cases is 8.

    Okay let's check the facts. You've uploaded a single set of log files:

    https://drive.google.com/drive/folders/1pxprex6vz4tuo2yaujdkyslnsacka6bv

    For me file 02_System.log & 06_varlog.log is important since those files contain the kernel log & the Xorg log.

    The kernel log tells me at least one pci device with a Nvidia "10de" id is found and:

    So later the file 96-nvidia.rules will try to identify what Nvidia card is installed because a Nvidia pci id was detected regardless if your IGP is disabled or not. Is this a bug? Well maybe if you're relying on hardware manufactored >10 years ago. It's a compromis that covers basically all the usual hardware setups and I'm pretty sure fixing things for such old stuff has low priority. After detecting the cards it either calls [email protected] or [email protected] which tells xorg-configure how to set up the graphic drivers. In example it creates symlinks for libglx.so

    For Nvidia drivers:

    ln -sf /usr/lib/xorg/modules/extensions/libglx_nvidia-legacy.so /var/lib/libglx.so

    For mesa drivers:

    ln -sf /usr/lib/xorg/modules/extensions/libglx_mesa.so /var/lib/libglx.so

    So now let's have a look at your Xorg log:

    Code: 06_varlog.log
    [    18.681] (II) LoadModule: "glx"
    [    18.682] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
    [    19.047] (II) Module glx: vendor="NVIDIA Corporation"
    [    19.047]     compiled for 4.0.2, module version = 1.0.0
    [    19.047]     Module class: X.Org Server Extension
    [    19.050] (II) NVIDIA GLX Module  340.107  Thu May 24 21:40:32 PDT 2018

    As we see it loads a Nvidia libglx.so and not the regular mesa like it should:

    Code: 06_varlog.log
    [     8.054] (II) LoadModule: "glx"
    [     8.055] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
    [     8.061] (II) Module glx: vendor="X.Org Foundation"
    [     8.061]     compiled for 1.20.2, module version = 1.0.0

    So you stated you've had already recompiled the distribution without the Nvidia packages so you should get an output like this:

    As you can see there is no 96-nvidia.rules, libglx_nvidia-legacy.so or xorg-nvidia.conf or xorg-nvidia-legacy.conf file so Xorg will certainly not load any Nvidia stuff if the distribution is compiled without Nvidia packages. I'm pretty sure yours looked like this:

    "instead of asking someone who knows how to build LE without Nvidia drivers"

    Bro.

    I.

    Did.

    That.

    Nope you did not. :rolleyes::dodgy:

    So how we compile LE without them? Well what about adding one single line:

    GRAPHIC_DRIVERS="r300 r600 radeonsi i915 i965 vmware virtio"

    to the generic options file. Well maybe not as "hackermanish" like "cat & grep all day and night" but hassle free & gets you rid of Nvidia.

    The other option would be to create an udev rule that prevents xorg-config to set up a Nvidia environment. For example you probably could create a 96-nvidia.rules file in /storage/.config/udev.rules.d copy the content 96-nvidia.rules in & change ATTRS{vendor}=="0x10de" to something like ATTRS{vendor}=="0x5333" what should prevent loading of Nvidia stuff. But since we already know you think about setting up a simple override:

    5schattenthe whole silly /storage/.config thing is just ridiculous.

    Your only option would be recompiling the whole thing. But properly. All in all I can say is I'm actually not impressed.

    PS: back to business -> this is a support thread for the RR build not someones personal problems or not existing reading comprehension skills /shrug

    PPS: It would be some serious black magic if my builds contain Kodi 18.4 which would be the fourth point release. Since my DeLorean is still at the service station you have to deal with Kodi 18 beta 4. :/

    By the way have you heard about the Dunning–Kruger effect?

    ekCtenK.jpg

    Beta 12 is online:

    • updated to latest LE9.0 upstream
    • updated to Kodi 18 beta 4
    • updated Generic & RPi kernel to 4.18.16
    • updated nvidia video driver to 410.66
    • updated mesa to 18.2.3
    • updated vulkan-loader to 1.1.89
    • updated Retroarch to 1.7.6-dev
    • updated several libretro-cores
    • updated dolphin & citra
    • updated amiberry 2.24b-dev
    • added some DOSBox sample confs for MT32 & FluidSynth emulation
    • added FluidSynth as MIDI synthesizer for Retroarch & DOSBox-SDL2 (only works with PulseAudio atm) -> create a "usePulseAudio" file in /storage/.config/ to activate it