Posts by ronbaby

NEVERMIND!

It appears that, for reasons I am none too clear on, when I booted my old USB stick with LibreELEC on it on the newer BI320, for some reason the network settings got magically switched to (dynamic) DHCP rather than the static IP that I had previously had the network set to. And since the NFS exports from my file server are limited and accessible only from a small number of IPs on the local network, and since DHCP caused the new BI320 to dynamically get assigned an IP outside of the allowed IP address range for my NFS shares, those NFS exports were coming up as being inaccessible.

Manually setting the network again to use a static IP within the range permitted to access my NFS exports over on the file server seems to have made everything good again.

For a long time, I have been using a Zotac Zbox BI320 as my livingroom media player with LibreELEC. I works great. Recently, I found another use for that box, so I bought a second one off fleaBay. It is also a BI320 and thus identical in essentially every respect to the original BI320.

I am a cheapskate, so I've been booting LibreELEC on the older BI320 from a SanDisk USB 3.0 stick... not that that matters to my story.

For connectivity, I have the BI320 hardwired to a Linksys WUMC710 media connector which supplies connectivity to all of my livingroom media things.

So, I took delivery of this second BI320, and I put it exactly where the original one was, wired it all up exactly like the original BI320 and booted it from the same USB 3.0 stick as I was using before with the other BI320.

It booted OK, but now, none of my NFS shares are working. So, I mean, what the hell? I took the newer BI320 into my workshop, booted Ubuntu on it, and verified that the ethernet on it is working just fine.

When LibreELEC gets installed onto a USB stick, or onto whatever, does that process LOCK the installation to a specific ethernet MAC address? That's the only theory that I can come up with as to why the installed LibreELEC on the USB stick works just fine in all respects on my original BI320 but seems to be unable to do anything with the (verified working) ethernet port when the same USB stick is inserted into the newer BI320, which is in all respects, identical to the original one, except for the MAC address, of course.

Nevermind! I just checked Kodi 18.2 on Linux/Ubuntu and the problem appears to be present there also, so this is NOT exclusively a LibreELEC issue, and I will be taking it up with the Kodi people directly.

Quote from llkobe

Ummmm... I sold my old AMD-based HTPC right around Feb. 25, 2018. Now I own a different (Intel-based) one.

It's great that you folks put in better AMD GPU support, but it is a bit late for that to do me personally any good. Nor am I any longer in a position to be able to test your new AMD fixes. Sorry.

This problem has been bugging me for some time. I'd like to know if others can reproduce it. I don't even know yet if this is a bug in LibreELEC or maybe in Kodi itself.

I watch a lot of movies. Mostly, I make .iso rips from DVDs and then watch them later.

Some nights I get sleepy in the middle of a movie and stop it in the middle, intending to return and watch the rest of the movie the next day.

When I do return to watch the remaining (as yet unseen) part of a DVD .iso, Kodi/LibreELEC always offers me the option to resume watching where I left off.

This "resume" option works just fine in the case of .mp4 files, but for quite a long time now it is been failing entirely for DVD .iso files. Even if you select the option to resume where you left off, LibreELEC ignores you and ust plays the DVD .iso from the very beginning again anyway, which is rather annoying, because then I have to spend time seeking to get back to where I left off watching.

So, is it just me, or can others reproduce this bug also? If so, I'll file a proper bug report.

As I said, something isn't adding up here.

I had a spare Sandisk Flair 32GB USB stick lying around so I downloaded and did a fresh install of Ubuntu 16.04.3 LTS onto that and then booted my AMD E-450 HTPC using that. I followed the directions on the Kodi web site to install Kodi, fresh, onto this system, but it appears that Kodi 17.6 was already pre-installed.

I ran a couple of tests and sure enough, playback of VC-1/WMV3 videos works just fine when the latest Kodi is layered on top of a recent vintage Ubuntu. The complete log file for these tests is here.

So, the obvious question is: What is broken in LibreELEC, relative to Ubuntu+Kodi? And shouldn't that get fixed?

Do I have to resort to using full-blown Ubuntu+Kodi in order to just simply play WMV files? It seems so, at present. But I thought that this was exactly what LibreELEC (and OpenELEC before it) were intended to make unnecessay. No?

Ubuntu: 16.04.3 LTS

Kodi: 17.6 Git:20171114-a9a7a20

Quote from chewitt

Like finance investments "past performance is not a guarantee of future performance" and with GPU drivers we are ultimately dumb consumers of what the vendors publish. I'm far from being an expert on the history of things, but VDPAU is dead and newer AMD drivers use VAAPI (as does Intel) which is still evolving. It's worth Googling the driver mailing lists and vendor bug trackers for issue reports and responses, because ultimately that's where things need to be reported and resolved.

Well, I just mentioned VDPAU because I had seen the name before a few times in relation to AMD/ATI GPUs. In truth, I don't know for sure VDPAU has anything at all to do with this issue.

Anyway, if VAAPI is the new/current way to get functionality out of AMD/ATI GPUs, then perhaps there is just simply a bug in the way LE is attempting to use VAAPI for older AMD/AMD GPUs (specifically with respect to VC-1/WMV3 decoding).

As I said, this did (and does) work just fine when I revert back to OpenELEC 5.0.8. So there has just been some breakage, somewhere along the line.

I wish that somebody on the LE team would at least take a quick look at the issue and see if there's something simple that could be tweeked to get it working again. But I guess that the motivation isn't really there.

