It's just silly and poorly-executed. You can make the same joke without borking systems.
How exactly did kodi.tv being down bork your system? Mine works fine
It's just silly and poorly-executed. You can make the same joke without borking systems.
How exactly did kodi.tv being down bork your system? Mine works fine
Looks like wine needs 32 bit libraries, so no go
@duffle
I wouldn't count on this issue getting fixed, as it's not reproducible and LibreELEC staff does not have any Intel or Xorg developers, they use upstream drivers like everyone else. Your issue is a HDMI/EDID handshake issue, as it works directly in your TV. The relevant difference between LE7 and LE8 lies in updated kernel and xorg drivers. Some times when bugs are fixed in updated drivers, new ones are introduced. It would probably be possible to replace those components with the older ones in LE8 if you wanted to do a custom build, but Linux distributions are moving forward not backwards.
As there seems to be a few more on this forum with similar issues, your best bet would be for all of you to report it in the proper place: How to report bugs | 01.org
You could try my latest build, as there was an EDID fix in the latest xf86-video-intel driver (which doesn't see many updates nowadays).
Yes, I think will be easy to add will have a look in the near future.
New builds are uploading very soon, lazy to list the changes have a look in github for those interested. Basically the LibreELEC OS and Kodi is the same, but most cores have been bumped to the latest git revisions as well as mesa/intel driver.
At this point the build is quite stable and everything should be working as it should. Next I will probably add a configuration addon that will make it easier to tweak my build, like enable/disable KMS, start Emulationstation/RetroArch instead of Kodi etc.
Your best bet is probably to use Docker.
That's an odd statement considering the issue is only present when he adds the AVR, and it works fine if he adds the EDID. Obviously the receiver is at fault for not properly passing through the EDID. I have an Intel NUC which works great with my Denon AVR.
Ask Pioneer for a fix!
EDIT: Don't know how I missed the fact that it worked in 7.0.x and not in 8.0.x The relevant difference would probably be the x.org and xf86-video-intel version. Even though it worked in older versions it could still be the AVR that was at fault and the older drivers just worked differently.
Try creating /storage/.config/xorg.conf like this:
I just told you, haswell supports 4.5 I just checked now, works fine here.
I can't see anything obvious in your logs, but I have a haswell and I'm pretty sure psx works here although didn't test it lately. Not at home to check right now but will do later.
The mesa version in this build supports OpenGL 4.5 for haswell, that shouldn't be an issue. Perhaps ask on the RA forum, sounds like there's some kind of issue as you both have this problem.
You can run Linux binaries on pretty much any distribution, as long as you have the required libraries. I don't use Teamviewer myself, but I would guess it's packaged either in rpm/deb. Maybe you could extract the files from the package, copy them over and run them as is. If that wouldn't work for some reason you can run pretty much anything from a Docker container. I recommend creating a thread for that and I might be inclined to help you out there as it would be easier for others to find the same information
That error message is the same as you would get when trying to run a binary compiled for a different architecture (for example running an ARM binary on x86_64). I'm running Thoradia's sabnzbd on my NUC no issue. Can you try running "/storage/.kodi/addons/service.sabnzbd/bin/unrar" in an SSH session and see if you get the same error? I guess it could be some weird thing happened and you got the wrong addon for your rpi although that would be odd. Try posting in his thread as well as he seems very helpful. Sabnzbd is written in Python so it's platform independent, if the addon runs fine otherwise you should be able to replace the unrar binary with a working one manually.
[hr]
zachmorris
Did you turn off "keep audio device alive" under system audio settings? Kodi tends to lock the audio device when playing click sounds for example. My launch scripts tries to solve this by telling Kodi to release the audio device, then sends SIGSTOP to the kodi process and does "usleep 500000" before running the frontend. Look at /usr/bin/emulationstation.start and /usr/bin/kodifreeze.sh to get an idea how it's done. Previously I used to do a "systemctl stop kodi" which avoids the issue entirely, but it takes longer. Let me know if you have a suggestion how to improve this
I managed to get mkfontdir and mkfontscale built for host without too much fuzz. If desirable I could try to create a PR:
New build 20170327:
- linux 4.10.6
- re-enabled lirc_serial driver
- samba reverted to 3.6.25 (let me know if this fixes the issues)
- removed transmission
- libretro cores now use correct git version (apparently netplay uses this to decide if clients are compatible)
- updated packages: beetle-saturn-libretro, btrfs-progs-system, xfsprogs, scummvm-libretro
I'm pretty sure you can simply update the required files under /flash. Look here for what's changed. No need to update just for the sake of updating.
If your zlib:host happens to be the same version that mkfontscale requires then you won't notice. Probably not an issue for slow moving distribution's like Ubuntu. I know the LE team's stance some times is "if it works on Ubuntu it ain't broken", but it would be good to move towards a build system that works regardless of distribution. If that means building more stuff for host, so be it.
EDIT:
Both Arch and Gentoo is mentioned in scripts/checkdeps, so statements like "why are you using gentoo?" seems kind of odd. Once you upgrade to the next Ubuntu version this will be an issue for you too. Just because it works on Ubuntu does not mean that something isn't broken.
Actually, he is not the one mixing libraries, the build system is I got the same thing as well. The problem is that the build host's mkfontscale is linked against a versioned zlib shared library, and when the LE build system calls it I guess $TOOLCHAIN/lib comes first in the LD_LIBRARY_PATH. Currently zlib in LE is 1.2.8, while in Arch (and I guess also Gentoo) it's up to 1.2.9. A quick fix is to bump the LE zlib version up but that'll only work until the next version comes along. A better fix seems to be calling mkfontdir/mkscale with LD_LIBRARY_PATH=/usr/lib. Either that or building mkfontdir/mkfontscale for the host (which would require building more stuff for the host).
The primary reason for using a WINS server is if you want to access computers located on different subnets via NETBIOS names. On a flat home network it's not needed. The way Windows browsing works is there's an automatic "election" process where one computer is selected to be a local master browser for each workgroup name. If that machine gets shut off using NETBIOS names could be troublesome until a new master browser has been elected.
Make sure that all your computers are using the same workgroup name and you should be fine. If your HTPC running LE is always on it might be a good idea to force it to be a local master browser (see the samba.conf.sample in /storage/.config).
I'll make the next build with Samba reverted to the old version, probably that's why.
It was segfaulting during download. I figured it could have been an incompatility with my build as I have made a few package bumps and changes that puts it past LE8 (kernel, openssl, glibc, etc.), so I didn't want to bother you with it. I was meaning to look into it more, I'll see if I get the time today and report back.
EDIT: Thoradia's transmission seems to work fine now, so I'll exclude my version in the next build.
You could stop the systemd unit and restart it with your custom configuration file as an option. It could be automated in autostart.sh for example. Be creative