Posts by Reddog

  • AV1 capabilities in Raspberry Pi 4 - anyone on nightly LE 12 ?

    Quote from popcornmix

    With latest nightly, you can enable NUMA to get better performance. See numa thread.

    Make sure bootloader is updated to latest and set:

    SDRAM_BANKLOW=1 (for pi5)

    SDRAM_BANKLOW=3 (for pi4)

    using using rpi-eeprom-config.

    I'm always up for an increase in performance, especially when it's for free!

    Does this apply to the latest le12 nightly (LibreELEC-RPi5.aarch64-12.0-nightly-20241114-f000f3c.img.gz) or is it just the latest le13 nightly?

    Thanks.

  • Which Pi for PVR?

    Quote from ian_j

    I currently have a Pi 3b running Pi-hole and a Pi 4 running LibreELEC both working fine.

    I fancy having a play with a new device and feel like setting up a PVR.

    Do I get a Pi 5 and use that for PVR or move everything around?

    Plus which USB device(s) would be the best for UK Freeview? Multiple if needed so that I can record more than one program simultaneously.

    Why not go for a TV HAT rather than a usb one.

    I recently bought the Raspberry Pi TV HAT from Amazon just because it was so cheap at £6.99.

    I set up a tvheadend server on the RPi5 in the living room (where the best tv signal strength is) and installed the tvheadend client on a RPi4 in the bedroom and a RPi2 in the kitchen.

    All works great.

    Of course this would only give you the ability to record one channel at time - or buy 2 since that would still be cheaper than a usb twin tuner.

  • Updating LibreElec version on RPi4/5

    Quote from chewitt

    The most likely explanation is a difference in the performance of the SD cards. I'm using an NVME drive on the RPi5 and it's 25-30 seconds from typing "reboot" to looking at an updated Kodi home screen.

    I had assumed the usb sticks I am using to boot le were a similar speed going by the "headline" read/write speeds but now that I've done an actual speed test with "hdparm -t /dev/sda" it appears the usb stick in the RPi4 (Samsung Fit 32gb) is getting towards 2x faster than the one in the RPi5 (Sandisk Ultra Fit 64gb) - 195MB/sec vs. 115MB/sec. As a comparison, the 4tb NVME drive in the RPi5, which is used purely for storage, is 550MB/sec

    But would still have assumed the RPi5 should be much faster at decompressing the update file.

    Sorry for the time-wasting.

  • Updating LibreElec version on RPi4/5

    This question may be better asked on the Raspberry Pi forum but I'll try here first.

    I generally update my RPi4/2gb & RPi5/4gb every time a new le12 nightly comes out and a while ago observed there was a noticeable difference in the time taken for them to update.

    Finally got round to using a stopwatch to check (these are times from when the "Decompressing image file..." message first appears):

    RPi4: time to decompress = 27 secs; total time up to the "System reboots now..." message = 40 secs
    RPi5: time to decompress = 54 secs; total time up to the "System reboots now..." message = 78 secs

    So double the time for a much more powerful cpu - unless I'm missing something glaringly obvious. Double the ram shouldn’t make any difference should it?

    I'm not really bothered about waiting for it to update, more curious as to why a RPI5 is so much slower.

    p.s. le running on a usb 3.0 stick in both cases (similar read/write times).

  • Raspberry Pi 5: HDR not working

    Quote from chewitt

    If you can share the EDID files from AVR+TV and TV-direct I'll ask the Pi devs to have a closer look. The intermediate one (RPi + AVR only) is expected to not work since there's no TV to pass EDID from so it'll be incomplete.

    chewitt Sorry about the delay in replying.

    I thought I had saved the edid.bin files for each permutation but I can only find the equivalent .txt files that I stored after doing a edid-decode on each of the .bin files.

    Anyway, I have attached the 2 .txt files with the EDID TV-wo AVR.txt being the working one and EDID TV+AVR.txt non-working to see if this is of any help.

    EDID TV-wo AVR.txt  EDID TV+AVR.txt

    Quote from noggin

    Can you play HD Audio (i.e. Dolby True HD, DTS HD MA/HRA) with this set-up (I'm wondering if the TV-only EDID you are using doesn't have flags for the AVR-supported audio that the TV doesn't support ? Or it could be that with modern TVs they do flag support for this because eARC lets them pass it through?)

    noggin I have checked all my audio test files and the AVR shows correct output according to the test files (DD, DD TrueHD, DTS, DTSMA) so I believe the TV must flag all the audio options for passthrough.

  • Raspberry Pi 5: HDR not working

    BallerShotCaller: FYI, I had a similar problem playing some videos through my Onkyo TX-L50 4K AVR with a RPi5/le12.

    I was finding that HEVC videos at all resolutions with 24fps would only play audio (surprisingly 4K/60 HDR test videos played fine).

    Long, long story short, I first tried getedid create with the full train (RPi5 -> AVR -> Samsung 4K TV) without success.

    Next tried removing the TV so only RPi to AVR and did another getedid create. Put back TV but still no good.

    Finally tried a direct RPi5 to TV - this worked so did a getedid create, put back the AVR into the train and low and behold I now have all HEVC videos at all resolutions (including 4K with HDR) playing faultlessly.

    (off course when doing the getedid thing I rebooted, tried test, did getedid delete, reboot etc.)

    It would be interesting for someone in the know to compare the AVR+TV edid vs. AVR only edid vs. TV only edid (i.e. working edid) as I have the files available.

  • No HEVC video with latest le12 nightly on RPi5

    So sorry about this - in order to prove to myself that I wasn't being crazy I reloaded the 726b493 build. Turns out that I must be!

    All my HEVC files (they are all local by way of a new 4tb nvme drive - love the new Pi5 having this feature) now play flawlessly.

    Only thing I didn't try when it wasn't working yesterday was the old IT Crowd catch phrase "Have you tried turning it off and on again".

    Once again, sorry to have wasted your time.

    Quote from Wolfpig

    This might not help you, but if you have still trouble, on the current nightly (b5ce01c) the hevc files I have tried (some uhd hdr promo movies) run fine.... the hevc decoder which is used seems to be even using a hardware decoding. (at least the info says so).


    What I remember right now, on the pi4 I had the same with certain files, but I think that was more as the persons who made that used some uncommon formats like hevc 8bit or so which made problems with hw decoding.

    Dont think I have those files still here, otherwise I would check if those still would make trouble

    All working now - it was just a simple PBKAC.

  • No HEVC video with latest le12 nightly on RPi5

    Quote from popcornmix

    I'm not seeing a 1st April nightly here: https://test.libreelec.tv/12.0/RPi/RPi5/

    I do see 3rd April had an unwanted kodi bump that was bumped back on 4th April.

    Does 4th April nightly also have the issue?

    This is the 1st April nightly I'm referring to:

    LibreELEC-RPi5.aarch64-12.0-nightly-20240401-726b493.img.gz

    I'll try the latest (LibreELEC-RPi5.aarch64-12.0-nightly-20240405-b5ce01c.img.gz) when I have a bit more time.

    Thanks for responding.

  • No HEVC video with latest le12 nightly on RPi5

    Could be just me since I haven't seen any similar posts but something changed between the 31st March and the 1st April nightly - i.e. with 31st March le12 nightly I have video + audio but with 1st April nightly it is only audio (my Samsung tv reports mode/resolution not supported).

    From what I have observed it is only happening with HEVC videos (720p/1080p/2160p) - by turning off DRM Prime fixes the problem and the video is shown along with audio.

    As I said it could be something in my settings but I don't recall changing anything that would have this effect and simply reverting back to the previous nightly build fixes the issue then I believe that it may be more widespread.

  • Operation of new library "Version" feature

    Quote from Jocke.Sve

    Could You please post a link to where one can find more info about this.

    Couldn't find anything obvious about this on Kodi web of in their form.

    Thanks!

    Kodi wiki link:

    Video versions - Official Kodi Wiki

    I'm not sure which Kodi sub-forum covers this - please let me know if you find it!

    Quote from chewitt

    "Versions" is the gift that keeps on giving .. the initial merge looked simple but then the 101x unconsidered corner-cases where it had unexpected impact started to show and it's been a complete pain in the rear to fix things; most of the original code has now been reverted and reworked to avoid or better resolve problems. If you report stuff in Kodi forums please be mindful that the devs who read of more issues will be "delighted" to know there's more :)

    As mentioned above, I don't know which sub-forum covers this so I think I'll hold off and give it a few weeks for the coding to settle down. Just take a look at the videoversiontype table of MyVideos131.db where lines 24 to 387 are blank and then it shows "4K" and "3D" at the end - of course that might have been generated due to me specifically setting the versions as 4K & 3D.

    As a side issue, you wouldn't happen to know which table is used for the field="filename" rule when used in a .xsp file?

  • Operation of new library "Version" feature

    Quote from chewitt

    Versions is a new feature that's had a challenging introduction (lots of rework needed since initial merge) so the best place to ask for help with it is the Kodi forum; as that's where the developers who've done (and are still doing) that rework, hang out.

    Thanks, I'll do that.

    I guess I was potentially trying to emphasise the issue in order for it to be considered in that rework.

  • Operation of new library "Version" feature

    I'm not sure if this is a le, kodi or skin problem (i.e. a problem for me at least).

    My main library contains all films that are 4K, 3D, FHD or SD and I have set up the Version feature to contain 4K and 3D where there are 2 versions of the same film in those formats.

    I also have a Favourites list that filters 4K and 3D (amongst others) using .xsp files.

    4K.xsp:

    3D.xsp:

    XML
    <?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<smartplaylist type="movies">
    <name>3D</name>
    <match>all</match>
    <rule field="filename" operator="contains">
        <value>3D</value>
    </rule>
    <order direction="ascending">sorttitle</order>