P.S. I'm just reading the Wikipedia pages relating to VAAPI, and it says that from 2009 onward, there was what I would term a VAAPI "shim" that provided a VAAPI compatible interface to AMD's proprietary fglrx Radeon driver. So if that existed as far back as 2009, I am guessing that OpenELEC 5.0.8 was/is probably using that successfully to drive the UVD2 portion of this AMD E-450 I've got. If so, then that begs the question: Why shouldn't that be working just as well today, with LibreELEC, as it was several years ago, with OpenELEC? The hardware hasn't changed, so it seems apparent that some software bitrot just crept in someplace.

Did fglrx drop support for older AMD/ATI GPUs? I rather doubt it.

This isn't adding up.

Quote from chewitt

MT7610U has a Linux driver that "works" but makes crappy Realtek drivers look like polished perfection. It does not follow basic kernel standards for important things like wireless regulatory domain and is not of sufficient quality to consider adding into LE. The related but older MT7601U was ground-up rewritten and has had in-kernel support for about 18-months, but there are no signs of it being extended to the the newer mediatek chips. As is usual for far-east wireless chip vendors, they appear to have no interest in Linux.

Yea, I kinda guessed that the story (on Linux support for this chipset) would be along the lines you have stated.

I wish I had some magic bullets to fire into the heads of the execs of these far-east chip vendors that would make them care about Linux. Sigh. But I guess that as long as they can build things that they can sell to Windoze weenies...

P.S. I think that I saw on TP-LINK's web site that they do have OSX drivers for this thing. One would think that maybe those could be leveraged for Linux somehow, but maybe not.

I think that I should become a Linux driver writer. Guarranteed job security, because there are always new devices like this coming to market.

I just picked up one of these, brand new, for practically nothing on FleaBay. Works like a charm on Windoze7 and quite fast.

I was slightly disappointed to see that getting the thing to work with anything Linux-y requires reading a lot of length threads (e.g on the Ubuntu forums) followed by some unspecified amount of futzing around. This would have been useful with my HTPC otherwise. Oh well.

USB device ID is 148F:761A and apparently, the thing is alleged to contain a MediaTek MT7610U chipset.

If anybody is maintaining a hardware support wish list, please add this.

Quote from smp

It's probably worth a try to compile a build with downgraded xf86-video-ati package.

Thanks for the suggestion, but I think I'm going to take a pass on that.

LE should support this hardware out-of-the-box. OE did, once upon a time. If LE just isn't going to do so, going forward, then it doesn't make sense for me to build my own custom version of LE every time there is a new bugfix release. If this HTPC just isn't going to be supported, then it makes more sense for me to just trash it and get something else which will actually be supported... like fer instance a Zotac Zbox BI325.

It's a pity, because this is a nice and very functional box that does (mostly) everything I need, and it has been highly reliable for several years now. (I'm frankly surprised that the power switch on the thing hasn't gone bad. I've given it plenty of exercise, over the past several years. I guess I got lucky and got a well-built one. This is a Foxconn NT-A3700-0H0WBANA.)

Sorry for the delay. I've now had a chance to do some testing to try to determine how far back this self-evident bug goes. As of now, I have tested:

8.2.2

8.1.1

8.0.1

7.90.009

7.0.3

All of the above versions exhibit the same exact (and very glaring) bug, i.e. total garbage, flashing, mostly pixelated, and mostly green output to the screen during playback of VC-1/WMV video, at least on my trusty old AMD E-450 based HTPC, however...

I just tried the exact same tests also on my AMD-based desktop system (containing an AMD A4-6300) and with the LE 7.0.3 release at least, the video playback of VC-1/WMV3 was just fine. So I'm guessing that the problem is limited to older-vintage AMD/ATI/Radeon GPUs.

I confess that I don't know very much at all about video acceleration on AMD/ATI/Radeon GPUs, but I gather that it involves something called VDPAU, and thus, I guess that there is... and perhaps always has been, from the beginning of the LibreELEC project... some very serious breakage in the way that LE is using that interface, at least for older vintage AMD/ATI GPUs.

Sigh. It's a pity, because this stuff did actually work, e.g. back when I was using OpenELEC 5.0.8. So somewhere along the line, breakage was introduced into the code. (This qualifies as a "regression", I think. It used to work, but now doesn't.)

So, um, if I want to continue watching my old WMV and VC-1 files (e.g. my rip of the Doctor Zhivago BluRay) and if I also want keep up-to-date, you know, as LE evolves, do I have no choice now but to finally bite the bullet and buy myself a Chromebox?

Quote from chewitt

Two things:

a) So far you are the only person to report it. So do some testing and step backwards to tell us the last working release.

b) Test a current milhouse (Leia) release, because there are no plans for more 8.2 releases

OK, I will do both (a) and (b), but do you or anyone on the team happen to have any AMD hardware the you could just try playing a WMV3/VC-1 file on? I do believe that the problem will be evident if you just do that.

Oh! And please explain to me where I can get this "current" release you have mentioned. I just downloaded that 8.2.2 Generic X86/64 file yesterday, and that did seem to be the most current available at that moment. I guess that you are suggesting that I look around for a "nightly" build, yes?

I'll post a full and proper bugreport, if necessary, but this problem is so amazingly glaring that I can't imagine that will even be necessary.

On AMD (x86/64) platforms... which is all I have access to at the moment... playback of WMV3/VC-1 files is totally hosed in the 8.2.2 release. I get just rapidly flashing, highly pixelated, and mostly green garbage on the screen. I've tried playing several different WMV files and the result is the same for all of them.

I can't image that I'm the only person to have noticed this, or to be able to easily reproduce it.

Could someone please confirm?

Quote from negt

Can't you do the Internet connection adjustments in LibreELEC Configuration under Programs, at least in Confluence?

I have no idead how to do that. If you instruct me, I'll try.

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?