I think most people wont use it without a GUI, and if you can already get Wireguard support in a cheap pocket router it liberates CPU resources for Kodi. On those GL routers, both client & server configuration can be done through a web interface for both Wireguard & OpenVPN. At some point maybe the Kodi web interface will support Wireguard client configuration too. But can you afford to expend any CPU resources on a VPN if you have a weak CPU (which represents the majority of LibreELEC users).
When background video playback is enabled and the TAB key is pressed with video playing, the video display resolution is reduced and the Kodi UI no longer fills the screen.
UPDATE: After extensive troubleshooting, it appears the issue was related to a FLIRC update, and a reset of the FLIRC adapter was necessary.
DirectVNC is a client implementing the remote framebuffer protocol (rfb) which is used by VNC servers. If a VNC server is running on a machine you can connect to it using this client and have the contents of its display shown on your screen. Keyboard and mouse events are sent to the server, so you can basically control a VNC server remotely. There are servers (and other clients) freely available for all operating systems.
What makes DirectVNC different from other unix VNC clients is that it uses the linux framebuffer device through the DirectFB library which enables it to run on anything that has a framebuffer without the need for a running X server. This includes embedded devices. DirectFB even uses acceleration features of certain graphics cards. Thus a lot of configuration can be done by creating the library specific configuration file /etc/directfbrc or the program-specific configuration file /etc/directfbrc.directvnc. See directfbrc
I think they submitted the code (revised) again and should get into 5.x kernel. Or at least many of us hope so. If yes, it will be in LE too?
Sooner or later.Quote
Btw, why is it not possible to add it to kernel on building?
You also need to build a G.U.I. to control it in Kodi. And this might have to be changed after the new kernel is released. Other bugs & features have a higher priority now.Quote
I couldn't believe how fast speed I am getting, compared to OpenVPN.
Sure, probably 4 or 5 times better -- possibly even more, depending on which cipher was used in OpenVPN. Wireguard is great for creating tunnels between two machines or private networks, but it is not ready to be deployed in commercial proxy applications because it lacks dynamic IP address management:
While alternatives are being discussed here, I wanted to mention that you can also run adblock on many home routers by replacing the factory firmware with OpenWRT and then installing the adblock package:
This blocking method is perhaps not as feature rich and user friendly as PiHole or AdGuard with the nice GUI — but it does not require extra hardware and it will block the most common privacy violating trackers (DoubleClick, Google Analytics, etc.) What matters most is the quality of the block list; everything else is a matter of preference.
There is also an app called GA checker for Kodi which scans your addons for obfuscated code and references to Google Analytics.
I noticed that LibreELEC has a VNC server for Raspberry Pi, but there is no VNC client in the repository. (I typically use LibreELEC in a classroom environment to display videos from a networked file server — but sometimes I need it to mirror the screen of the instructors desktop PC.)
This is planned in the near future, but not implemented yet.
If you really need Wireguard immediately, you can use the beta 3.0 firmware on GL.inet routers
On the RPi 3 platform, I found a couple of keys which did not work correctly on my MCE remote (model RC-1). So I created a custom key table by copying '/usr/lib/udev/rc_keymaps/rc6_mce' to '/storage/.config/rc_keymaps'. My transceiver is detected as follows:
Found /sys/class/rc/rc0/ (/dev/input/event4) with:
Name: Media Center Ed. eHome Infrared Remote Transceiver (1784:0006)
Driver: mceusb, table: rc-rc6-mce
lirc device: /dev/lirc0
Supported protocols: lirc rc-5 rc-5-sz jvc sony nec sanyo mce_kbd rc-6 sharp xmp imon rc-mm
Enabled protocols: lirc nec rc-6
bus: 3, vendor/product: 1784:0006, version: 0x0100
Repeat delay = 500 ms, repeat period = 125 ms
For some reason I cant understand, on this remote the LibreELEC default WINDOWS key assignment:
...performs the same function as the BACK button. For example, if I am in Kodi "Videos/Add-ons", the BACK key and WINDOWS key do the same thing. As MCE remotes already have dedicated keys for each type of media, and all of my RF remotes have a HOME key which invokes the main menu on LibreELEC, I believe the WINDOWS key should do the same on an MCE remote - so I assigned it like this:
However, it still behaves the same way -- as the back key. So I changed KEY_HOME to KEY_VOLUMEUP, and that works. I then assigned it to KEY_EPG, and this works too. But it appears that KEY_HOME and KEY_MEDIA do the same thing in LIRC (which is to navigate back). Looks like a bug to me.
The BACK key on this remote is assigned by default as follows:
And it does work - but just for the sake of clarity, I thought the key should be explicitly assigned to the back function, like this:
So I tested it, and the key performs the back function with both. (Not that it matters in this case, since the key already does what it should - but its here for the sake of documentation.)
On my remote the MORE INFO key :
currently displays the add-on properties window, instead of displaying the context menu (meaning: there is no way to raise the context menu -- at least on my model). So I thought this key should be reassigned as follows:
I tested this, and it works correctly -- so I now have a working CONTEXT MENU button, just like my RF remotes that function correctly in LibreELEC. From reading the documentation here...
...it appears to me that all of the MCE remotes are assigned the same default keytable on LibreELEC -- so if they all function the same way, with respect to the MORE INFO key, I believe this particular change should be published for everyone.
"kodi-send" does not give any kind of succeed or fail indication. It only confirms that a message was sent. If you send an invalid command (e.g. action=baloney) it would never tell you the command is not supported. The only result is that I see no image in the screenshot folder. So I turned on debugging and repeated the command. Aside from keyboard events, this is the only thing that was logged:
DEBUG: cached image '/storage/screenshots/screenshot003.png' size 1920x1080
I'm looking at the screenshot folder through an SFTP connection and I dont see the image, even after refreshing the directory. I am not really concerned about it, but I wanted to see if others had encountered the same issue, since the context button also quit working on Play in LE 9. But the screenshot problem seems to have cleared up after a reboot, so I cant reproduce it now.
I have hardware acceleration disabled in OMXplayer because it interferes with the ability to change playback speed on YouTube. I still get smooth playback of MPEG-2 HD streams from TVheadend on a RPi 3 in LibreELEC 9, regardless of whether the factory MPEG-2 license key is installed. But I run the TVHeadend server on another machine, which could make a difference.
I am running LibreElec 9.0 on a 3B+ using the unofficial SiliconDust PVR software with SiliconDust Quatro tuners and not having any frame skipping issues.
Its probably worth pointing out that the SiliconDust PVR client does not have a companion server component which runs on the local network (except what is in the tuner - that does not support PSIP, multicast, or transcoding.) There are pros and cons to this arrangement, but suffice it to say that your CPU load will be lower compared to those who are running a PVR service on same machine as the client.
I get the same thing, but on a Pi 2 once I upgraded to 9.0.0. Happens while playing Mpeg2-TS via TVHeadEnd PVR Plugin
If you can find a build of TVheadend for your router or NAS device, it would be preferable to use that instead of running the server on your media player. (And since the MPEG-2 patent expired, I also think LibreELEC should include the patched GPU firmware that activates hardware acceleration automatically.)
Update: I was able to reproduce this issue on the old 2-core Play 1. When I move the mouse rapidly, CPU usage nearly doubles. If I continue this for a while, it starts dropping frames and the audio loses sync. After about 10 - 20 seconds, CPU usage returns to normal but sometimes the audio remains silent until the channel is changed. It seems like the video player is running at a lower priority than it should - and if something pushes the CPU to 100%, sometimes it never recovers.Code
- WARNING: CRenderManager::WaitForBuffer - timeout waiting for buffer
- WARNING: Previous line repeats 16 times.
- WARNING: ActiveAE - large audio sync error: -1218.382589
- WARNING: ActiveAE - large audio sync error: -1216.828077
- WARNING: ActiveAE - large audio sync error: -1217.117625
- WARNING: ActiveAE - large audio sync error: -1209.260177
Was taking some screenshots through the CLI in RPi and just discovered the same command is not working on Play v1
# kodi-send --action=Takescreenshot
I checked in guisettings.xml to verify the path had not changed and its still the default
I also found that it works normally in the remote Web interface (Chorus2)
Services which have been accused of copyright infringement are not supported. I think some non-infringing addons were banned in the process, but the rules must be obeyed. This policy is aggressively enforced. (Maybe new users should get a message about it when the forum account is created.)
Update: in current beta for Play v1 this button now seems broken on the official remote:
Hamid was the only developer and he quit. Its not in the Fusion repo or anywhere else. Here is the last working version.
Why not use Discourse? It's free and open source. It can auto-resize images by default.
And if that is not enough you can write your own plug-ins.
1. If an image attachment exceeds 1 megabyte, the upload fails with an unhelpful message:
"An unknown error occurred during the upload"
2. In the message composition area, the forum incorrectly states:
"Maximum File Size: 2 MB"
-- the upload failed at 1.1 MB (or precisely 1,169,522 bytes)