...it's incredible for a platform focused on media player...
If by "platform" you refer to Raspberry Pi - that is not focused on being a media player. It is developed by the Raspberry Pi Foundation as an educational tool. It just happens to be able to be used as a media player.
Maybe some perspective is needed...
How much did you pay for an AV receiver to decode and play the audio through your speakers...?
How much did you pay for your speakers...?
How much did you pay for the Raspberry Pi that you expect to do so much...?
How much did you pay for the software that you seem to expect to be able to play everything on a very low-cost hardware platform...?
Too many people (you are not alone, see elsewhere on this thread or on the forum) seem to expect that everything should work just because the developers choose to give their time and effort for free and choose to share the results of their labour with the rest of the world.
If things don't work, one of the benefits of open source projects is that anyone can contibute. And with LibreELEC, if you can't contribute to development, there are still other ways to help. But as Klojum has said, sometimes the project is also dependent on other things working first, and the developers may have no control over that. This can especially be true when the platform uses silicon where the suppliers do not provide open documentation to all that may need it.
Just for a test, try moving the bedroom RPi much closer to the living room if possible.
Strictly speaking, you need to try shortening the distances to the router, since the communication between the devices will always have the router in the middle (unless you set up an ad-hoc network without a router). Moving the Pi in the bedroom won't help if the router is also in the bedroom, for example. Shortening the distances, check for possible interference from other routers (neighbours' networks), rebooting the router, etc. can all help. Many routers have quite poor software which can degrade the router performance over time, and a reboot can help in such cases. If you have an Android device, there are WiFi analyzer apps available to help find less congested spaces in teh WiFi spectrum.
Are most LibreElectric users Raspberry Pi users?
I think this is very likely to be the case.
Cetainly x86 platforms are not the majority use case, although they are preferred by some (myself included).
I think it's possible, because CEC data is merged into A/V data. RPi4B uses a different graphics driver to deal with higher resolutions and two HDMI outs. CEC signals have to be filtered out of the HDMI stream, before CEC adapter can handle it.
This is almost 100% incorrect... (sorry...)
CEC data is never part of the AV stream. In fact, CEC is a separate LOW speed interface (actually a bit like a slow I2C bus). It uses a separate line in the cable from the AV data. Most cables will include CEC support, but there are some that do not.
May I suggest - tell people what TV you have, which input on the TV you are using, what model is your AV receiver, which input, what types of cables (HDMI 2.0 ?), and so on. Further information such as which resolution modes are enabled (whitelisted in LibreELEC), and details of the HDMI capabilty of the receiver (what HDMI standards and what resolutions supported) may also be helpful. You have given so little information that no-one will be able to make helpful suggestions.
True. My point was, it's not just CRTs, but older TVs with HDMI and so on. But you're right - it's a very long time in terms of modern product life cycles.
Why would you need calibration anyway?
What is your display, and old CRT monitor/TV ?
Every recent TV has its own settings for a 1:1 pixel display, and in that way, disabling overscan.
Just an FYI - there were quite a few TVs from the plasma era (as late as 2007-2008) which did not support any overscan control or override. I had a Panasonic plasma from 2007 with exactly this issue and I always had to use the calibrate feature until just two years ago when I changed up to a 4k OLED. The good plasmas were so good, it wouldn't surprise me if there's still a moderate number in use.
Interesting that I only pasted in the link to that page of configuration info, but the forum seems to be presenting the content from that link embedded in the message. That was not my intention; sorry. I probably should have flagged it as a URL in some way.
If I enable wired and wireless network in LibreELEC, what happens?
I think it will only use one of them (not sure which though - I don't have that hardware).
I found this...
It says it's a list of pages for the router settings that are not gennerally accessible. You may find a page to allow devices on Wireless and Wired parts of the router to talk to each other.
In my experience routers that provide isolation between wired and wireless devices in this way cause more problems than they solve. It can prevent all kinds of things from working, including app control of wired devices. Another related problem is that device discovery fails to work properly if multicast packets can't get from one part of the network to another. Unless you really need to restrict things in this way I would start with a better router.
The are supposed to be green and grey, at least with the default skin.
Sorry - I forgot that I use Confluence (I cannot tolerate Estuary). I shall take a look though to see if that was part of my problem.
I only whitelisted 1080p50 and 1080p60.
Just a thought - when you say that you white listed them - did you make them White or Yellow in the list? Bizarrely the whitelisted refresh rates should be set to yellow. (I have no idea how that came about but it's not helpful IMHO.) The rates that remain white are effectively not used, so they are actually black-listed. I had stutter issues with some interlaced blu-ray rips today until I figured this out.
This has to be one of the rudest requests for help that I have ever seen. I realise that your first language is not English, but you clearly have little understanding of how software such as Kodi, LibreELEC and others are developed by people who do things voluntarily and because they want to do them, not because of demands such as this.
You might wish to consider editing your post. Less shouting and more consideration for the work that is done may actually encourage someone to help. As you have written your request at the moment, I do not expect any developer to reply.
SMBv2 basically requires full credentials, thus name plus password, and it no longer supports network browsing. Meaning you will have to use the "Add a network location..." option for connecting to SMB video/music/picture sources.
Minor typo in the above...
5v is only half the story and mostly not the problem.
Sufficient amperage is key here.
Agreed. Voltage regulation and sufficient amperage are very importand. You also need adequate quality cables and connnectors to ensure minimal voltage drops. The problem is typically that USB power supplies that have enough current capability are often compromised in terms of their ability to maintain a good 5 volt supply at the connected device due to the cabling. USB specs allow for some voltage drop, but the short term current spikes required by some platforms such as the Pi can be significant and often result in excessive voltage drops unless the cable is adequately rated. The problem only gets worse with longer cables, of course.
Just a thought - I don't think that FLAC audio encoding itself will generally be the problem, but maybe it is exposing a problem elsewhere. For example, could it be related to the tagging? Maybe the tagging format or content is slightly different in the newer files. Did you transcode from FLAC encoded using 1.2.1 to FLAC using 1.3.2 or did you re-encode from some other format? If you aren't familiar with it, take a look at dBpoweramp and try batch encoding a bunch of files. It's pretty quick, very little work, and it may help. The tags will be retained and embedded in the newer file.
Agree. I am not one of the "Political Correctness" brigade, but having worked in the semiconduction industry for some years, where there were quite a few wives in the business who were more capable engineers than I, I am of the view that the expression is due for retirement. In most cases that I can think of, the terms "not very user friendly" or "may present technical challenges" can be worked into a sentence just as readily, and they are probably less ambiguous to users who do not have a knowledge of such English colloquialisms .