Posts by chewitt

  • Question about Flirc USB Receiver

    See: https://github.com/xbmc/xbmc/pull/26368

    The PR is (was, it's merged) more about a bit of soft-promotion of flirc because Team Kodi receives royalties on Kodi flirc case sales than anything else, although the add-on might evolve in the future to support programming of the flirc USB device; it's technically possible to do that if the "flirc_util" add-on has also been installed.

    It's probably something we'll add to the default image so the flirc receiver shows-up (is recognised) by default.

  • Help with SMB share please

    There is no default SMB share for /storage but there are shares for e.g. 'Videos' which map to /storage/videos so if you drop files into that share they should show up in that location?

    Samba will also auto-share "removable" drives that are mounted to /var/media so even though it's not a removable device it sounds like the second NVME drive is being auto-mounted to that location. Samba will create a share based on the disk label of the mounted device so if you labelled it as 'MyDrive' it will create an SMB share using that name that maps to the underlying /var/media/MyDrive location.

    If you want to edit the default SMB shares: https://wiki.libreelec.tv/configuration/samba

    It doesn't really sound like you've done anything wrong and using a Mac as the client device accessing shares isn't unusual.

    If you SSH into the HTPC using Terminal.app on macOS, run this command and share the URL that's generated by 'paste'

    Code
    ls -alh /storage/videos /storage/tvshows /var/media/MyDrive | paste

    (edit /var/media/MyDrive to match whatever you called it).

  • Pine A64 WiFi/BT Module Support

    If this is the correct device-tree?

    linux/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts at master · torvalds/linux
    Linux kernel source tree. Contribute to torvalds/linux development by creating an account on GitHub.
    github.com

    I don't see anything about WiFi/BT inside the dts file and I don't see any patches in our buildsystem for support. If you know what content is required to enable the module and you have some basic technical skills it's not hard to self-build an image with an extra patch to add support.

  • [Odroid-C2] CEC / AnyNet+ & ARC Issue

    If you install from my image and then downgrade to 12.0 you are no longer running my image. The 12.0 nightly might not boot. It's hard to comment further because we're both talking hypotheticals. I haven't booted a C2 for some time and have no plans to dig a board out for a couple of weeks due to travels. So just experiment and see what happens.

    NB: Even if you prove something is broken in the LE12 image and resolved in the newer one we aren't going to backport Linux 6.14.y or libCEC 7.0 to "fix" the LE12 branch so the information is entirely academic.

    If things don't work, you have my LE13 image to use. K22 will start moving towards release soon.

  • [Odroid-C2] CEC / AnyNet+ & ARC Issue

    You can drop the .tar files in /storage/.update but Kodi does not support downgrades so after downloading the .tar file to the board you need to manually stop Kodi and rename /storage/.kodi to /storage/.kodi22 before rebooting to start the update. On restart after the update this will give you a clean K21 instance to (re)configure.

    Note that I don't keep archives of my older K21 images and I bumped to K22 more than a year ago, so the only K21 images around are the official releases which allegedly have a boot bug on C2 boards. It will start u-boot then fail to boot into the kernel, but this only visisble with a UART cable connected.

    Also note that earlier K22 images in my share solved the boot bug with a workaround in u-boot, and the latest images solve it with a kernel fix submitted upstream (that should do the same thing). I'm not sure if the board will boot with u-boot from the latest image and kernel from the older one. You'll have to try it and see.

  • DVB-S2 PCIe Twin Tuner

    Quote from sundtek

    PCI-Express devices are in progress, we don't have them on the market yet but they will be available within the next 2 months I would say (according to the current status). Contracts with chip suppliers are signed, samples are in our office. The PCI-Express datatransfer already works, we are working on the frontend (receiver part at the moment).

    There is a definite need for 'supported' products in this space so this is nice to hear :thumbup:

  • Netflix, Aussie Addons, Oz Weather, Embuary Info, Cu LRC Lyrics - Python exceptions

    Quote from dartheejit

    Log is attached. positive-deer.log.txt.zip

    Why!??? .. all you had to do was share the URL the paste function generated (https://paste.libreelec.tv/positive-deer.log) which shows the filesystem on the USB drive was force-checked:

    but even with fsck there's loads of this:

    Code
    Apr 06 07:30:55.157302 LibreELEC kernel: sd 4:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=0s
Apr 06 07:30:55.157923 LibreELEC kernel: sd 4:0:0:0: [sda] tag#0 Sense Key : 0x3 [current] 
Apr 06 07:30:55.158357 LibreELEC kernel: sd 4:0:0:0: [sda] tag#0 ASC=0x11 ASCQ=0x0 
Apr 06 07:30:55.158758 LibreELEC kernel: sd 4:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 02 11 42 88 00 00 08 00
Apr 06 07:30:55.159165 LibreELEC kernel: critical medium error, dev sda, sector 34685576 op 0x0:(READ) flags 0x3000 phys_seg 1 prio class 2
Apr 06 07:30:55.159217 LibreELEC kernel: EXT4-fs error (device sda2): __ext4_find_entry:1683: inode #1051944: comm mount-swap: reading directory lblock 0

    And then:

    Code
    Apr 06 07:31:07.955704 kodiLounge kernel: EXT4-fs error (device sda2): __ext4_find_entry:1683: inode #1052028: comm kodi.bin: reading directory lblock 0
Apr 06 07:31:08.000646 kodiLounge kernel: EXT4-fs error (device sda2): __ext4_find_entry:1694: inode #1052028: comm kodi.bin: checksumming directory block 0
Apr 06 07:31:10.457599 kodiLounge kernel: EXT4-fs error (device sda2): htree_dirblock_to_tree:1083: inode #1052028: comm kodi.bin: Directory block failed checksum
Apr 06 07:31:13.098569 kodiLounge kernel: EXT4-fs error (device sda2): __ext4_find_entry:1694: inode #1052028: comm kodi.bin: checksumming directory block 0
Apr 06 07:31:13.191377 kodiLounge kernel: EXT4-fs error (device sda2): __ext4_find_entry:1694: inode #1052028: comm kodi.bin: checksumming directory block 0
Apr 06 07:31:13.260223 kodiLounge kernel: EXT4-fs error (device sda2): __ext4_find_entry:1694: inode #1052028: comm kodi.bin: checksumming directory block 0
Apr 06 07:31:13.308411 kodiLounge kernel: EXT4-fs error (device sda2): htree_dirblock_to_tree:1083: inode #1052028: comm kodi.bin: Directory block failed checksum
Apr 06 07:31:13.355379 kodiLounge kernel: EXT4-fs error (device sda2): __ext4_find_entry:1694: inode #1052028: comm kodi.bin: checksumming directory block 0

    So the USB drive is bad (critical medium error) and this impacts data read from /dev/sda2 which is mounted as /storage. I think it is unlikely that the power outage caused the issue. It's more likely the drive went bad all on its own, but the outage results in unclean shutdown of the filesystem so the filesystem is in a 'dirty' state causing fsck to be run on boot, and this then finds or runs into the underlying media problem. On a memory device medium errors are failed cells in the flash memory chip that's inside.

    I wouldn't waste time attempting to repair the USB drive as once cells start to fail the only outcome is more cells failing. If it's still possible (not guaranteed) you can backup the essential Kodi userdata like sources.xml, passwords.xml, DB files, and add-on settings files somewhere. Then make a clean install on a replacement USB drive, stop Kodi, and copy the userdata bits back.

  • [x86-64] Switching Display Modes does not work for Zoom

    From what I can see with View Mode and Zoom:

    Starting from "Normal" mode if you enable "Zoom" mode it starts with "Zoom amount = 1.0" and when you make any change to the amount value the selected mode automatically changes to "Custom" mode. I've zoomed a 4:3/SD letterbox video so the sides are closer to the edge of my 16:9 screen resulting in "Zoom amount = 1.15" and if you toggle between "Normal" and "Custom" modes the zoom value is persistently applied.

    However, if I now switch back to "Zoom" the display switches to a mode similar to "Wide zoom" and not the current "Custom" value that I defined. This probably makes sense in the context of not wanting to automatically revert to "Zoom amount = 1.0" when going back to "Zoom" as this would presumably change the "Custom" value automatically too. However, if I now move to change "Zoom amount" the wide zoom mode is shown until the amount value is adjusted; only then the screen switches to the "Custom" amount value. I also note that if I adjust "Zoom amount" back to 1.0 the mode auto-switches back to "Normal" mode again.

    This is probably old code and "not a bug" since "code is working as designed" but the design could use improvement. Unless there is some use-case I'm not understanding I think it would be more logical to simply have "Zoom" respect the current "Zoom amount" value defined and eliminate "Custom" mode.

    As this is nothing specific to LibreELEC I'd suggest you report this to Kodi developers via their forum or GitHub issues.