Posts by ronbaby

Ahhhhh! Got it. Thank you.

P.S. I'm not much of a systemd guy, as you can probaby tell. Mentally, I'm still back in the good old initd daze.

Ooof! Thank you! You hit the nail on the head. I removed the "-o " and now all is working.

Who knew that the fix was so simple... but also not at all entirely obvious? (I guess I am just too literal. When somebody says "put options here" I assume they mean the whole thing.)

OK, so, to close this thread out I'd like to just humbly suggest a couple of minor changes to that page that documents this whole procedure for setting up LibreELEC as an NFS client:

1) Either put "nolock" on the example Options= line on that page or else include rpc.statd in future releases (or ideally, do both of the above, i.e. the "belt & suspenders" approach).

2) Mention somewhere on that same page that if one happens to make a typo in one's /storage/.config/system.d/storage-<whatever>.mount file and if one then does the "systemctl enable" step that it is important (as I learned) to do a systemctl disable on the named file or else the old (erroneous) version of the storage-<whatever>.mount file will not get properly flushed.

Good suggestion, however still no joy.

From the root shell, this works perfectly:

mount -t nfs -o nolock 192.168.1.2:/y /storage/y

With the above, the volume gets mounted, no problem. So I put -o nolock on the Options= line in my storage-y.mount file, then I did:

systemctl disable storage-y.mount

(which I now know is necessary to clean out any possible prior cruft) and then, from the root shell I again tried:

systemctl start storage-y.mount

This resulted in the following error:

Job failed. See "journalctl -xe" for details.

Looking at the journaled relevant errors, I see:

Apr 27 12:42:54 LibreELEC systemd[1]: Mounting storage-y.mount...
Apr 27 12:42:54 LibreELEC mount[1211]: mount.nfs: rpc.statd is not running but is required for remote locking.
Apr 27 12:42:54 LibreELEC mount[1211]: mount.nfs: Either use '-o nolock' to keep locks local, or start statd.
Apr 27 12:42:54 LibreELEC mount[1211]: mount.nfs: an incorrect mount option was specified for /storage/y
Apr 27 12:42:54 LibreELEC kernel: nfs: Unknown parameter '-o nolock'
Apr 27 12:42:54 LibreELEC kernel: nfs: Unknown parameter '-o nolock'
Apr 27 12:42:54 LibreELEC kernel: nfs: Unknown parameter '-o nolock'
Apr 27 12:42:54 LibreELEC systemd[1]: storage-y.mount: Mount process exited, code=exited, status=32/n/a
Apr 27 12:42:54 LibreELEC systemd[1]: storage-y.mount: Failed with result 'exit-code'.
Apr 27 12:42:54 LibreELEC systemd[1]: Failed to mount storage-y.mount.

Here is my storage-y.mount file. It isn't complicated.

[Unit]
Description=nfs-y-script
Requires=network-online.service
After=network-online.service
Before=kodi.service

[Mount]
What=192.168.1.2:/y
Where=/storage/y
Options=-o nolock
Type=nfs

[Install]
WantedBy=multi-user.target

I'm stuck. Any help would be appreciated.

P.S. based on what you said I will no longer say uncomplimentary things about SMB, however I personally am already all set up on my primary file server with NFS (and lots of content), so I am certainly planning on sticking with that.

P.P.S. Since the preferred/recommended (systemd) method of getting my NFS volume mounted on my LibreELEC machine doesn't seem to be working, could I accomplish essentially the same thing by just placing the command:

mount -t nfs -o nolock 192.168.1.2:/y /storage/y

which does work, into some file where it will always get executed on boot time?

P.P.S. In the future, should LibreELEC ship with /usr/sbin/rpc.statd to provide another way around these issues? Looking on my Ubuntu deskptop system that daemon is only 0.08 mebibytes big, so not really too burdensome in the grand scheme of things.

I am attempting to update my trusty old x86 HTPC from an ancient version of OpenELEC that I've been running forever because it just worked and it was sufficient for my needs. Now however I'm trying to move to the latest LibreELEC (legacy PC edition) and I'm just not able to get NFS mounts to work following the instructions on this LibreELEC Wiki page:

Mount Network Share

I have noted that (in the case of NFS, at least) these are still the identical old instructions that I used on OpenELEC, years ago, to have the kernel mount my NFS volumes. So in theory this should all still work, but it ain't working. Here are the errors I'm getting:

Apr 27 03:42:03 LibreELEC systemd[1]: Mounting storage-y.mount...

Apr 27 03:42:03 LibreELEC mount[1420]: mount.nfs: rpc.statd is not running but is required for remote locking.

Apr 27 03:42:03 LibreELEC mount[1420]: mount.nfs: Either use '-o nolock' to keep locks local, or start statd.

Apr 27 03:42:03 LibreELEC mount[1420]: mount.nfs: an incorrect mount option was specified for /storage/y

Apr 27 03:42:03 LibreELEC systemd[1]: storage-y.mount: Mount process exited, code=exited, status=32/n/a

Apr 27 03:42:03 LibreELEC systemd[1]: storage-y.mount: Failed with result 'exit-code'.

Apr 27 03:42:03 LibreELEC systemd[1]: Failed to mount storage-y.mount.

(The above errors are in the systemd log, of course.)

I've tried all of the obvious solutions to fix this problem and nothing is working, so I'm asking for guidance. Specifically I've tried "systemctl start rpc-statd" but that only produced the error "Failed to start rpc-statd.service: Unit rpc-statd.service not found.". Of course I also tried adding "-o nolock" to the Options= line in my storage-y.mount file, and that still produced errors & failure when I did "systemctl start storage-y.mount".

I am at a loss and at an impasse. Any & all suggestions that might allow me to move forward would be appreciated.

P.S. Just for context I should mention that, back in the day I actually did go to the trouble of actually measuring the performance of (a) SMB shares (they really suck, performance-wise) and (b) the in-built Kodi NFS client (not bad, but not great), and (c) kernel mounted NFS shares. Kernel mounted NFS outperformed the Kodi in-built NFS client by a significant margin, which is why I most definitely want to stick with them and get them working on a current LibreELEC release.

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.