Posts by milhouse


    - does not allow to select specific folder (like: http://xx.xx.xx.xx/video/movies), I have no enter it manually after ip address.

    This depends on the server to some extent - some NFS servers will allow folders to be browsed (eg. ReadyNAS) others don't (eg. FreeNAS 8). Just enter the full path.


    - despite new address (xx.xx.xx.193) it remembers the old one (...65) and write "server is not available", and I can't change it. Looks like old path was saved in some config file, and it is not changed with my update.

    If you've added a source to your library (ie. x.x.x.65), and set the content of the source (movies, music etc.) and tried to scrape content for the source, then it may have left remnants of the server path in the media library database (MyVideos/MyMusic). The way to remove a source is 1) set the content to None (which removes all entries from the database and then 2) delete/remove the source. If you didn't set the content to None (ie. you omit step #1) then this might explain why Kodi is still trying to access the server as the paths for the server are still in your database(s). I believe the solution is to re-add the old source, exactly as you added it originally, set the content to whatever you originally set it to, and then set the content to "None" (which should remove any database entries) before finally deleting the source again.

    The following post on the Kodi forum gives details of how to run my build scripts:

    Python not building

    My scripts might work for you as per the instructions in the thread, or you might need to tweak some of the dependencies depending on your OS. If you're already building LibreELEC using the standard build instructions ("PROJECT=imx6 ARCH=arm make release" etc.) then you shouldn't have too many issues - just make sure you install the dependencies required by my scripts (pv pxz pigz pastebinit patchutils).

    Once you're setup (don't skip any steps in the post!) you can try "PROFILE=imx6 ./autobuild.sh" although I don't build the IMX6 project myself so have no idea if it will build successfully from LibreELEC master (in theory, it should). If you want to build from the libreelec-8.0 branch (with Kodi 17 final) then use "PROFILE=imx6-stable ./autobuild.sh"

    Note that with my scripts when building with "PROFILE=imx6" you're basically building multiple moving targets - you're building latest LE master, latest Kodi master, and the latest masters for over a dozen different addons and libraries (libnfs/libcec), all of which are being updated daily (sometimes several times a day) with changes that can break your build. I update (at least once a day) oebuild.tar.gz with the latest commits and configuration changes to achieve a successful build but of course I'm only building for RPi/RPi2/Generic so you may need to resolve any IMX6-specific breakages yourself.

    With "PROFILE=imx6-stable" you're building the LibreELEC/Kodi/addon/libnfs/libcec/etc. versions that are configured in LibreELEC branch libreelec-8.0, which should result in a more stable/predictable/reliable build environment.

    Sorry, the switch to the 340.xx driver had been requested by users who considered it to offer improved picture quality over the 304.xx driver. Unfortunately after switching to 340.xx this has inevitably meant some older GPUs such as yours, which launched 11 years ago now in Feb 2006, are no longer supported (and it's simply not feasible to support this increasingly small number of users by adding a third nvidia driver, as it would burden every x86_64 user with a much larger download for very little benefit).

    If you can find a cheap drop-in modern alternative, that would be your best option (nvidia or amd) and then disable your on-board GeForce 7025 GPU.

    Alternatively, you might be able to find someone willing to build LibreELEC 8.0 with the 304.xx driver in place of 340.xx (or try building it yourself) - I know someone asked for just that within the last couple of months (either here or on the Kodi forum). Found it, here you go. Maybe Goga777 would be willing to share if he has an up to date build.

    Sounds odd. Double check you're writing the RPi2 file. Also check the LED pattern when booting the RPi2 - the number of flashes of the green LED gives a cute to what is failing/missing. Also check the contents of the FAT partition in a PC - make sure all the files are there and there's no corruption.


    I mean RPi2/RPi3 images should use LABEL= or UUID= to refer to partitions,
    to be able to copy image to uSD or to USB without changing cmdline.txt
    Maybe the script to resize should be also updated if physical device name is used.

    Absolutely not.

    Imagine you're booting with boot=LABEL=System and you boot while a removable drive with the same label is connected - chances are your system will fall to boot and cause a support headache. Or you boot with disk=LABEL=Storage while another "Storage" removable drive is connected, possibly used instead of your normal "Storage" drive, and potentially even resized by fs-resize.

    The UUID may well be different on your USB partition so won't work any better than device id - you'll still need to edit cmdline.txt

    Anyone switching to USB booting on the RPi can be expected to have the technical ability to edit cmdline.txt.

    fs-resize should resize a USB partition if it contains a file called "/.please_resize_me" and doesn't already contain .config, .cache and .kodi directories. If you wrote an .img directly to your USB disk then (after editing cmdline.txt) LibreELEC should boot and resize your Storage partition.


    OT: Why I see only lost+found mounting /dev/sda2 from a linux system before resizing ?

    What are you expecting to see? If it's a freshly formatted file system then lost+found is all you'll see - the .config, .cache, .kodi etc. directories will be created when LibreELEC boots.

    If you wrote a LibreELEC .img file to your USB drive then you should also have the ".please_resize_me" file in the root of the second partition.


    The options are default: automatic boot, tab gives the 'option' of 'installer live' . Maybe this is run from memory? Who knows. After that you get a choice of Quick Install, Repair/Upgrade or Logfile.
    And (apparently) since version 7, there is no option to install the 32bit version.

    When booting from the USB stick you have three options: installer (the initial default), live (uses RAM for storage, ie. non-persistent) and run (uses USB stick for storage, ie. persistent). Both "live" and "run" will not write to your internal drives although they might be mounted which is useful for accessing media (or even recovering a system).

    The USB stick will remember the last option used to boot the USB stick, making that option the new default, and the options you see listed when prompted for the boot option won't include the current default.

    Since you only see "installer" and "live" this suggests you've already tried "run" which is now your default. Alternatively your USB stick is based on an old 7.0.x version of LibreELEC which doesn't include the "run" option.

    LibreELEC has never supported 32-bit x86.

    fabio70mi: Have you enabled USB boot mode by adding "program_usb_boot_mode=1" to config.txt, and after booting checked that the OTP (one-time programmable) bit is set correctly?

    Documentation is here: How to boot from a USB Mass Storage Device on a Raspberry Pi 3 - Raspberry Pi Documentation
    [hr]


    Hi,
    I'm trying the same just now with 7.95.2
    I updated root=/dev/sda2 in cmdline.txt but I think it's not enough, maybe I've to change /etc/fstab.
    (From Raspbian, /dev/sda2 contains only lost+found, strange, I will try again to create SD using win32diskimager in place of Rufus).

    There is no root= for LibreELEC - it is boot=. There is also no /etc/fstab.

    It sounds like /dev/sda2 should be your Storage partition, or disk=. Presumably /dev/sda1 would then be your System (boot=) partition.


    Also could be nice to boot LibreElec from PXE, maybe it's only more complicated the autoupdate being the firmware files loaded via tftp

    Thank you

    LibreELEC for RPi boots fine over TFTP. Some details of this process are in the PR I added several months ago: init: mount per-client boot/disk if available & configured by MilhouseVH · Pull Request #621 · LibreELEC/LibreELEC.tv · GitHub

    Also refer to the Raspberry Pi documentation (you'll need to adapt the Raspbian-specific instructions to LibreELEC).
    [hr]


    @Irusak: wondering if it would be helpful to add the other parameters that raspbian has like:
    dwtc_otg.lpm_enable=0 console=serial0,115200 console-tty1 elevator=deadline fsck.repair=yes rootwait

    Any idea?

    The LibreELEC kernel will add all required kernel options - look at /proc/cmdline of a booted system to see all the kernel options. LibreELEC is not Raspbian, and should not be treated as such. You're most likely to break something when adding Raspbian kernel options to LibreELEC.


    I agree with fabio70mi that using a label rather than an address would be nicer. Don't know how that should be phrased in cmdline.txt (or elsewhere).
    As far as fstab is concerned: I cannot find it on the USB stick from my Linix Mint box!

    You can use labels and uuids in addition to device ids when referring to partitions, eg disk=LABEL=Storage, or disk=UUID=aaaa-bbbb-cccc-dddd

    HiassofT has informed me that 7.95.2 (which is due to be released real soon) is working fine on RPi3 with GPIO, so please test again with 7.95.2 (or build latest libreelec-8.0 branch)

    Edit: Oh hang on, 83ef1f2ea906ed3820edc7f366e110658c64a82f - that's a fairly recent build from libreelec-8.0. If 7.95.2 is still an issue then please can you identify from the test builds I gave when this problem started.

    I'm a bit confused about what is working and not working after you revert that commit.

    The following three test builds include the recent LIRC changes:

    1. #1228: LibreELEC Testbuilds for RaspberryPi (Kodi 18.0) (bump to 0.9.4c)
    2. #0111: LibreELEC Testbuilds for RaspberryPi (Kodi 18.0) (lirc: check for socket in lircd-uinput.service)
    3. #0114: LibreELEC Testbuilds for RaspberryPi (Kodi 18.0) (lirc: fix [email protected])

    Can you test these builds to try and determine when this problem is introduced? I'm assuming your remote is working perfectly in #1227.

    HiassofT tested a GPIO receiver on RPi3 and didn't have any problems with the 0.9.4c change PR1101 that first appeared in build #1228, so are you sure this is the PR that introduces the problem?

    Yes sorry - it's down for planned maintenance adding additional storage, unfortunately this is taking a little longer than the expected ~1 hour. Hopefully it will be back soon!
    [hr]
    Server is now back online.

    Thanks, looks to be a packaging cock up by lirc - the version of the 0.9.4c package now includes several post-0.9.4c commits which break the build. Obviously, these extra commits should not have been added to the 0.9.4c package.

    I've added PR1252 which will download the 0.9.4c package from a different url. This new URL is serving the original 0.9.4c package without the extra commits.

    Either manually change the URL in your local repo and restart the build, or wait until PR1252 is merged.