theres a lot wrong with this one so just read the red
BESIDES ID LIKE TO NOT HAVE TO DO ANY MODIFICATIONS ANDIT JUST WORKS
LIKE WHY CANT YOU JUST SEE THAT THE UDEV RULE IS BEING TRIGGERED FALSELY, WHICH IS THE BUG I WAS REPORTING
GOD FREAKIN DANG YOU ARE SO THICK DRAKE WOULD BE ALL OVER YOU
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 $%&§"! 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?
-
Well looks like the GUI is based on QT 5.4 so I probably could build mupen64plus-GLideN64 for Generic systems but not for RPi and for generic systems there is already parallel-n64/mupen64plus-libretro.
I honestly have no clue why they don't pull the recent Glide64 code since the core pretends to be compatible with upstream
-
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.
Well doesn't the lr core use GLideN64?! IMHO ParaLLEl uses some diffrent plugins
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.
-
Hey that's great!
One last thing concerning emulators, I think retroarch n64 cores are outdated, would it be difficult to add this standalone build of mupen64 to the x86-64 build?
Afaik mupen64plus has been updated not too long ago.
Updated HLE RSP from upstream · libretro/mupen64plus-libretro@e654195 · GitHub
-
-
Would it be possible to add some missing libretro cores to your build?
nec pcengine
GitHub - libretro/beetle-pce-fast-libretro: Standalone port of Mednafen PCE Fast to libretro.
atari 2600
GitHub - libretro/stella-libretro: Port of Stella to libretro.
atari 800
GitHub - libretro/libretro-atari800: atari800 3.1.0 for libretro/libco WIP
msx (some cool games like the first two Metal Gear)
GitHub - libretro/blueMSX-libretro: Port of blueMSX to the libretro API.
All of them works fine on rpi, they are mature cores, they are not updated often so it would not be much work to maintain.
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
I'm not entirely sure if Retroplayer is a real alternative to Retroarch at the moment
-
I can create a PR to LE.
There is no more need for custom DTBs for each device, as configuration has moved into the vfd.conf files. This means that each root-DTS file needs to have an openvfd entry, so I'll have to make another PR to LE's linux-amlogic repo.
I'm a bit busy at the moment, but I'll try to find the time for it.
No problem, take your time.
-
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...
-
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.
-
-
Hello,
I have a rather old Philips TV connected to my HTPC. The problem is: every once in a while the display goes completly cyan/magenta. I had the problem before with older HTPC hardware and the fix was to force the output of the graphics adaptor to Full RGB / RGB 4:4:4. Unfortunately, I did not find where I can make this setting in LibreELEC 9 (Milhouse build).
So far I tried
- setting "ColorSpace" and "ColorRange" in xorg.conf
- xrandr (but there seems to be no property for the pixel format, at least for the AMD CPU)
- Kodi settings (use limited color range)
Is there a way to force the pixel format to RGB 4:4:4?
Well maybe this helps:
amdgpu#xorg_or_applications_won.27t_start
CodeSection "Screen" Identifier "Screen" DefaultDepth 24 SubSection "Display" Depth 24 EndSubSection EndSection
QuoteDefaultDepth 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.
-
id think you'd be able to read.
"instead of asking someone who knows how to build LE without Nvidia drivers"
Bro.
I.
Did.
That.
The xorg conf file was still there
AFTER
I modified the config file WITH NO NVIDIA NOR NVIDIA LEGACY DRIVERS and compiled it
///////AFFFTTTEERRR THATT//////
I DOUBLE CHECKED AND RECOMPILED
AND THE XORG CONF IS STILL THERE.
then, and only then, did I come to the fourms.. USING PRCOMPILED IMAGES BECAUSE IT SEEMED TO BE A BUG. I can't report a bug using altered unpublished code now can I?
I explained how the card isn't even in lspci, Yada yada yada, findcatgrep to stop generating xorg-nvidia-legacy.conf, yada yada yada, your memes, now we're here. You gonna actually use that 4th grade reading comprehension in this one or drunkenly skim, then reply like a 12 year old again?
I don't think I need to tell you a third time that your hat is made of buttox.
PS, my current job does not involve coding. We get the shitty "can it run Skype and outlook?" "Yep" computers. I'm surprised and lucky I don't get 2 cores of a hypervisor these days.
PPS, thanks for updating to Kodi 18.4 I'm sure it was difficult managing that, your mom telling you to clean up the basement again, and all those memes and commits you had to look up to try and /school me/ on a mistake I've been trying to tell you for 3 days I didn't make.
<Insert amused man eating popcorn gif>
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:
Code: 02_System.log
Display More[ 0.591254] pci 0000:00:00.0: [10de:02f1] type 00 class 0x050000 [ 0.591595] pci 0000:00:00.1: [10de:02fa] type 00 class 0x050000 [ 0.591876] pci 0000:00:00.2: [10de:02fe] type 00 class 0x050000 [ 0.592159] pci 0000:00:00.3: [10de:02f8] type 00 class 0x050000 [ 0.592443] pci 0000:00:00.4: [10de:02f9] type 00 class 0x050000 [ 0.592739] pci 0000:00:00.5: [10de:02ff] type 00 class 0x050000 [ 0.593039] pci 0000:00:00.6: [10de:027f] type 00 class 0x050000 [ 0.593321] pci 0000:00:00.7: [10de:027e] type 00 class 0x050000 [ 0.593623] pci 0000:00:02.0: [10de:02fc] type 01 class 0x060400 [ 0.593693] pci 0000:00:02.0: PME# supported from D0 D1 D2 D3hot D3cold [ 0.593984] pci 0000:00:03.0: [10de:02fd] type 01 class 0x060400 [ 0.594049] pci 0000:00:03.0: PME# supported from D0 D1 D2 D3hot D3cold [ 0.594322] pci 0000:00:04.0: [10de:02fb] type 01 class 0x060400 [ 0.594385] pci 0000:00:04.0: PME# supported from D0 D1 D2 D3hot D3cold [ 0.594676] pci 0000:00:09.0: [10de:0270] type 00 class 0x050000 [ 0.595121] pci 0000:00:0a.0: [10de:0261] type 00 class 0x060100 [ 0.595443] pci 0000:00:0a.1: [10de:0264] type 00 class 0x0c0500 [ 0.595496] pci 0000:00:0a.1: reg 0x20: [io 0xfc00-0xfc3f] [ 0.595507] pci 0000:00:0a.1: reg 0x24: [io 0xf800-0xf83f] [ 0.595561] pci 0000:00:0a.1: PME# supported from D3hot D3cold [ 0.595839] pci 0000:00:0a.2: [10de:0272] type 00 class 0x050000 [ 0.596155] pci 0000:00:0b.0: [10de:026d] type 00 class 0x0c0310 [ 0.596176] pci 0000:00:0b.0: reg 0x10: [mem 0xfebff000-0xfebfffff] [ 0.596248] pci 0000:00:0b.0: supports D1 D2 [ 0.596252] pci 0000:00:0b.0: PME# supported from D0 D1 D2 D3hot D3cold [ 0.596530] pci 0000:00:0b.1: [10de:026e] type 00 class 0x0c0320 [ 0.596551] pci 0000:00:0b.1: reg 0x10: [mem 0xfebfe000-0xfebfe0ff] [ 0.596625] pci 0000:00:0b.1: supports D1 D2 [ 0.596630] pci 0000:00:0b.1: PME# supported from D0 D1 D2 D3hot D3cold [ 0.596918] pci 0000:00:0d.0: [10de:0265] type 00 class 0x01018a [ 0.596961] pci 0000:00:0d.0: reg 0x20: [io 0xf400-0xf40f] [ 0.596979] pci 0000:00:0d.0: legacy IDE quirk: reg 0x10: [io 0x01f0-0x01f7] [ 0.596983] pci 0000:00:0d.0: legacy IDE quirk: reg 0x14: [io 0x03f6] [ 0.596987] pci 0000:00:0d.0: legacy IDE quirk: reg 0x18: [io 0x0170-0x0177] [ 0.596991] pci 0000:00:0d.0: legacy IDE quirk: reg 0x1c: [io 0x0376] [ 0.597273] pci 0000:00:0e.0: [10de:0266] type 00 class 0x010185 [ 0.597295] pci 0000:00:0e.0: reg 0x10: [io 0x09f0-0x09f7] [ 0.597305] pci 0000:00:0e.0: reg 0x14: [io 0x0bf0-0x0bf3] [ 0.597315] pci 0000:00:0e.0: reg 0x18: [io 0x0970-0x0977] [ 0.597325] pci 0000:00:0e.0: reg 0x1c: [io 0x0b70-0x0b73] [ 0.597335] pci 0000:00:0e.0: reg 0x20: [io 0xe000-0xe00f] [ 0.597346] pci 0000:00:0e.0: reg 0x24: [mem 0xfebfd000-0xfebfdfff] [ 0.597653] pci 0000:00:10.0: [10de:026f] type 01 class 0x060401 [ 0.597986] pci 0000:00:10.2: [10de:026b] type 00 class 0x040100 [ 0.598007] pci 0000:00:10.2: reg 0x10: [io 0xdc00-0xdcff] [ 0.598017] pci 0000:00:10.2: reg 0x14: [io 0xd800-0xd8ff] [ 0.598028] pci 0000:00:10.2: reg 0x18: [mem 0xfebfc000-0xfebfcfff] [ 0.598088] pci 0000:00:10.2: supports D1 D2 [ 0.598349] pci 0000:00:14.0: [10de:0269] type 00 class 0x068000
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:
Code
Display More############################################## # LibreELEC 9.0 Reborn Remix # # https://goo.gl/TemeuW # # based on https://libreelec.tv # ############################################## LibreELEC (5schatten): RR-201843-e3f35d1 (Generic.x86_64) phoenix:~ # ls /usr/lib/udev/rules.d 30-disable-wakeup.rules 70-joystick.rules 40-modeswitch.rules 70-mouse.rules 50-udev-default.rules 70-power-switch.rules 51-these-are-not-joysticks.rules 70-touchpad.rules 60-block.rules 75-net-description.rules 60-cdrom_id.rules 75-probe_mtd.rules 60-drm.rules 78-sound-card.rules 60-evdev.rules 80-clock.rules 60-input-id.rules 80-drivers.rules 60-not-joysticks.rules 90-alsa-restore.rules 60-persistent-alsa.rules 90-pulseaudio.rules 60-persistent-input.rules 95-udevil-mount.rules 60-persistent-storage-tape.rules 97-hid2hci.rules 60-persistent-storage.rules 97-xorg.rules 60-persistent-v4l.rules 98-appleir.rules 60-sensor.rules 98-eventlircd.rules 60-serial.rules 98-xorg-xkb.rules 61-cdrom.rules 99-8bitdo-bluetooth-controllers.rules 64-btrfs.rules 99-systemd.rules 70-infrared.rules 99-vmware-scsi-udev.rules 70-input-repeat.rules 99-wakeup-eth.rules phoenix:~ # ls /usr/lib/xorg/modules/extensions libglx.so libglx_mesa.so phoenix:~ # ls /etc/X11 xorg-amdgpu.conf xorg-modesetting.conf xorg-i915.conf xorg-radeon.conf phoenix:~ #
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:
Code
Display More############################################## # LibreELEC 9.0 Reborn Remix # # https://goo.gl/TemeuW # # based on https://libreelec.tv # ############################################## LibreELEC (5schatten): RR-201843-e3f35d1 (Generic.x86_64) phoenix:~ # ls /usr/lib/udev/rules.d 30-disable-wakeup.rules 70-mouse.rules 40-modeswitch.rules 70-power-switch.rules 50-udev-default.rules 70-touchpad.rules 51-these-are-not-joysticks.rules 75-net-description.rules 60-block.rules 75-probe_mtd.rules 60-cdrom_id.rules 78-sound-card.rules 60-drm.rules 80-clock.rules 60-evdev.rules 80-drivers.rules 60-input-id.rules 90-alsa-restore.rules 60-not-joysticks.rules 90-pulseaudio.rules 60-persistent-alsa.rules 95-udevil-mount.rules 60-persistent-input.rules 96-nvidia.rules 60-persistent-storage-tape.rules 97-hid2hci.rules 60-persistent-storage.rules 97-xorg.rules 60-persistent-v4l.rules 98-appleir.rules 60-sensor.rules 98-eventlircd.rules 60-serial.rules 98-xorg-xkb.rules 61-cdrom.rules 99-8bitdo-bluetooth-controllers.rules 64-btrfs.rules 99-systemd.rules 70-infrared.rules 99-vmware-scsi-udev.rules 70-input-repeat.rules 99-wakeup-eth.rules 70-joystick.rules phoenix:~ # ls /usr/lib/xorg/modules/extensions libglx.so libglx_nvidia.so libglx_mesa.so libglxserver_nvidia.so libglx_nvidia-legacy.so libglxserver_nvidia.so.410.66 phoenix:~ # ls /etc/X11 xorg-amdgpu.conf xorg-modesetting.conf xorg-nvidia.conf xorg-i915.conf xorg-nvidia-legacy.conf xorg-radeon.conf phoenix:~ #
"instead of asking someone who knows how to build LE without Nvidia drivers"
Bro.
I.
Did.
That.
Nope you did not.
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
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?
-
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
-