</smartplaylist>

    The problem is that if I set the 4K film as the default in the Version setup then the 3D version of that film doesn't show up in the Favourites 3D list - but the 4K version does show in the 4K list.

    If I set the 3D film as the default then the 4K version doesn't show up in the Favourites 4K list - 3D version shows in the 3D list.

    I'm unsure if this is intended or is just a side effect of the way the Version system works and if there is a way round it.

    Anyone with an idea that could fix this?

    p.s. Using RPi5 with latest le12 nightly and Aeon Nox Silvo skin (version 9.99.3).

  • failure to mount Windows shares in Nexus nightlies

    Ok, I'm quite sure now that this is some sort of timing issue.

    I decided to play around with different options in the mount script since I noticed luguber had some differences to my mount | grep nfs output:

    Code
    /storage$ mount | grep nfs
192.168.1.200:/mnt/HD_a2 on /storage/NAS_1 type nfs (rw,relatime,vers=3,rsize=32768,wsize=32768,namlen=255,hard,nolock,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.1.200,mountvers=3,mountproto=tcp,local_lock=all,addr=192.168.1.200)
192.168.1.200:/mnt/HD_b2 on /storage/NAS_2 type nfs (rw,relatime,vers=3,rsize=32768,wsize=32768,namlen=255,hard,nolock,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.1.200,mountvers=3,mountproto=tcp,local_lock=all,addr=192.168.1.200)

    So I amended the options line in the NAS_1 script (thinking if that worked and the NAS_2 script didn't then that would prove the missing options):

    Code
    Options=vers=3,nolock,noacl,retry=2,timeo=900,noatime,proto=tcp,mountproto=udp

    And rebooted (after a systemctl daemon-reload command) - also removed my 4tb hdd attached to usb3 on the RPi5 so it wouldn't keep starting and stopping during the testing.

    It worked with both mount scripts so I had access to both drives in the NAS from le.

    I then did a shutdown to re-attach my hdd and restarted - both scripts failed this time.

    Tried another reboot and this time the NAS_2 script mounted but the NAS_1 didn't! But when I went into a ssh session and did a "systemctl start storage-NAS_1.mount" command, I could then access the NAS_1.

    So, if I want to keep up with le development I'm going to have to do multiple reboots in order to have both NAS drives mounted unless I find a solution around this timing issue.

    p.s. my rcpinfo output:

    Code
    /storage$ rpcinfo -p 192.168.1.200 |egrep "service|nfs"
   program vers proto   port  service
    100003    2   udp   2049  nfs
    100003    3   udp   2049  nfs
    100003    2   tcp   2049  nfs
    100003    3   tcp   2049  nfs

  • failure to mount Windows shares in Nexus nightlies

    Quote

    I also use nfsv3, I think it defaults to that still if you don't specify version.

    I can't get past the "protocol not supported" error without adding vers=3 in the options line.

    Quote from luguber

    For comparison, my config file looks like this:

    Try mount manually:

    Code
    mount -t nfs -o nolock 192.168.1.200:/mnt/HD_a2 /storage/NAS_1

    Can't get this to work either (I added vers=3 due to the protocol error).

    Quote

    And check logs to see if more details are mentioned there.

    Quote from luguber
    Code
    journalctl | grep nfs

    Now this is interesting?

    Output:

    Code
    /storage$ journalctl | grep nfs
Jan 21 19:13:14 LibreELEC kernel: nfs4filelayout_init: NFSv4 File Layout Driver Registering...
Jan 21 19:13:14 LibreELEC kernel: nfs4flexfilelayout_init: NFSv4 Flexfile Layout Driver Registering...
Jan 21 19:14:50 LibreELEC systemd[1]: storage-NAS_1.mount: Unit process 963 (mount.nfs) remains running after unit stopped.
Jan 21 19:14:50 LibreELEC systemd[1]: storage-NAS_2.mount: Unit process 967 (mount.nfs) remains running after unit stopped.

    Why does this state nfs4?

    Quote from luguber

    Also, the timeout error you get suggest network or serverside issue as well.

    My NAS is an ancient D_Link DNS-323 and has never been "fast" - when le starts up, the splash screen shows the le build and a message "waiting on Network to come online ...". This takes about 100 seconds before going into Kodi - showing an error before entering Kodi about mounting failing in the latest non-working builds.

    The challenge is going to be establishing what is different to the util-linux's mount operation and the original (working for me) Busybox's mount operation with regard to the timeout issue.

  • failure to mount Windows shares in Nexus nightlies

    Quote from HiassofT

    The journal message already gave you the correct hint: use Option=nolock in your systemd mount unit.

    so long,

    Hias

    Quote from luguber

    Reddog as HiassofT wrote above, you need to add the nolock option. It works then.

    HiassofT& luguber thanks for trying to help but it's still not working.

    I added the Options line but got an error about "Protocol not supported" so added my NAS nfs version.

    My Options line is now "Options=vers=3,mountvers=3,nolock" (not sure if one of the vers is redundant).

    Current error using 20th January le12 nightly on RPi5 is:

    Comparing this to a working version with le12 from 6th January:

    FYI my NAS exports file is:

    Code
    /mnt/HD_a2 192.168.1.0/24(rw,root_squash,sync,no_wdelay,insecure,no_subtree_check)

    I'm obviously missing something so any help would be greatly appreciated.

  • failure to mount Windows shares in Nexus nightlies

    Quote from agb

    Not sure I can be of any help, my problem was with cifs, yours is nfs.

    In my original post I showed the 'Options' I added to the unit file.

    luguber was having issues with nfs mounts, I suggest you ping him.

    Sorry, I should have read more carefully that yours was cifs.

    luguber in case you have tried the nightly from 18th January (using the #8509 fix) - did it work for you?

    I'm curious about these 2 lines in the error I get:

    Code
    Jan 18 20:56:18 LibreELEC mount[1396]: mount.nfs: rpc.statd is not running but is required for remote locking.
Jan 18 20:56:18 LibreELEC mount[1396]: mount.nfs: Either use '-o nolock' to keep locks local, or start statd.

  • failure to mount Windows shares in Nexus nightlies

    Quote from agb

    Fixed in

    https://test.libreelec.tv/12.0/RPi/RPi4/…-0af59b4.img.gz

    Thanks HiassofT et al.

    How do I mark this threadas [SOLVED}?

    Glad it's fixed for you but no luck for me.

    Running from ssh, I'm getting the following errors using 18th January nightly for RPi5:

    This is with systemd mount script:

    Did you have to make any changes to your script or exports file to get it to work?