Tvheadend

Which satellite provider?

I've been having problems with getting the EPG from Sky UK but Freesat UK's grabber works fine.

Freesat UK im just using it for the freeview channels so I think thats the one.

I have a full Freesat and Freeview EPG FWIW, on 3.9.1074~gd9f1f88.

Do you have the Freesat EPG mux identified and active? (11426H, I think).

Yeah it appears to be there and enabled(auto) is in the epg scan column and enabled column is true.

I just changed the scan status of that mux to active it returned to idle but appears to have scanned as the epg items went from 4000(ish) to now over 17000.

So I will have to see if it keeps the epg updated now.

Oddly, I had to upgrade my kernel to 3.13 because of end-of-support ... and I'm also now getting EPG issues (e.g. nothing on CBBC HD on Freeview or Freesat). Not sure it's related, I'm going to reboot to an older kernel and do some digging...

Have you got any futher thoughts on what you've seen?

Odd. Rebooting from 3.13.0-32 to 3.5.0-54 and my EPG is filling fast... I've got CBBC HD events appearing, and I'm up to 43,000 events vs the 35,000 or so I had before the reboot (although I've peaked at nearer 80k in the past).

However, looking at my logs, any epg scan since 12th July seems to throw a 'data completion timeout' error - yet I didn't uprgade the kernel until the 16th. I suspect that's unrelated, though, and is more likely to be an artefact of a tvheadedn upgrade (to 3.9.1074~gd9f1f88) I did that day.

So, my thoughts now...

1. Do I need to recompile tvheadend on the later kernel? Clearly something changed in the EPG code, could that be it? Why would it only show when the kernel changes? DVB API?

2. Do I need to upgrade v4l-dvb (I see no reason why...)? Similar thoughts as above...

3. ... anyone got any other ideas?

Replying to myself... looking at .config.mk, I last compiled with (default options):

CONFIG_V4L = no
CONFIG_LINUXDVB = yes

... so it's not V4L... it looks like V4L-DVB and LINUXDVB have been converging, but they're different APIs.

My best guess is that something between kernel 3.5 and now has changed, and the compiled version I have is, therefore, wrong. I'll try recompiling on a later kernel and comparing the filesize/CRC as a start (same code base, different kernel). I just need to wait for the kids' programmes to stop recording for a while...

Hmm I dont think its kernel related as I have been compileing and updateing through all kernel revisions 3.13.x, 3.14.x and now on 3.15.6 and its only withing the last week(ish) that I have been noticing this problem with the epg.

(This is with periodic reinstalls of the server to clear out my tinkering).

So I think if it was kernel related I would of noticed much sooner.

At the moment I have 15 channels out of 100 in xbmc that have no epg at all this is with having that freesat epg mux active and scheduled to scan each morning at around 6 am.

EDIT:

Also i dont know if its related but my dvb-t channels have been haveing alot of issues playing over about the same length of time maybe a bit longer seems to come and go every couple of tvheadend updates.

Yeah, you might be right - I got SOME new events in the EPG, but not all, so I've rebooted back to 3.13 to see what happens. I'll rebuild tvheadend now anyway.

I lost power a few times this week (partly the network, partly the storms) so I suppose it might also be related to that. Or, or, or...

Q: When did the Commonwealth Games streams come on line? About the same time? Could there simply be some channel shuffling and/or EPG updates to accomodate this in some way?

A: Yes, that's part of my problem. CBBC HD is off air on Freeview to make room for the games... but still on Freesat. So, I'm getting conflicting EPG updates from the two channels.

... but I still seem to be missing BBC Four HD, BBC Three HD and some others in the EPG from Freesat ...

Okay, I'm not certain, but it looks like I'm getting pretty much nothing from the DVB-S EPG. At best, I get now/next... at worst, nothing whatsoever on any channel I've checked. I hadn't noticed before because like-named channels are merged with their Freeview equivalents, so the Freeview EPG has hidden the problem.

I've also reverted to a few versions of tvheadend from the past couple of weeks (back to 3.9.1032~g704c17e, anyway), just to see if perexg's latest EPG commits caused the problem... same problem. So I'm back to wondering whether something's changed on the EPG format that tvheadend isn't able to pick up at the moment. I'll ask on #hts when I get the chance, as it's very strange...

And.... they're back. Having poked, prodded and tweaked, having added some muxes and altered others, I finally set the networks to Idle Scan as I went to bed last night. Lo and behold, my EPG is now three times the size and all channels are present and correct.

Yeah that seems to of worked for me aswel.

Set the idle scan and left it all day and all channels seem to have epg now and epg items is over 20000.

I think it used to just populate all on initial scan. But oh well seems to be working for now.

Hello Guys!

A couple of days ago i have done the update of tvh from the unstable repo around 3.9.5xx to 3.9.1073 and after some time (think about 3 to 4 days) I had the same behavior that EIT-EPG data isn't grabbed anymore. I was happy that after the upgrade to 3.9.1083 the EPG data was fetching again. But I think that was the cause of the reboot after updating tvh. Today im missing EPG again on a bunch of channels. So I found this topic. And what can i say? In DVB Adapter -> Network configuration -> "Idle scan muxes" was "false". It seems that this option was magically disabled with the update and EPG was only updated directly afte rservice restart (Maybe option Skip initial scan=false ?). And i bet my 2 cents that enabling "Idle scan muxes" was the reason.

@Prof Yaffle

Thanks for digging into this and your efforts for the community.

Greetings from Austria :-)

