Posts by ronbaby

Another issue that I feel obliged to mention also...

Apparently, the Realtek WiFi chip in the Beelink MiniMXIII is crap. Or at least some comments I read today say it is. And having just tried to use it myself, I can say that that does in fact appear to be the case.

The good news is that I had/have my trusty old TrendNet TEW-684UB dual-band USB WiFi adapter lyiing around. So I plugged that into the Beelink's free USB socket, power cycled the box, and yes, I am now seeing lots of SSIDs that are reachable from either wlan0 or wlan1. (So I'm guessing that wlan0 is the built-in Wifi and that wlan1 is my external TEW-684UB.)

Assuming that I'm correct about that part, there is just one small fly in the ointment... I am *not* seeing my router's 5GHz band SSID anywhere in the available connections list. Bummer.

I was going to ask the question: "In general, do the kszaq builds include in-built support for a variety of USB WiFi adapters?" But it seems now that the answer to that question is "yes". The only disappointment is that it appears that only the 2.4GHz radio in my TEW-684UB WiFi adapter may be supported, and not also the 5GHz radio.

If so, I don't imagine that this is an issue that would be appropriate to raise with kszaq, or even with the LibreELEC team. I guess that if I want to report this non-feature I have to go off and try to locate whoeever is currently maintaining the relevant Linux kernel driver, yes?

P.S. For awhile there, I was going to report that the latest kszaq build was locking up my Beelink box. It sort-of seemed to be doing that. But in fact I think that the box was just getting really slow sometimes on account of the dirt-cheap wiFi chip in this thing. (When Kodi starts to do buffering over a slow link, it seems like it really doesn't want to be interrupted part way through doing that. Or maybe it's just me.)

Another issue that I feel obliged to mention also...

After putting the latest kszaq build onto my Beelink MiniMXIII, and after lodaing the "stock" Confluence skin on top of that, I went bonkers for a short while. desperately trying... and failing... to find out how to make adjustments to the type of the Internet connection being used.

Slowly, it dawned on me that the "stock" Confluence skin, quite rightly, lacks the special interface button to get at all of the LibreELEC-specific settings. So I had to switch back to Estuary to get at those.

I have no idea what a "good" fix for this problem would look like. Maybe kszaq needs to bribe the Confluence maintainer to get him to auto-detect when his skin is running on LibreELEC and in that case add in the extra button and controls. Well.. just a thought.

All I know is that I'm probably not the only person who is going to be using LibreELEC with skins other than Estuary, either now or in, the future, and thus, logically, it is unlikely that I will be the last person to ever raise this issue.

