Posts by chewitt

    We have to go through some process to "unlist" ourselves or we wait until they just happen re-scan our corner of the interwebs and decide we're safe again. It's a thinly veiled scheme which herds you towards paying for a Norton Safe WebSeal thingy to promote you're scanned and clean. I'm personally okay with Norton users being inconvenienced by this. We are not going to waste funding on a webseal, and people might Google and find this thread where I post my ex-Symantec-employee comment about their ability to detect anything useful these days as "pretty low" and Norton junkware not being worth the exorbitant annual fee that's charged. Not that they are particularly unique in this; most AV suite tools are equally naff.

    We do publish checksum data (append ?mirrorlist to any download file URL or click the 'info' links on download pages) but that data comes from the same server as the files so fails the "could be tampered with test" and files are not served over https as we use mirrorbrain to geo-distribute downloads and avoid massive bandwidth/hosting charges - the mirrors you get files from are all http-only and outside our control. Signing is in the to-do list but I apologise and confess that rightly or wrongly it's not currently a high priority item in the list. We have quite a few other hosting/back-office things that need attention first but we'll get there eventually..

    Thanks for sharing the concern but it is a false positive. We use a packing tool to reduce .exe file sizes and because it is very efficient the same tool is also used by lots of bad people who write virus and trojan code. The packer leaves telltale signs in the exe and this sometimes triggers warnings in AV tools that aren't particularly clever (none of them are these days).

    I'm using the default power on/off button of a random IR6/MCE remote purchased off eBay. It works because the sensor integration is done properly on the Ultra2 board that I have (both vpeter and I have the same board). That said, I never really use suspend because it does full power on/off from the remote and the box boots in 10 seconds. Suspend has no real speed advantage so why bother with the extra complications it adds.

    I've posted the link to our internal dev team channel for add-ons but I'm not sure you'll get willing volunteers there. Normally the people that might care about SNMP support on a Kodi media box are also the type to roll up their sleeves and use their Linux skills to update things for LE (as that git repo hasn't been touched for a couple of years and things probably need revising). If someone does the work and would like to sustain the add-on in the long-term it can be PR'd to our git repo.

    OpenVPN does not need to be installed in LE (only in OE v6.0) and we do not provide any GUI add-ons for configuring VPN things. Thus the correct place to ask for support is the forum support thread for whatever {unknown} VPN configuration add-on you're using?

    Clock slew has no impact on startup other than the clock being slightly wrong. The journal on a Raspberry Pi (with no RTC) will show you a system that starts happily on 1st Jan 1970 until the network comes up and NTP drags the clock forwards 36 years.

    The first delay of 15 seconds occurs because /dev/random is locked due to a lack of entropy. This usually stems from using simple HTPC hardware with no external peripherals or mechanical media which are the OS's main sources of entropy. LE7.0+ does some workarounds for storing and then recovering entropy on next boot that normally reduce the delay, but there's not much to do about that.

    The second much larger delay looks to be related to /dev/sdb. I'd make an educated guess that this is a larger capacity (and/or slow speed) USB stick and the OS + hardware shutdown process is leaving the stick into an unclean state which triggers fsck on restart; the scan takes time to complete so you see a boot delay and because you already fsck'd the partitions a manual check after boot shows nothing as the issues caused were already resolved.

    Install to a proper HDD/SSD and the longer delay issue probably goes away.

    LE8.0 builds use the 340.xx nvidia driver whereas LE7.0 will be using the older 304.xx driver for that card - we see occasional reports of cards that work "better" (in non-specific terms) with the older driver. If you have some Linux skills or confidence it's possible to self-build LE8.0 with the older driver and test things. If the older driver works better it's not really a bug in LE, it's just that some older nvidia cards are quirky.

    S3 mode works fine when the BIOS/hardware combination supports it (without bugs) and the user configured the BIOS correctly. Most issues are seen when the BIOS is buggy and when the "translated badly from Chinese" BIOS GUI confuses the user (PEBKAC) but we also see cases where hardware doesn't send/keep power to the special USB port during suspend properly (even when the BIOS is configured right) which ensures the receiver never sees the IR wake signals. So no idea what problem you have .. but that's a summary of where things normally break.

    Ahh.. my bad, it's nvidia-xconfig that we include not nvidia-settings. The nvidia-settings code requires Qt and a load of other not-otherwise-needed stuff to run so it could be packaged up as an add-on, but this probably needs to be a user-community effort as I'm not sure any of the core devs will be too interested in the task. It might be worth seeing how nvidia-settings actually implements the LED status changes as it's probably just code wrapping to simplify setting of things via other means.