Posts by jahutchi

    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?


    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:



    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.


    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.


    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):

    1. 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.

    1. <TVGuide>
    2. <remote>
    3. <!-- Yellow Button -->
    4. <yellow>SendClick(28)</yellow>
    5. </remote>
    6. </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.

    Please see my post on page 13

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



    ... Millhouse build #0108b:


    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.

    I have now also tested using:

    8.2.2 official (i.e. kernel 4.11.12) with the Linus Torvalds patch installed, rather than reverting 4cd13c2: BEDD

    This also works perfectly - same results as per reverting 4cd13c2. I can watch live tv and record a further 3 programs at the same time without any breakups or continuity counter errors in tvheadend.

    Further proof that both reverting 4cd13c2 and using the Linus Torvalds patch appear to have the same positive effect.

    But unlike the softirq problem this does not affect the recorded stream, this is a playback-only issue.

    The problem i experienced on my Acer revo with the millhouse builds may therefore be different to those you're seeing on the rpi3, as the issue did effect the recorded stream:


    did you see continuity errors such as these in your tvheadend log?

    I'm afraid so. But unlike the softirq problem this does not affect the recorded stream, this is a playback-only issue. Also, I don't know when this started - I did not test kernels 4.10/4.11/4.12/4.13.

    As mentioned in my previous post, I'm currently running 4.11.12 (kernel shipped with 8.2.2 official generic build) with 4cd13c2 reverted. I've been running this build for the past week or so without any breakups, and have been testing today to double-check I can both record and watch at the same time. I had 3 programs recording and watching a fourth, without any breakups. So I would suggest this further regression has occurred since 4.11.12.

    Is anyone able to test #0108b on x86_64? jahutchi I think you have a Revo 3700 (Atom D525 quad core) - are you able to test this build

    Apologies that I've not been able to contribute as much as I would like over the last few days - work & family life getting in the way, but I have been following these threads with interest.

    I have been testing some builds...

    My testing suggests that both reverting 4cd13c2 and using the Linus Torvalds patch have the same positive effect, but that there has been a further regression in later kernels 4.14/4.15? as also suspected by smp - whereby I can no longer watch and record programs at the same time :-(

    Millhouse build #0108b:


    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.

    8.2.2 official (i.e. kernel 4.11.12) with just 4cd13c21b207e80ddb1144c576500098f2d5f88 reverted: ANGH

    I can watch live tv and record a further 3 programs at the same time without any breakups

    I am currently building an equivalent 8.2.2 official image with the Linus Torvalds patch included, rather than reverting 4cd13c2 - to confirm for sure whether both patches do indeed have the exact same positive effect.

    Over the past couple of months I've been bisecting and debugging the kernel on my Acer Revo 3700 Generic x86_64 machine. This was quite a learning curve, as I haven't previously used git very much let alone bisect a kernel. However, I found there were plenty of guides around on the internet, so I was quickly able to get upto speed. I must also say that the build system for LibreELEC is extremely well put together and easy to follow.

    After approx 50 builds I believe I've found the answer....I've hit a few issues along the way - the main problem being that at several commit points in the 4.9 rc1 development the kernel would not compile due to breakages in the netfilter module, and this was preventing me from getting close to the troublesome commit. I therefore disabled netfilter in the kernel options, and from then it only took a couple of weeks to locate the troublesome commit.

    Here is my git bisect log:

    So this indicates the troublesome commit is: 4cd13c21b207e80ddb1144c576500098f2d5f882

    To test this theory, I've created some builds based on 8.2.2 with a kernel patch applied to revert the change made under 4cd13c21b207e80ddb1144c576500098f2d5f882.





    I've tested the Generic builds on my Revo 3700 which appear to work... no artefacts after running for a couple of days, whereas I'd normally see artefacts every 2-3 minutes with any of the 4.9+ kernel-based builds :-)

    The Generic build also contains a further kernel patch to address the buffer overflow problem in timer.c as discussed on page 8 of this thread (Kernel 4.9.x drops USB data on Pi 2B (regression from 4.4.x) · Issue #2134 · raspberrypi/linux · GitHub). Since I found this also has impact but to a much lesser degree - without this you may get artefacts maybe 2-3 times per day depending on usage. The v4.9.59 kernel shipped with 8.2.2 for RPi2/3 did not require this patch as it's already fixed in that version.

    Maybe others could perform some testing on these builds (especially on the Pi2/3) to confirm whether this does indeed resolve the issue.

    In the longer term I have no idea on the best way to fix this - it looks like the commit was made to quite intentionally send all I/O traffic onto the ksoftirqd process queue rather than processing the request immediately. This seems to have consequences for lower-spec devices where you are trying to use DVB cards. My Revo 3700 machine has a quad core 1.8GHz processor and I have a fairly minimal LE build with only a handful of addons installed. It works perfectly with 4.8-based kernels, but suffers badly with artefacts on unpatched 4.9+ kernels, with picture breakups every 2-3 minutes, or even more often when put under heavier I/O load. This seems to fit with what others have reported in this thread - i.e. the problem surfaces when under heavier I/O load.

    Update: deleting my .config folder fixed that problem. Ive done some testing against the latest millhouse build (Milhouse-20171214210652-%231214-g9155531) but still have stream corruption im afraid :( back to my attempts to bisect the kernel i guess

    I just tried the generic build to test whether it fixes the issue on my machine but get a blank screen and cant figure out why. Here is the output of my journalctl: NHSG

    I do not get a kodi log so dont think its getting that far. I tried wiping my .kodi directory too and that had no effect.

    Do these test builds support nvidia_legacy_340? My graphics card is an ION2. First time i've tried a millhouse build on this box.

    Meanwhile i've been bisecting the 4.9 kernel and was starting to narrow down the commits, so will pause my efforts and try merging this patch into my custom build to see if it improves things.