It would thus be Good if there were to be a generic sort of solution developed, but I understand that this is far easier said than done. (This seems like a classic N x M problem... you have N different versions of standalone Kodi implementations and M different skins to worry about. I'm not sure if there is even any way to insure that all of the N always work perfectly with all of the M.)

Back again... And now it appears that there actually is an issue relating to video calibration/scaling. (It wasn't just my imagination, and despite what I might have said awhile ago, I actually didn't fix it.)

Here's the story in a nutshell. As I said, I've got a Beelink MiniMXIII (original version) w/ 2G/8G, Gigabit ethernet, and (apparently) the Realtek WiFi. I just downloaded and fresh installed to a microSD card the latest and greatest 8.2-8.2.1.2 kszaq build and a proper device tree. I switched the thing to Confluence skin and did the video calibration, which I always have to do on account of the fact that I have a POS Panasonic flatscreen that does a 2.5% overscan, all the way around, and I can't disable that unfortunate "feature" in the TV. So I always have to force Kodi to do scaling (underscan?) to work around this annoyance.

Anyway, I got the video nicely calibrated to do the underscan so that all of the normal Confluence menus & stuff shows up just perfect on the screen. But then I went and tried to watch one of my ripped DVDs, and I jiggled my mouse to get the OSD to come up and overlay the DVD that was playing... which it did.

The problem is that it is clear and evident that the OSD stuff around the edges is only partially displaying. It is partly obscured by the physical edges of my flatscreen TV. In short, although the scaling (underscan?) that I set up when I did the video calibration is working perfectly, that scaling is apparently not being applied to the OSD display, when it is activated. The result, in my case, is that the OSD is mostly unusable, and most of its bits and pieces appear half-way off the physical screen.

I didn't check to see if this is a problem also for Estuary, but I kind-of-suspect that it isn't, or else a lot of people would have reported it already.

Anyway, I hope this can be fixed. It would appear that the calibration/scaling information is just being stashed in some place where the OSD code (in Confluence, at least) isn't picking it up.

I had tried out kszaq's (then current) build on my Beelink MiniMXIII some time ago and it worked just great... didn't even have to use a toothpick! The thing just booted from the microSD card, or so I seem to recall. But I only tried to use the box hardwired. Now I have reason to want to try out this box again, but this time using the built-in WiFi.

I know for sure that I've got the 2GB/8GB model with gigabit ethernet, and I'm pretty darn sure that I have the original S905 (not-X) model. So as far as those things go, I know which of the device tree files to grab, but I have no idea if I have Realtek WiFi or not. Do I? Is there any easy way to tell? Do I just need to try both the Realtek and non-Realtek device trees and see which one works?

Yea, that's kind-of what I figured. FleaBay is doing a lousey job of filtering out the garbage listing these days.

I just happened to be looking again at the "Android Devices" page on the Kodi wiki this evening, and I noticed that something called a Xiaomi Mi Box... which I had never heard of before... got a favorible mention.

I googled for that and ended up on FleaBay where, it appears some Chinese vendors are selling these boxes for under $13 USD... but Gearbest is selling it for around $47.

So, um what gives here? What am I missing? There must be a catch someplace.

But if I really can get these boxes for $13 USD, -and- if I can get a working LibreELEC on them, then I'll be buying a half a dozen of them to give out to friends. (What with the shipping time from China they will arrive too late to use as stocking stuffers, but might sill make cute gifts.)

So, does anybody here happen to know what the catch is on those eBay offers? (I can hardly believe that they can even -manufacture- these things that cheaply.)

I saw some sites where it is said that these boxes have booting locked down, so that you can't actually get LibreELEC on the things. Is that so?

OK. Thanks again.

P.S. As it turns out, the bug I mentioned isn't even in LibreELEC per se. I did more tests and found out that it is present also in Kodi on a Linux desktop system and also in Kodi running on Windoze7. So I filed a proper bugreport with the Kodi folks.

OK. I'll try that next time. Thanks.

So I need to type "live" at the boot: prompt, yes?

Just recently, I decided to try running kszaq's latest build for an ARM/s905 box I have. It was very simple to try this. I just downloaded the image, copied it to a microSD card and booted from it and I was running LibreELEC on the s905 box. Nice. Very simple. No need to futz around with an "install" step.

Today, I'm trying to nail down some particulars about a bug that is apparently causing playback to simply lock up, specifically when I am playing any member of a particular subset of the mp4 videos I have on hand, and when I use the left arrow button on my remote to try to skip forward. It appears that this bug is present in both kszaq's latest build for the s905 and also in the latest release (8.0.2) of LibreELEC for x86. In short, it is clearly not a hardware-specific problem.

Before reporting this bug formally, I'd like to try to pin down exactly what the last version of LibreELEC was that this actually worked properly in, i.e. just before the breakage occured. (I know these same videos had no problems with the ancient OpenELEC I had been using in the past.) If I can nail down when the breakage started... i.e. which exact version of LE... then perhaps I can help the developers to isolate whatever code changes caused the breakage.

But the thing is this: The x86 releases of LE seem to have this annoying requirement that you first put the "installation" image on a stick or a card, and then you run that to install the thing onto some different stick or card, and only then can you actually run the thing. This will quite obviously be tedious, e.g. if I am going to be experimenting with several successive x86 LE releases (which I do now plan to do).

So, um, am I missing something? Are there some LE x86 images someplace that can just be run (in "live" mode) without installing them? And if not, why not? It would be a great help to have such things.

NEVERMIND! It appears now that I did actually screw up the calibration. I got the calibration set properly now and everything looks terrific.

Sorry. My bad. my mistake.

This is really awesome. Thanks for all your hard work on this kszaq. These are terrific little boxes, and cheap too! Now I can finally make some good use of this, rather than as a mere dust collector.

Thanks for the quick reply kszaq. What about the OSD scaling issue? Is this just me, or can you reproduce it?

Maybe I just screwed up and didn't do an adequate job when I did the video calibration. I'm going to go back now and do the calibration one more time, just to be sure. But I really don't think I messed that up, so I really do think there is an issue here with the OSD scaling.

So far, this is the one and only issue that will cause me to wait before discarding my trusty old x86 book-sized home theater / Kodi box and switching over for good to the Beelink. (Everything else seems to be working perfectly.)

Greetings,

I bought a Beelink MiniMX III (2GB/16GB) many months ago, but the ports of LibreELEC available for it at that time were still a bit, um, raw, so I set the thing on the shelf for a long while.

Yesterday I downloaded the latest kszaq build, LibreELEC-s905.arm-8.2-8.1.9.img.gz, put it on an SD card, and the Beelink seems to be working great with that. But I have a few questions, and have noticed one apparent bug that may perhaps be something I need to report to the Kodi people, rather than to kszaq or to the LibreELEC people.

So, my questions:

1) Just curious: How come I need to use Rufus to transfer the .img file to the SD card? Could I just as well have DD'd it to the card instead?

