HW limitations: RPi will never play HEVC/H.265
Just to say this isn't true, as the RPi2/3 does support H.265.
The RPi2 can play H.265 720p content without any issue, and with moderate overclocking can also playback H.265 1080p content (up to a bitrate of about 10Mbps). This actually makes a lot of H.265 1080 content quite playable on the RPi2. With the RPi3, it's usually not necessary to apply any type of overclock to achieve good H.265 1080p playback.
Obviously 4K playback isn't possible.
No, to be honest I don't see any errors/issues in either dmesg so I can't explain why the fsresize is failing when using the sdhost driver. I wonder if a dmesg from a freshly imaged SD card would reveal the issue, but this would require you to re-image your SD card, allow fsresize to fail, then grab the dmesg - I'd expect there to be some mmc-related errors logged.
If you're using one of my test builds you should be posting in the Kodi forum thread which documents these builds, as that's where they're supported. If you want help from the LibreELEC forum then use an official build.
Thanks for the information. So i'll keep the patches.
I don't know if it's a useful information, but your build 0617x with the lirc bump did not affect the kernel 4.6.2 broken remote repeats. Just tested without knowing, if it's really technically related... So. As said, just fyi - if even valid
Thanks for the confirmation, but #0617x wasn't expected to fix that.
While getting a little more into compiling stuff, i mainly wonder why the few FernetMenta VideoPlayer patches (which are included in your "Millhouse build")
Comparing xbmc:9248a82331e5311...FernetMenta:585587fc07bba2a · xbmc/xbmc · GitHub
are still not included in KODI git master. Is there a reason for that? I mean: Regular way seems to be: test, PR, merge with git master?
The first of those commits, "python: use kodi provided cert if available" is submitted as a PR, python: use kodi provided cert if available by FernetMenta · Pull Request #9424 · xbmc/xbmc · GitHub - once it merges it will disappear from the FernetMenta branch. The remaining commits may or may not become pull requests, but as Fernet is the main developer for VideoPlayer I'm happy to trust he knows what he's doing and that he has plans for those commits.
I've always used:
Is that dmesg with the dtoverlay=mmc or without? It would be good if you could upload the dmesg after booting without dtoverlay=mmc, ie. while using the default sdhost driver.
The resize is normally very quick - for an 8GB SD it's only a few seconds, I haven't timed it but I'd say it's less than 10 seconds. I wouldn't expect it to take much longer with a 16GB SD so if it's taking "quite a long time" (can you time it?) then perhaps it's experiencing errors and failing to do anything at all...
One thing to try would be writing the image to SD card, adding "dtoverlay=mmc" to config.txt, and then booting the new image to see if the resize succeeds while using this older mmc driver.
Also, can you run "dmesg | paste" after you've booted into LE, and paste the link.
HoangLee: why are you trying to copy the font file into the read-only filesystem when you've been told to copy it into /storage/.kodi/media/Fonts ?
Yes, I could mount the second partition - use "sudo apt-get install kpartx" on Ubuntu to install kpartx:Code
- [email protected]:~/projects/extract$ ls -la
- total 2244644
- drwxrwxr-x 3 neil neil 4096 Jun 13 23:29 .
- drwxrwxr-x 39 neil neil 12288 Jun 14 22:02 ..
- -rw-r--r-- 1 neil neil 574619648 Jun 8 20:47 LibreELEC-RPi2.arm-7.0.1.img
- -rw-rw-r-- 1 neil neil 574619648 Jun 9 13:21 LibreELEC-RPi.arm-7.0.1.img
- -rw-r--r-- 1 neil neil 574619648 Jun 13 23:31 LibreELEC-WeTek_Core.arm-8.0-devel-20160612143724-r23223-gec2a5d2.img
- [email protected]:~/projects/extract$ mkdir storage
- [email protected]:~/projects/extract$ sudo kpartx -av LibreELEC-WeTek_Core.arm-8.0-devel-20160612143724-r23223-gec2a5d2.img
- add map loop0p1 (252:0): 0 1048577 linear 7:0 2048
- add map loop0p2 (252:1): 0 65537 linear 7:0 1052672
- [email protected]:~/projects/extract$ sudo fsck -n /dev/mapper/loop0p2
- fsck from util-linux 2.27.1
- e2fsck 1.42.13 (17-May-2015)
- /dev/mapper/loop0p2: clean, 12/8192 files, 5530/32768 blocks
- [email protected]:~/projects/extract$ sudo mount /dev/mapper/loop0p2 storage
- [email protected]:~/projects/extract$ ls -la storage
- total 17
- drwxr-xr-x 3 root root 1024 Jun 12 12:40 .
- drwxrwxr-x 4 neil neil 4096 Jun 14 22:03 ..
- drwx------ 2 root root 12288 Jun 12 12:40 lost+found
- -rw-r--r-- 1 root root 0 Jun 12 12:40 .please_resize_me
- [email protected]:~/projects/extract$ sudo umount storage
- [email protected]:~/projects/extract$ sudo kpartx -d LibreELEC-WeTek_Core.arm-8.0-devel-20160612143724-r23223-gec2a5d2.img
- loop deleted : /dev/loop0
- [email protected]:~/projects/extract$
i don't have another SD this is a new SD and like i said when build x works and y, z doesn't i still think it might be the build not the SD otherwise it doesn't make any sense.
Yes, that is strange, but I can't think of anything obvious that has changed that would cause this.
I can write this to the device nand but won't that brick it if it's bad?
Not familiar with the Wetek system so can't advise here.
So I am starting to suspect LE has some issue with 16GB SD cards (or Kingston in particular) since Raspbian has no issues at all with it. Unfortunately I do not have any smaller sized SD cards to test with. Just 16GB's.
Just to be clear, you have the same problem with OE? This question isn't about scoring points, it's just that the image creation/first boot process has diverged somewhat between OE and LE and if you have this same failure-to-resize problem with OE then it's unlikely to be caused by any LE changes...still not sure what could be causing this (all my available SD cards top out at 8GB).
How are you powering the RPi2? Can you try a different power supply?
P.S. I also tried it with OpenELEC (I know, I know) but that has the same issue with add-ons (storage wise is is the same as with the LibeElec Jarvis situation shown above).
So you say you've got a 16GB SD card, but neither OE or LE will expand the ext4 partition? Have you ever managed to install any release on to this SD card which has then gone on to use all the available 15-16GB of space?
Since OE is also failing to resize the partition my suspicion would be that the SD card has failed, or the SD card is a fake and isn't really 16GB - see this article and consider testing the SD card with a tool such as h2testw on Windows.
Not sure if the problem is caused by the storage being almost full or something else though.
That's definitely the reason why you can't install any add-on, the question though is why you don't have the space... after a fresh install from disk image LE (and OE) will automatically resize the ext4 partition to use ALL available space which should in your case be slightly over 15GB. This is a relatively straight forward process and if this isn't working then there's possibly something wrong with the SD card...
It seems with the Kodi 17 LibreELEC inputstream doesn't work for some reason (RPi2)? I installed it via: curl -Ls getwidevine.sh | bash
It did say sucessfully installed ....
getwidevine.sh isn't installing the inputstream.mpd add-on, it's only installing the libwidevine library which is needed by the inputstream.mpd add-on to decrypt encrypted content.
With official LibreELEC Kodi 17 releases (alpha, beta, whatever) you'll need to install the inputstream.mpd add-on from the LibreELEC Add-ons repository.
I've downloaded your img.gz and fsck'd both the FAT and ext4 partitions and they're both clean so there's nothing wrong with the image itself. Unfortunately I don't have Wetek hardware so can't write the image to an actual device, but the problem doesn't appear to be in the image creation process (we did have a problem with this, when creating the FAT partition, fixed on master on 9 June - see mtools: Fix creation of dot directories (. and ..) by MilhouseVH · Pull Request #435 · LibreELEC/LibreELEC.tv · GitHub).
Can you try a different SD card?
I just passed to LibreELEC and everythings seems to work fine except the remote control via Official Kodi remote per iOS.
I did check that under SYSTEM->SETTINGS->SERVICES->WEB SERVER
The flag is ON for ALLOW REMOTE CONTROL via HTTP.
I also checked that under SYSTEM->SETTINGS->SERVICES->REMOTE CONTROL all options are ON
The default web server port has changed to 8080 in recent Kodi builds, so make sure Kore is trying to connect on the same port that your LE client is using.
Can you upload the img.gz with the faulty partition, and paste the link?