Posts by ronbaby

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.

Quote from lrusak

The best thing to do would be to follow our rss feed. Perhaps there is a recipe using ifttt that will email you when a new rss post is made.

RSS link: feed

That's still a "pull" solution, and thus less convenient, because I'd still have to be looking at it on a regular and/or frequent basis... even though most of the time there will ne no new news or announcements.

A "push" solution, like an announcement mailing list would be more conenient for those who want to know about new developments, but can't spare the time to check the web site every day until something new actually is announced.

As I understand it, one of the main rationales for this project is that support for new hardware platforms will be more of a priority.

That's absolutely terrific, of course, but I wonder if you guys might consider implementing a low-volume "announcements" mailing list to inform people whenever you first make an official release for some new hardware platform.

Unfortunately, I don't have time to come and scan all new postings in these forums on a daily or even weekly basis, but I sure would like to know about it whenever you guys make an official release for a new platform/machine, particularly any ARM-based ones.

P.S. Actually, I have my eye on one specific type of box, but I ain't gonna buy one until you guys say you have an actual supported release ready to go for it. More generally, I'm interested in everything that's going on it the ARM space, so would like to know about any specific new announcements from your project relating to any ARM-based machine(s).