2) I've noted that if I do a power down of the Beelink, via the LibreELEC interface, my TV shuts off too. I would prefer that it didn't. How can I disable whatever magic (CEC?) is causing this?

And now, the bug:

Sadly, I own a VERY annoying TV. This is a Panasonic 50" Plasma which was one of the last inexpensive ones they ever made. It has a very annoying non-feature -- It does a 2.5% overscan along all egdes, and there is really no way to disable this. (Believe me, I am sure.) Thus, no matter what Kodi device I hook to this TV, I have to get in and do the Video Calibration, right at the start, so that Kodi will do scaling to compensate for the TV's annoying overscan.

With this latest kszaq build for the s905 loaded onto my Beelink Mini MX III, I did perform the video calibration, and that makes almost everything display OK, however it appears that certain parts of the OSD that appear, e.g. if I move the mouse or skip forward (under Confluence) while watching a video are not being properly scaled. The results is that some bits of the OSD are actually only partially visible on the screen. (This is apparently true under both Estuary and Confluence.)

So, what do you folks think? Is this a kszaq/s905 specific problem? Or is it perhaps a LibreELEC-specific problem? Or is it a generic Kodi problem?

I'll report it, formally, and with all of the usual and required information (i.e. logs and such) but at this point I don't even have any clear idea who I should be reporting it to, specifically.

Any help in determining that would be appreciated.

Quote from chewitt

S3 mode works fine when the BIOS/hardware combination supports it (without bugs) and the user configured the BIOS correctly. Most issues are seen when the BIOS is buggy and when the "translated badly from Chinese" BIOS GUI confuses the user (PEBKAC) but we also see cases where hardware doesn't send/keep power to the special USB port during suspend properly (even when the BIOS is configured right) which ensures the receiver never sees the IR wake signals. So no idea what problem you have .. but that's a summary of where things normally break.

