Posts by milhouse

    Glad you got it sorted. I once worked at a firm that deployed 200 Compaq PCs which then experienced strange and intermittent network problems. Eventually we discovered that Compaq had programmed all 200 network interface adapters with the same identical MAC. Fortunately we were able to reprogram them all but that was a PITA... Maybe the same clown that programmed those network adapters is now working at WD! :)

    The problem is that the file system label, "Elements", is the same on both drives so they're both being mounted from the same mount point, /media/Elements. Consequently only the first disk is mounted correctly. The second disk fails to mount correctly because the mount point is already in use.


    Solution is to change the file system label on one of the drives. Connect it to a Windows machine and change the label, ie. "Movies". Then both drives should mount correctly, one from /media/Movies and the other from /media/Elements.

    Can you boot your Pi with no drives connected, then plug in your movies drive (which presumably will be mounted) to the hub, wait 30 seconds, then (still with your movies drive connected) plug in your TV shows drive to the hub.


    Wait another 30 seconds then run the following command, and paste the links:

    Code
    1. dmesg | pastebinit
    2. journalctl | pastebinit


    Thanks.

    I would suggest trying the latest LibreELEC x86 test build from this thread: LibreELEC Testbuilds for x86_64 (Kodi 17.0) - these builds are more bleeding edge than 7.90.003.


    Once you have confirmed you still have a problem with VC1 material, post a full debug log after playing one of your VC1 movies - enable debug logging, reboot, play your movie, then "cat /storage/.kodi/temp/kodi.log | pastebinit" and paste the link in the test builds thread with a detailed explanation of the problem. One of the Kodi VideoPlayer developers will hopefully then be able to suggest a solution, which will be to post a bug on freedesktops.org, wait for AMD to fix their driver, or if you're lucky there will be a bug fix in VideoPlayer.

    Not a problem as such, but we may experience users asking for or expecting features in non-imx6 platforms - as we have seen this week - because a feature already exists in imx6 but not elsewhere. Normally all our platforms strive for parity in terms of features, but having one platform with kitchen sink features can be confusing for users who then demand the same elsewhere. It's just a question of how we handle this.


    The clue is in the im6/xbian name .. the origins of that Kernel are not OE/LE so there will be a few differences.


    Yeah, it's not the first "difference" this week. I can see this being a potential long-term issue (or at least, topic of discussion) unless the imx6/xbian options are harmonized with all other platforms.



    It's trivial to add the module, but does the device also require firmware?


    I've no idea about firmware, it's one of those DVB do-hickies. :)

    MN88743 seems to be enabled as a module only for imx6/4.4-xbian. All platforms have module support for MN88742. Not sure why 88743 is only enabled for the imx6 platform, it's possibly something that could be added to all other platforms if there is a requirement for it (is the 88743 a replacement for the 88742?)

    You can install your own Kodi splash by copying a png file into /storage/.kodi/media/Splash.png. This would allow you to use the same artwork for both LE and Kodi splash files.


    However with an upcoming change (kodi: database migration splash text by MilhouseVH · Pull Request #537 · LibreELEC/LibreELEC.tv · GitHub) your current custom splash may not be ideal, as the space below the central logo would be best kept clear (you have the LE logo). You'll only have an issue during a database migration, which will be a one-time issue (per major release), and may be something you can easily live with.

    You can just delete those directories as the fs_resize process will delete and recreate the storage partition, so you will lose every item of data currently stored.


    If the fs_resize process is failing, there are four possibilities (in no particular order):
    1) Insufficient power supply
    2) SD card has failed (they have a limited number of writes, and will fail eventually)
    3) Fake SD card and it's not really 32GB capacity (test with various software tools designed to detect fake SD card)
    4) SD card is not compatible with default sdhost driver, try adding "dtoverlay=mmc" in config.txt before first boot

    Yes, we identified the 4.6.x kernel commit that causes the auto-repeat failure. Reverting this commit fixes the auto-repeat issue but causes other more serious lirc issues so not really sure what the solution is right now. Assuming the kernel commit is in fact correct, perhaps the lirc system requires a tweak to accommodate the kernel change - reverting the kernel commit probably isn't a long term solution, and it already requires a rework for the 4.7 kernel.

    Nope, no new driver nor any other change in #0629 that would explain the new behaviour you describe.


    Upload "dmesg | paste", "journal -a | paste" and "/var/log/Xorg.0.log | paste" from #0629 in the Kodi forum thread along with a full description of the issue, as this is where the Milhouse builds are supported (and also fully documented so that you can see what is new and changed in each build).


    The Milhouse builds are not supported on the LE forum, so if you want help with a Milhouse build post on the Kodi forum.

    OpenELEC currently has (or had, as of 2 months ago, not sure of the exact current figure) half a million active users.


    You have absolutely no idea of the size of each distributions userbase. Presuming that the userbase size for a distribution is "small" based on your personal skin usage figures is pretty misguided, not to mention woefully inaccurate - it's more likely to indicate that your skin simply isn't very popular with those distributions.