Code
WireGuard.Address = 192.168.4.2/24What happens with /24 instead of /32 ?
Posts by chewitt
-
-
but unfortunately on S905 720p also stutters, although there is no big difference in raw computing performance.
There is a sizeable raw compute performance difference between S905 ([email protected]) and S905X3 ([email protected]+) hardware.
-
Oh, one other question - will it support h265 playback?
Yes, HEVC/H265 is hardware decoded to 4K60 and HDR with 10-bit depth.
-
You can do "dmesg | paste" and "cat /storage/.kodi/temp/kodi.log | paste" to generate two URLs; one for each log. If either of them is large the combined logs + extras that "pastekodi" generates might be too large for the ix.io paste service.
-
Would you recommend a 4 or 8GB Rpi5 for running LE?
I wouldn't look at the 8GB model unless planning to run containers and such in the background. For normal LE use a 2GB board would be fine so the lower spec 4GB board is more than enough.
-
Would LE install onto a zidoo z9x pro
100% no, it has a Realtek RTD1619BPD SoC chip with zero upstream kernel support.
-
This is a box for the pirate BeOutQ satellite service in the Middle-East (targetted at Saudi Arabia). According to a UEFA report on the box that I found in Google it has a Montage M88RS6060 tuner and this chipset has drivers in the upstream kernel (CONFIG_MEDIA_TUNER_M88RS6000T) which are not currently enabled in the AMLGX image; but the user behind the video has presumably self-built an LE image after enabling the needed things.
LE10/LE11/L12 all support DVB hardware (internal or external) *IF* the hardware has upstream drivers. Your WP2 box has old drivers written for 3.10 kernel that were ported to 3.14 .. and nothing newer. I made an attempt to clean-up the tuner/demod/diseq drivers (enough to compile them on a recent/current kernel, see https://github.com/chewitt/linux/commits/dvb-sucks) but these drivers are not modular following modern kernel standards and more code-glue is needed to make anything work; and AFAIK the signal from the tuner and demod needs to be processed by an Amlogic demux driver which doesn't exist. I have no real clue how the DVB stuff works and I don't write code .. someone that does needs to take that work forwards.
TL/DR; nothing new .. nothing that will advance the non-support for the tuners in your WP2 box.
-
To my ears that sounds like even greater justification
-
Thanks for confirming. The change will go into LE12 with https://github.com/LibreELEC/LibreELEC.tv/pull/8201
-
I'm reading your description and my first thought is .. this user needs to get a NAS box and migrate the mess of USB drives and cables and wall-warts into a single device that just sits in the network serving media. Not the cheap option, but it'll be a pile more reliable for any client box/board to work with and you'll quickly forget all about USB woes and focus on movie watching.
NB: No idea about numbers of drive limits or power limits; not my area of expertise.
-
Would there be away to write Libreelec it to the onboard flash so it doesn't have to keep booting from the SD card?
In short, no, we would need the original u-boot sources from the vendor to extract needed boot files to build a dedicated image.
Have a read of this for the remote: https://wiki.libreelec.tv/configuration/…ration-advanced .. the article needs updating to reflect a move to "toml" format files. If you look at the existing .toml files in the filesystem (find / -name *.toml) you'll see the format is very slightly changed, but still easy to crib.
-
Have a read of this: https://wiki.libreelec.tv/configuration/4k-hdr .. the HDR bits aren't relevant (S905 doesn't support it) but everything else regarding adjust-refresh and modes will probably help with playback. Otherwise the big fat disclaimer on what works/doesn't-work and the general state of decoding in the AMLGX image that's in the public release notes applies.
-
Hard to say .. I've done little testing recently due to being on a different continent to all my test kit
-
No idea on the SMB issue; look at system logs on the Windows side and LE system (not Kodi) log.
RockPro64 is nice hardware RK3399 but despite having a sample somewhere I've done little with it and can't speak from experience about how it runs LE these days; my general impression is that RK3399 doesn't have all its capabilities supported (but I could be speaking out of my rear .. since I don't use them much/ever).
RPi5 is faster and despite being technically less capable on-paper in terms of codecs is probably more useable today, and I speak from the personal experience of using one over the last few months during pre-launch dev/test. RPi5 would be my go-to (as it already is).
-
Pi codecs are pretty robust, but ultimately they are large and complex software so there's always opportunities to throw weird media at them and cause new crashes. Hence the request for a snippet that causes the problem; pi devs like those and will typically investigate to see if any changes can be made to avoid the problem and play the media, or at least fail more gracefully.
Leaving DRMPRIME off is proably not what you want as it means all media is software decoded and at some point that'll cause different issues.
-
Recycled RPi3 or a current RPi4 (or RPi5 once it ships in a few weeks) with an analogic DAC card (HAT) to create the RCA outputs. It's a little bit more fiddly to assemble than something that ships in an all-in-one box, but it should be cheaper than £200, and it's based on the most reliable hardware that we support. Lots of Pi DAC cases available here: https://thepihut.com/collections/raspberry-pi-audio-cases and most DAC cards give really good quality audio output, unlike the all-in-one boxes intended for HDMI use where analogue is an afterthought.
-
LE aims to be a minimalist OS so we don't pre-embed the full 350MB of linux-firmware needed to support all cards; so an educated guess is the driver modules are present in the kernel but the firmware blob(s) needed for the card to boot are missing. Run "pastekodi" and share the URL generated so we can see the boot log. It will normally flag the missing file, which can be manually downloaded/installed to prove that the card works once files are added, and then we can pick those files into the AMLGX image so manual fiddling isn't needed in the future.
-
Now what needs to happen is to email the alsa-devel mailing list with a plain-text email (not html) that has a good description of the problem, some log examples (via pastebin links) of before/after, and the contents of the files that you generated. Then hopefully one of the names on the list can spot what kind of exception/quirk needs to be added to eliminate the workaround. If you do that and you're given a patch to test, ping us back because it's fairly simple to spin an LE image with the patch and have you test it.