Gern geschehen

I'm another who's got this problem. I had build 946 working fine. Upgrading to 1050 caused some problems, I can't remember what exactly, but when I downgraded back to I lost everything on the Automatic Recorder that was specifically tied to a DVB-S channel. DVB-T stuff and programmes not linked to any channel were fine. I'd also upgraded the kernel about that time. I can't remember to and from which, but both were fairly recent Arch Linux on arm5 (pink pogoplug), and it somehow overwrote the working firmware for my DVB-T stick with a non-working version, so I wasn't sure what caused the problem. Especially as I often do a full system upgrade before building tv-headend, in order to have it built against the latest libraries.

Theb I upgraded to 1083, and the problem I can't remember didn't come back. I did notice that I had lost the EPG for a couple of channels that only publish two or three days ahead, but I assumed that was linked to the new cron-able epggrab. Maybe I'd scheduled something to record a bit too close. But I've tried scheduling it with a clear window of at least an hour either side, and still it doesn't pick up anything from DVB-S. Changing idle scan to true doesn't seem to help either.

Looking at the messages, I see that it seems to be choking on a transponder that broadcast both in DVB-S/MPEG-2
and DVB-S/MPEG-4, namely 12604H on Astra 19E, and that it never moves on from there. It throws up a couple of errors, nit: invalid checksum (len 832), and eit: invalid checksum (len 1609), and then seems to stop scanning.

For me now even on the latest builds 3.9.1227 (built today 7 Aug 2014) the epg only seems to properly update during the initial scan not during the idle scan is anyone else seeing this?

Does anybody have any idea why this is happening?

Yes I'm getting some wierd EPG not scanning in last couple of hundred commits, things were fine around 3.9.570, but from then it's been hit and miss with EPG just magically scanning in every 10 days or so for no particular reason.

Seems to be linked with enabling "idle scanning", which I disabled recently as it seemed to be adding loads of duplicate muxes and services (a bug), this never used to happen...hmmmm.

Also, when booting up the EPG grabber seems to just be scanning for hours and hours on all channels but with no results...

What's going on here?

Sorry Guys!

Seems that I was a little bit to fast with my last comment :-) . Im seeing this problem still on my setup. What I have noticed is when you tune to an empty channel (without EPG data) it beginns to fill up all channels from that transponder with actual EPG data.

So something strange happens here.

So if I can help to debug this, please let me know. Maybe you can also give me a hint how to start to debug this.

Br, Thomas

OK, This may be a question of getting all the settings and options right. And I remember that the old version of TVheadend would wake up to scan the epg once an hour no matter what the settings, so maybe the new behaviour is a bit more sensible. I just still can't work out exactly what some of these tick boxes do.

First of all we're talking about the DVB-S options here. When not recording, I'd expect a DVB-S card to do one of 4 things:

i) Power off and shut down,
ii) Usually power off, but power on to download epg information from time to time as scheduled,
iii) Power on continuously and cycle between transponders to download epg information more aggressively,
iv) Power on continuously without necessarily being actively tuned to a transponder

OK iv) seems a bit pointless, but it may happen.

So how do these tie in with the options in TVheadend? Under Configuration/DVB Inputs/TV adapters there is a tick box on the page for the DVB-S adapter for "Power Save" under the basic settings. But then on the settings page for the LNB connected to that adapter there is a "Turn off LNB when idle" tick box. What is the difference?

Then under Configuration/DVB Inputs/Networks there is an "Idle Scan Muxes" option. In the past this meant option iii) as I detailed above, whereas option ii) was the default. Now it seems to be necessary to enable it just to make option ii) work. I'm not sure if this works in conjunction with the cron option under Configuration/Channel EPG/EPG Grabber, because I haven't enabled that since I missed a couple of recordings when they clashed with the epg grabber and the priority scheme didn't work properly.

With the "old" EPG method, all it needed was "Network Discovery" to be on.
Now it seems to need "idle scan muxes" to be on too.

It also seems to now be ultra sensitive to bad signal quality on ANY mux that is going to be scanned. That is to say that if there is any weak signal that will cause any BER errors on that mux then you'll have a problem, the EPG won't finish scanning and NO DATA will be added to the EPG.

The "old" method didn't seem to have this issue with bad muxes/reception/questionably low SNR/high BER errors.
It also seemed the "old" method loaded the data into the EPG in real time, that is to say that you could see data come through to the EPG database before the scan had completed.

I prefer the old method personally, as it just worked, it seems the new method is working for me, but I had to...

DISABLE ANY QUESTIONABLE MUXES THAT WERE ACTIVE
DISABLE EPG FOR QUESTIONABLE MUXES THAT WERE ACTIVE

Deleting the muxes is no good as with "Network Discovery" and "Idle scan muxes" turned on they will just be autimatically picked up again, so they need to be visible and disabled manually.