OK, lemme fiddle with it some more. My setup is kind of convoluted, but I think that I should be able to tell whether my HTPC is dropping power to the USB ports or not. (If it is, then obviously, as you noted, that's could very well to create a problem.) I guess that I also need to go back, yet one more time, and see if I've mucked up the programming of the Harmony remote. I'm guessing that I may need to re-jigger that to get it to send a proper "suspend" signal, rather than an "off" signal.
[hr]
Hummm.... OK, the depth of the morass that I've navigated myself into is just now beginning to become clear.

There's this whole huge (and very informative) thread over on the Kodi forums about how to get Harmony Remotes properly working with Kodi and, obviously, other home entertainment components at the same time:

HOW TO - Configure a Logitech Harmony Remote for Kodi

It would appear that one of the several problems I may have created for myself was that a long long time ago, when I first started using Kodi, I cheaped out and bought an $12 Ortek VRC-1100 remote... whose IR receiver I am now trying to use with my Harmony 600... rather than buying a real and official $20+ "eHOME RC6" remote. Sigh. My bad. But the VRC-1100 (and its IR receiver) does mostly work, so perhaps all is not lost. And I've just found some more stuff that I can diddle in the Logitech Harmony setup/configuration. So slowly but surely I'm getting to where I want to be with this thing. It's all just much more complicated than I had hoped it would be.

i'm still trying to understand all this, so I have to ask... Those of you who said that you've seen setups where LibreELEC is able to be put into (and then taken out of) the S3 state... can you please tell me exactly which remotes you were using and which buttons you pressed to accomplish that feat? That information might help me to figure out how to get this working also with my own peculiar set of hardware.

OK, well, I lied. The real issue isn't really one of power consumption. (I just said that because it seemed simpler than explaining the real issue.)

The real issue is this: I'm trying to get all of my home entertainment toys to work right and play well with my Logitech Harmony 600 remote. And it ain't easy. The Harmony wants to be in control of everything. It wants to be able to turn all relevant components both on and off when initiating and stopping an "activity". I've been wrestling with it for two days straight. It's just a finicky little beast. It just doesn't want to grok the concept that there is some home entertainment component in my arsenal that it cannot turn both on and off, you know, with just IR signals.

So, you know, life would just be a lot simpler if IR signals could put my x86-based HTPC into the S3 state, from which it could be woken up again with another appropriate IR blast.

This isn't about "legacy" hardware. Anybody whose got an x86 HTPC and wants to use a Harmony remote is going to have the same issue, and will be yearning for the same solution, i.e. having the "Off" button on the Harmony put the x86 HTPC into the S3 mode, from whence the Harmony can raise it from the dead again. (And x86 systems are not in any sense "legacy" systems when it comes to running Kodi or OpenELEC or LibreELEC. Believe me, I've tried using Kodi in different ways on ARM harware, and in my experience, it just still isn't nearly as stable and bug-free as running Kodi on x86 is.)

Anyway, even ignoring all that, it seems kinda nuts that the x86 hardware manufacturers went to all this trouble to invent, standardize, and implement this "S3" mode... all obviously for the benefit, specifically, of people wanting to use x86 systems in home entertainment contexts... and then the world's premier x86-compatible media player, i.e. Kodi (personified by LibreELEC in this case) can't even make use of this special hardware mode that was clearly created exactly and specifically for home entertainment purposes and contexts.

P.S. Since you asked, I am currently using libreELEC 7.90.009.

Hey, sincerly, thanks a lot for the tips! I had the menu mode set to "Advanced" but obviously, "Expert" was what I really needed. So now I have the overscan calibration problem sorted out, and thanks to the clues you threw me I've also managed to selectively disable VDPAU for WMV3/VC1, so that's all good now too. (Well, anyway, my vids are playing OK. But I hope and trust that you guys will keep it in the backs of your minds, for the future, you know, that VDPAU HD accel for WMV3/VC1 just plain isn't working, at least on AMD GPU hardware.)

Anyway, I'm a happy camper now. One of the main menu screens for one of my ripped DVD ISOs came up as just an all black screen, but other than that one very minor thing, everything else is working beautifully now.

Quote from lrusak

no more work is going into the 7.x line, I suggest you update to the alpha builds and report back

Ok, I just now downloaded and installed and tried the 7.90.009 image for x86.

The good news is that the left mouse button now works OK.

The bad news is that playback of WMV3/VC1 video still comes out as utter gibberish on the screen. So, you know, that looks like a major problem there. (Again, this is on an AMD APU, and an attempt is being made, by LibreELEC, to use VDPAU for decoding these videos. I could just turn off the VDPAU HW acceletarion, but then if i do that, some of my higher bit rate MP4s won't play.)

Anyway, by trying out this new test release, with the new skin, I've found an even worse problem.

It appears to me that in this new skin, the ability to calibrate the size of the displayed image has been completely removed. I found a "calibration" section in one of the menus, but it only allowed for selection of either 2 or 3 video buffers. Gone is the ability to adjust Kodi to compensate for overscan. This is an enormous problem for me, because I have a particularly brain-dead Panasonic 50 inch plasma that insists on doing 2.5% overscan and I can assure you that there is no way to turn that off, period. (I looked into this ad infinitum, and this was just some Panasonic engineer's stupid idea for a way to save money and make the lower priced models in this line of TVs less capable. The higher models of this same TV do have firmware and menu adjustements that allow the overscan to be disabled, but not this specific model.)

So anyway, unless somebody puts back the old Kodi capability to actually calibrate the displayed image, you know, in order to adjust for (stupid) display overscan, I guess that I'm going to be stuck on using only pre-17 Kodi versions forever... or at least until I buy a new TV, probably sometime in 2023.
[hr]
Oh! And by the way, a 2.5% overscan (on each side of the image) may not sound like a lot, but I can assure you that it is enough to make the various skin menus mostly or entirely unusable.

The following comments are all relating to LibreELEC (official) 7.0.2...

I've been changing around a LOT of my home entertainment hardware lately, and as part of all this, I decided that it was about time for me to "upgrade" from the trusty old OpenELEC 5.0.8 that I've been using for a long time now on my AMD E-450 based HTPC to the latest and greatest official LibreELEC release.

Well, I tried that, and mostly everything still worked (which is the good news) but I encounted two regressions that are serious enough to force me back to OpenELEC, at least for the time being. These are as follows:

1) Apparently, LibreELEC 7.0.2 tries to use ff-wmv3-vdpau (HW accel) to render any and all WMV3/VC1 videos on this hardware, and I'm sorry to report that, for me at least, this seems to fail 100% of the time. LibreELEC obviously believes that it is playing these videos just fine, but in fact, the screen just gets filled with pixelated gibberish, tending heavily towards the greens. I've checksed carefully, and this is only a problem strictly and only for WMV3/VC1 videos. WMV1 and WMV2 videos play just fine, as do all MPEG4 or MPEG2 videos. And to be clear, the problems arises when playing either WMV3/VC1 main profile vids or advanced profile ones.

(This seems to me a glaringly serious and glaringly obvious bug, and I'm a more than a little preplexed that nobody else has already reported it. Has anybody else already reported this?)

2) LibreELEC 7.0.2 seem to mostly properly support my Logitech M305 mouse... as did OpenELEC before it... but with LibreELEC 7.0.2 the left mouse button just doesn't seem to have any effect at all anymore, which is distinctly un-good.

I hope and trust that the above two problems can be resolved in some future release, because I really do have the goal of switching over to LibreELEC as soon as I can do so without losing critical (to me) functionality.

P.S. OpenELEC 5.0.8 only tried to use ff-wmv3-vdpau (HW accel) just for WMV3/VC1 advanced profile videos. It made no attempt to do HW accel for WMV3/VC1 main profile videos. I am pleased to see that the libreELEC team is apparently working to try to implment HW accel for all kinds of WMV3/VC1 videos, and will be even more pleased when that effort bears some usable fruit.

Until then however, I wonder if there is a some way of simply tweeking LibreELEC to get it to simply never try to use ff-wmv3-vdpau. If there were a way to do that, then that might be an adequate work-around for me, until such time as LibreELEC's use of this decoder can be made to work reliably. (None of my vids are of sufficiently high bitrates so that they even need the HW accel, given the strength of the CPU I'm using.)

I have an older and relatively power hungry HTPC, and it would be Nice if I could make this thing wake up from the comfort of my couch. I looked at the BIOS screens and it appears that it does have an enable/disable setting in the BIOS which allows the thing to wake up on USB input from state S3. (My remote is a USB remote, BTW.)

I'm guessing that quite a lot of x86 hardware has this same sort of capability, in the BIOS at least, i.e. support for waking up on some USB input while in the S3 state. And I'm also guessing that I'm probably not the only person who has a power hungry x86 HTPC kind of thing and who would also appreciate it if LibreELEC would implement proper support for the both sleep and wake using this S3 state.

P.S. As reported by at least one other guy, i tried using the "Suspend" button in the libreELEC GUI, and the HTPC system -seemed- to kinda sorta shutdown, but then it came right back on again a second or two later.