Posts by jahutchi

    Sadly, that patch didn't fix the issue. I was able to quickly reproduce it by disconnecting the antenna cable for 10 minutes and trying to tune to a bunch of transponders (when the cable was disconnected). When I reconnected the cable the device was unable to lock the transponders anymore until a reboot.

    Do you get any errors in dmesg under these circumstances? Such as the -110 timeout errors seen by others.

    I recently tried upgrading to a later 4.9.x kernel (4.9.111), as I'd noticed this fix which seemed related:

    kernel/git/stable/linux.git - Linux kernel stable tree

    However, I've just hit the problem again (admittedly, it took a couple of weeks to surface)...

    I have the following errors in my tvheadend logfile:

    Code
    2018-07-26 10:45:48.356 [   INFO] mpegts: 11778V in Freesat - tuning on Montage Technology M88DS3103 #0 : DVB-S #0
    2018-07-26 10:45:50.462 [  ERROR] diseqc: failed to set voltage (e=Resource temporarily unavailable)

    And the following messages repeating in dmesg:

    Code
    [934966.146448] m88ds3103 1-0068: i2c wr failed=-110
    [934968.283100] usb 1-1: dvb_usb_v2: usb_bulk_msg() failed=-110
    [934968.283107] usb 1-1: failed=-110

    Only thing I can do to get the darn thing working again is power cycle.

    I am therefore reverting back to kernel 4.9.88.

    Since my previous post, it's also worth noting that I've hit the problem (just once) on kernel v4.9.88. This was at a time when my machine was extremely sluggish because a process (tvheadend) ran out of control and chewed all my memory, causing excessive swapping.

    I downgraded tvheadend from 4.2.6 -> 4.2.5 where I don't see the memory leakage (reported here: timeshift buffer size problems - Tvheadend). So this could also be related to how busy the machine is at the point you perform the channel switch.

    jahutchi you need to read the error messages you've helpfully shared. If your DNS is not being updated, then running a resolve script will fix this for you.

    On LibreELEC the /etc directory is on a squashfs read-only file system.

    Any advice on where the scripts need to go to resolve this issue on a LibreELEC system?

    In the meantime I adjusted my network settings to use the Google Dns as this works both on and off the VPN. However, I would prefer to use the DNS of my ISP and VPN provider.

    I recently seem to have the same DNS issues that others have reported recently. I'm using PIA and have been successfully for the past couple of years. This problem has developed recently though not exactly sure when, and I have automatic updates enabled.

    Basically, after connecting to PIA I lose the ability to perform DNS lookups since my DNS settings are still set to that of my ISP rather than the PIA DNS servers.

    Here are the logfile entries from openvpn.log when I connect:

    I can see the DNS servers in the PUSH reply, but these do not take effect since nslookups are still using my ISPs DNS, and eventually timeout:

    Code
    # nslookup www.google.com
    Server:    194.168.4.100

    After reading this thread I tried activating the "Potential DNS Fix" in the advanced settings but this gave the error:

    A DNS fix was not possible. Refer to the Kodi log... which looks like this:

    Code
    11:03:37.389 T:140547394086656  NOTICE: VPN Mgr : (common.py) Creating a new APPEND.txt for Private Internet Access to try and fix DNS issues
    11:03:37.399 T:140547394086656   ERROR: VPN Mgr : (common.py) To attempt a DNS fix, you need to install update-resolv-conf script in /etc/openvpn
    11:03:37.400 T:140547394086656   ERROR: VPN Mgr : (common.py) Alternatively for systemd enabled installations, install update-systemd-resolved in /etc/openvpn/scripts
    11:03:37.400 T:140547394086656   ERROR: VPN Mgr : (common.py) After installation of one of the scripts, apply the DNS fix again.

    I'm running LibreELEC 8.2.5.

    Any help with resolving this would be greatly received and I'll be happy to run further tests to help debug where it's going wrong.

    For the time being, as a workaround, I think I will adjust my LE network settings to point at the google DNS servers.

    Subscribing to this thread since ive been affected by this too. Im currently running 8.2.5 with a 4.9 kernel (4.9.88) and no problems whatsoever. I did have problems of this nature when using the kernel shipped with 8.2.5.

    I also have this problem if i leave the power management options (e.g. S3 suspend on usb), enabled in the BIOS; which was also problem for me in older kernels too.

    I hit this problem too a few weeks back after upgrading my kernel to 4.9.92, so i went back to 4.9.88 and all good since.

    I don't know if the problem would exist if I had specified an external time server.

    I've just experienced this same problem over the weekend since the UK clocks went forward 1 hour for BST.

    I am running Kodi v17.6 on LibreELEC v 8.2.3 with Tvheadend v4.2.5, with the pvr.hts client on the same machine.

    I have not touched the LibreELEC time server settings, so it's using the standard internet time server that ships in the LE settings by default.

    On Saturday (when we were on GMT), I was looking ahead in the TVGuide as I wanted to schedule a program that started at 07:30PM on Monday 26th March. However, the TVGuide was showing the program as starting at 06:30PM. I then realised that this was probably because the clocks were changing Saturday night/Sunday morning, so I didn't worry.

    However, on Sunday morning, following the Daylight saving changes, I went to look in the TVGuide again and everything was still out by an hour including the programs currently playing. The system time, which is also displayed top-right of the TVGuide had been changed to reflect the DST, so this was correct. However, the TVGuide data was all out by an hour e.g. a show which started at 11AM was actually showing as having started at 10AM, so the timeline which goes vertically down the screen was therefore over whichever program would be playing in 1hr time.

    To correct this I went into Kodi Settings -> PVR & Live TV -> General -> Clear data. The database was cleared and refreshed from the Tvheadend backend (as mentioned, this is on the same machine). Following this, all the times were then correct. It would be nice if we didn't have to do this whenever the clocks change.

    Anymore hints? Otherwise I'll try to reinstall everything... And maybe switch to LE9

    In that case I would test whether the situation is improved in the LE9 millhouse builds.

    I have two MyGica T230 sticks too which work just fine for me under LE 8.2.3 on my Generic machine, though I use DVB-T2 rather than DVB-C which could be the difference.

    Presumably, you've only enabled DVB-C in the TVHeadend adapter settings and have not enabled DVB-T?

    Quote

    To be honest, I never closely investigated the logs, as I was a little overstrained with the amount of different logs and messages. Which would be relevant log be - to be fetched with dmesg?


    If you're having issues with channel switching then you probably want to in the the TVheadend logfile:

    /storage/.kodi/userdata/addon_data/service.tvheadend42/service.log

    Quote

    Do you think, the slow channel switching can also be lead back to interference problems?

    Seriously, I have no idea. As I mentioned in my previous post interference can cause all kinds of weird issues. But it's something you can easily rule out by trying the suggestions in my previous post.

    Quote

    Concerning the upgrade to LE9: Is the internal backup solution via the LibreELEC menu enough to be able to restore everything as it is now? Or do I have to manually backup certain folders (because you have mentioned to backup relevant folders in /storage).

    Personally, I manually backup anything that's on my storage partition that might be affected by an upgrade. I don't know what stuff you have installed so can't give you a definitive list on what to backup. Just have a look on your storage partition and figure out for yourself which files/folders need to be backed up. Prime candidates are ~/.kodi ~/.config ~/.cache. I don't use the internal backup solution provided by the LE addon, but others may be able to comment further on this.

    Quote

    I am a little confused wheter I should upgrade to LE9 - after all it is a Alpha - but still a lot of people claim that it runs even smoother than LE 8.2.x...

    As mentioned, it wouldn't hurt to try it and you can always revert back afterwards, as long as you've done a backup.

    When you are referring to the problems you have been having then - do you mean artifacts or slow channel switching?

    I've experienced various issues related to interference from other devices - mainly for me it was picture breakups, and usb drop-outs (with these errors in dmesg):

    Code
    dvb_usb_v2: usb_bulk_msg() failed=-110

    Interference, whether it be EMI / RF / Static, can cause all kinds of weird issues, and dvb adapters can be more prone to these issues that other devices due to the type of work they're doing - i.e. taking a signal from your aerial and demodulating it into digital images that your machine can understand, which are then transmitted down your USB wire. The types of problems caused by interference may vary from one device to another. It rang alarm bells for me when you said "without doing your recommended steps, the artifacts stopped" - because this is what I was seeing - one day it would be fine and another it would have issues.

    An example of another user with a similar problem to mine can be found here:

    DVBSky S960 USB failed=-110

    The user from that post reported that replacing the power supply for both RPI and DVBSky resolved the issue. I have replaced the PSU on my generic x86_64 machine which didn't make much difference. After that, for nearly a year, I was convinced it was a software rather than hardware issue, and was reluctant to splash out on new cables or hardware.

    At one point I purchased a new TV cabinet (not to try and solve the issue), but this forced me to have a real good tidy-up of my wiring. I also moved the router well away from my machine and dvb devices. I also had an external hard disk near the dvb adapters which I don't think was helping things and that was completely removed. At the same time I replaced some of the USB cables for ones with ferrite chokes, and made sure my T220 DVB-T2 cards weren't plugged directly into the back of the machine, but were connected through a USB M-F cable (£3 of amazon) which had good shielding and ferrite chokes at both ends. I'm not exactly sure which of these actions helped, but the drop outs stopped for several months, though I do still have very occasional (split second) glitches in the picture (maybe 2-3 times per week). I recently purchased a soundbar and had to re-arrange the wiring a little which disturbed things, and the usb drop-outs and frequent picture disturbances returned :( I therefore tidied the wiring once more and it's been OK the last few days (fingers crossed).

    Obviously, I have no idea whether interference is the cause of your issues, but speaking from my personal bad experiences it's well worth investigating. If the problem is easy to reproduce then even try temporarily moving the equipment to another room, to run some tests to determine whether you're device is being influenced by the surrounding environment. Also, I don't know whether your Pi is enclosed in proper casing - I would assume it does, since most come with the casing included by standard nowadays.

    Note: I personally still have small amounts of interference - i.e. very, very occasional split-second glitches and continuity errors in my logfile, so I think I still have small amounts of interference. I've just purchased a bag of ferrite chokes which I'm going to install on several of my wires. I'm not sure if this will help, but they're cheap so it's worth a go. Failing that, I've not yet replaced the power supplies that came with my DVBSky adapters, but may try that next since the power supplies they came with have very thin wires (2-3mm) which don't appear to have good shielding and don't have ferrite chokes.

    In general I'm now really pleased with my picturewhich is perfect 99.9% of the time, but I'm still striving to reduce the interference further.

    If you search around the internet for TV interference issues (not just with linuxdvb) then you will see that this can effect any household using any device (SkyTV / Freeview / etc), and you can find some real horror stories out there!

    It may also be worth trying the latest LE9 nightly - what harm can it do. It would certainly rule out whether the upstream drivers for your DVB card work better. If you backup the relevant folders on your /storage partition, then you can always put everything back to exactly the way it was afterwards should it not help.

    I hope some of these suggestions help, should your issue be related to interference.

    You may be suffering from some sort of interference (rf/emi/static). I struggled with this problem a couple of years back and it drove me crazy for over a year. I was experiencing usb drop outs and continuity errors which got worse the longer the machine was running. With the usb drop outs i needed to cold power down the machine and dvb cards to get back to normal. Skytv always used to advise powering down for a couple of minutes with their old boxes as they were known to freeze up when near sources of interference.

    A few tips:

    * try unplugging all nearby devices, and plug them in one at a time to see whether one of them causes the disturbance.

    * try moving both your machine and dvb devices to a different location away from the tv and any other devices that may cause interference. If this helps then...

    * Try different cables (power/usb/rf) - and go for ones that are well shielded/ avoid cheap cables.

    * Look at how your cables are distributed. Cables that are looped round each other and just thrown in a heap/spaghetti junction (like i had previously) can cause interference.

    * some devices such as wireless routers can cause interfence so try to place your machine and dvb devices away from these

    * as well as shielded cables you can look into ferrite clamps. These are cheap and reportedly can reduce interference, though the jury is out for me on that.

    If you're familiar with Kodi keymaps then one thing you can do is map the action "SendClick(28)" in the TVGuide section of your keymap to a remote button of your choosing.

    This would mean you need to firstly go into the TV Guide, but from there you can then get to the Channel Groups dialog with a single button press rather than going to the left slide-bar then keying down and selecting the Channel Groups option.

    For example, on my machine I have mapped "SendClick(28)" to my remote control's yellow button and it works a treat.

    Code
    <TVGuide>
      <remote>
        <!-- Yellow Button -->
        <yellow>SendClick(28)</yellow>
      </remote>
    </TVGuide>

    I also have a "Guide" button on my remote which is mapped straight to the TV Guide, so I can get to the channel groups by simply pressing "Guide" followed by "Yellow".

    If you haven't used keymaps before then this page should help:

    Keymap - Official Kodi Wiki

    28 is the ID for a built-in control within the PVR Guide which will take you straight to the channel categories selector. These hidden built-in button ID's aren't so easy to find, but are listed towards the end of the skinning manual:

    Skinning Manual - Official Kodi Wiki

    Please note that I haven't tried this in anything other than the default Estuary skin so can't promise it will work in Aeon Nox.

    I can confirm that the recorded stream plays fine on PC. The recording plays back with the same artifacts on LE.

    Any suggestions on how I could possibly resolve ?

    Have you enabled hardware acceleration (VDPAU in your case) in settings>system>display?

    My graphics card is also NVidia ION-based, and my machine cannot cope unless i turn on the h/w acceleration.

    Also, is your cpu overloaded when playing back the stream? As this would be another indicator that the stream is not being decoded by your gpu.

    -Hey all,

    I have x86_64 with 8.2.0 (kernel 4.11.12) and have issues with dvb. I have a DVBSky T9580 V3.

    Could somebody provide me a 8.2.2 release with linus torvalds fix?

    Best regards,

    Marcel

    Please see my post on page 13

    Here are the links again to some builds i made with the problematic commit reverted...

    LibreELEC-Generic.x86_64-8.2.2-dvbfriendly-nomb.tar

    LibreELEC-Generic.x86_64-8.2.2-dvbfriendly-withmb.tar

    ... Millhouse build #0108b:

    SHAS

    With this build I can get a stable stream when watching live tv. However, if I watch and record at the same time then I get breakups.

    Millhouse build #0101z: JYUK

    Same as above - I get a stable stream when watching live tv. However, if I watch and record at the same time then I get breakups.

    ...

    I've just been revisiting the issues I was seeing with the Millhouse Builds. I actually get breakups on those builds when simply viewing live TV using the MyGica T230 DVB-T2 Freeview tuner.

    My Machine has 2x DVBSky S960 DVB-S2 (Freesat) tuners and 2x MyGica T230 DVB-T2 (Freeview) tuners. In TVHeadend I have it configured to use the DVBSky S960's in preference to the MyGica cards for those channels where the stream is available on both networks. This is why I was only spotting the issue when both watching and recording - as that was forcing it to use the MyGica T230 card.

    So this looks like it is most likely a problem with the MyGica T230 drivers supplied in those builds so is unrelated to this issue - sorry for the noise.