Posts by S80_UK

    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.

    Info here...

    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.

    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.

    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...

    External Content
    Content embedded from external sources will not be displayed without your consent.
    Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.

    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.

    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 .

    I am a developer myself, so I know that I am running a pre-release and even pre-beta software which may contain lots of bugs. But as a User of such a software I see it as my Job to report bugs that I find in there, in order to help the devs fixing it.

    Then report them properly!

    As a software tester (I test software and hardware for consumer audio products professionally and as a former developer) I know that saying "it doesn't play properly" tells the developer nothing. A proper bug report will tell the developer everything they need to know about the file you were trying to play, its encoding methods, video and audio data rates, etc. It will tell them about the settings in the software, about the details of the video and audio outputs, and so on. Each of those things and many more could influence the software and whether or not it may play a file. A full debug from Kodi actually makes the task for the tester pretty easy.

    If you are a software developer, then you should understand the importance of detailed and accurate bug reports. Your brief description of the problem and assumptions as to where the problems may lie are not enough.

    How come someone takes the same LE packages and makes a functional piece of software that WORKS ??!!

    Study and learn, HTPC fanboys. Modularize!

    And thanks for nothing! ))

    Rather than a rant about modularisation, you could take a look at the vast amount of work that has been done over recent iterations of LE and recognise that modularisation has been a constant theme, with an increasing number of elements being modularised over the past couple of years. The fact that there is not a separate DLNA renderer "as standard" currently is a reflection of the needs and interests of the developers who do it for the love of it / for the fun of it. It is hardly a failing of the project and is certainly not worth such a criticism. With software such as LE, where the codebase is open, there's a very straightforward way or introducing changes such as you seek - try it yourself. If you don't have the time or skills, fair enough, but your apparent sense of entitlement does you no credit.