PVRClient - GetEPGForChannel - server error in XBMC

[andyb2000]

XBMC keeps logging errors about EPG data and a server error being returned.

Let's take 'Fitness TV' for example (!), Channel data in the TVH webui is valid. Bringing up the EPG in the webui shows valid entries with start/end ok, nothing invalid looking in the entry.

Something that may have something to do with this, is a lot of these channels share their channel, i.e. one that I see often appearing in this server error list is BBC THREE and CBEEBIES which I know share the mux/channel, so could this be linked?
When the errors appear in XBMC, no debug errors are logged in TVH.

22:32:36 T:3013606256 ERROR: PVRClient - GetEPGForChannel - addon 'HTS Tvheadend:192.168.55.3:9982' returned an error: server error
22:32:36 T:3013606256 ERROR: EPG - Update - failed to update table 'Fitness TV'
22:32:36 T:3013606256 ERROR: PVRClient - GetEPGForChannel - addon 'HTS Tvheadend:192.168.55.3:9982' returned an error: server error
22:32:36 T:3013606256 ERROR: EPG - Update - failed to update table 'JML Direct'
22:32:36 T:3013606256 ERROR: PVRClient - GetEPGForChannel - addon 'HTS Tvheadend:192.168.55.3:9982' returned an error: server error
22:32:36 T:3013606256 ERROR: EPG - Update - failed to update table 'Horse & Country'
22:32:36 T:3013606256 ERROR: PVRClient - GetEPGForChannel - addon 'HTS Tvheadend:192.168.55.3:9982' returned an error: server error
22:32:36 T:3013606256 ERROR: EPG - Update - failed to update table 'Believe TV'
22:32:36 T:3013606256 ERROR: PVRClient - GetEPGForChannel - addon 'HTS Tvheadend:192.168.55.3:9982' returned an error: server error
22:32:36 T:3013606256 ERROR: EPG - Update - failed to update table 'JML Cookshop'
22:32:36 T:3013606256 ERROR: PVRClient - GetEPGForChannel - addon 'HTS Tvheadend:192.168.55.3:9982' returned an error: server error
22:32:36 T:3013606256 ERROR: EPG - Update - failed to update table 'Bangla TV'
22:32:36 T:3013606256 ERROR: PVRClient - GetEPGForChannel - addon 'HTS Tvheadend:192.168.55.3:9982' returned an error: server error
22:32:36 T:3013606256 ERROR: EPG - Update - failed to update table 'QVC Beauty'
22:32:36 T:3013606256 ERROR: PVRClient - GetEPGForChannel - addon 'HTS Tvheadend:192.168.55.3:9982' returned an error: server error
22:32:36 T:3013606256 ERROR: EPG - Update - failed to update table 'Best Direct'
22:32:36 T:3013606256 ERROR: PVRClient - GetEPGForChannel - addon 'HTS Tvheadend:192.168.55.3:9982' returned an error: server error
22:32:36 T:3013606256 ERROR: EPG - Update - failed to update table 'men&movies'
22:32:36 T:3013606256 ERROR: PVRClient - GetEPGForChannel - addon 'HTS Tvheadend:192.168.55.3:9982' returned an error: server error
22:32:36 T:3013606256 ERROR: EPG - Update - failed to update table 'SAB TV'
22:32:36 T:3013606256 ERROR: PVRClient - GetEPGForChannel - addon 'HTS Tvheadend:192.168.55.3:9982' returned an error: server error
22:32:36 T:3013606256 ERROR: EPG - Update - failed to update table 'Argos TV'
22:32:36 T:3013606256 ERROR: PVRClient - GetEPGForChannel - addon 'HTS Tvheadend:192.168.55.3:9982' returned an error: server error
22:32:36 T:3013606256 ERROR: EPG - Update - failed to update table 'Retail TV'
22:32:36 T:3013606256 ERROR: PVRClient - GetEPGForChannel - addon 'HTS Tvheadend:192.168.55.3:9982' returned an error: server error

[adamsutton]

Yeah that might be something. I thought they didn't share a CID, but maybe they do. I'll take a look at how my system performs when its up and running again.

[adamsutton]

Confirmed. I'm also not getting several channels including CBBC and CBeebies both of which I think time share (BBC Three and Four or something like that). Strange though that the info is clearly in the TVH DB properly (for all channels).

[adamsutton]

Ok, not so confirmed. Just did a full reset of the XBMC PVR database and it started working. It's possible that between the various runs (I know I've been running things very differently each time) XBMC has gone confused over the channel numbers and while most of what it had was still valid maybe some weren't?

But at this stage this is speculation.

[adamsutton]

ok confirmed again. happened again after I reset everything to test another fix.

this time I have a suspicion. from what I remember of xbmc if next (in channel response) is empty it won't fetch the epg. maybe I'm not properly reporting next for part time channels (where there us no now?).

though this only a guess at this point.

Sent via Hubroid

[andyb2000]

Yep, did the same, reset and try again and the fault happens again. Seems to be channels that are part time.
I don't seem to see the 'programs start at x pm' in the xbmc schedule so perhaps it's related to the length of that placeholder or something (guessing! )

Cheers

Andy

Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Adam Sutton reply@reply.github.com wrote:

ok confirmed again. happened again after I reset everything to test another fix.

this time I have a suspicion. from what I remember of xbmc if next (in channel response) is empty it won't fetch the epg. maybe I'm not properly reporting next for part time channels (where there us no now?).

though this only a guess at this point.

Sent via Hubroid

---

Reply to this email directly or view it on GitHub:
#13 (comment)

[adamsutton]

Yeah its gotten worse as well. In trying to test the issue I actually managed to crash TVH. The only good thing is the crash is completely repeatable so hopefully I'll be able to find the problem.

[adamsutton]

Crash was (I think) a red-herring. I've found the source its a lack of testing when I extract objects (which can be of multiple object types) from the EPG object hash based on an ID. This means that if XBMC asks for event=X (which should be a broadcast) but it is in fact a season (or something else) all hell breaks lose when it tried to incorrectly use the pointer/memory.

This occurred (I assume) due to my messing about with the DBs again. But I have plugged this whole (not yet committed).

[adamsutton]

OK, this seems really hit and miss at the moment. I just tried completely reloading the XBMC EPG several times. One time I got most channels but noted that CBeebies was empty, re-run and its back.

So at a loss as to what could be happening, interestingly I don't think I restarted TVH between those two runs, so it should already have been in the right state? Very odd.

[adamsutton]

I'm beginning to think that this is "random" and depends on the current state of the DB and whether the opentv grabber is actively running.

Because of how the data is built (from opentv) in two halves is possible to have broadcasts without episodes attached, if this happens it will cause XBMC to report a malformed event record (which is what I'm seeing).

I've been planning to rewrite the opentv code to do things better, so I think I'll do that and see if it makes the issue go away.

[andyb2000]

Interesting, I've not really noticed apart from it seems to be the same channels time and time again, BBC Three seems a constant one for me, I'll try another few db resets/power cycles and see if I can get that one to load.

Sounds an interesting theory on the data build and xbmc pulling an invalid event at the moment.

[adamsutton]

I think that your right about it being the part time channels. but I think its probably got something to do with the shared episode entries because the close entries have an empty string as description.

Sent via Hubroid

[andyb2000]

I've never noticed this before but actually going on the TVH webui,
choosing BBC THREE, the Title I actually see for the holding spot is wrong!
It says:
"..programmes start at 6.00am"
Which is interesting, as BBC THREE starts at 7pm, and Cbeebies starts it
channel broadcasts at 6am, so this does appear linked!

Cheers
Andy

On 24/06/12 17:49, Adam Sutton wrote:

I think that your right about it being the part time channels. but I
think its probably got something to do with the shared episode
entries because the close entries have an empty string as
description.

Sent via Hubroid

--- Reply to this email directly or view it on GitHub:
#13 (comment)

Andy
e: andy @ thebmwz3.co.uk
e: andy @ broadcast-tech.co.uk
w: http://www.thebmwz3.co.uk
w: http://www.broadcast-tech.co.uk

[adamsutton]

Yeah, that's what happens because of what I described above.

To get a "basic" episode equivalence I use a hash of either description, summary or title (in that order taking whichever is set). Unfortunately these place holders have no (useful) description, but have an empty text field. Unfortunately this passes the simple is it set test and causes my code to hash (" "), and basically all these close entries share the same episode (which includes the title).

So currently the title will keep changing to whichever one was last processed, check again later it'll might say starts at 7pm for both channels.

I'm currently working on sorting out how I build the data in opentv to a) account for these empty descriptions and b) account for the fact the info is provided in two halves.

Whether this will actually resolve the issue I'm not yet sure. But it always worried me the way I was putting things together bit at a time, so I'll be happier to get this out of the way and see if it helps.

[adamsutton]

Just a quick update, I have had a go at rewriting the opentv code to do a better job of putting things together. There may be short periods in which the data isn't entirely correct, but that shouldn't cause the XBMC problems that I was seeing.

It all stems from opentv splitting its data in a rather annoying way and my attempts to efficiently and reliably put things back together. Basically what may happen now is that when the TITLE record is received it will find/create a broadcast entry. If this "creates" an entry it will create a new episode using a hash of the title to get the URI. This at least leaves an entry that XBMC can use (i.e. it has a title).

If a subsequent SUMMARY record comes along it will potentially create a new episode entry (using hash of summary/desc for URI) that will replace the old one, but will maintain the previous title (since it has none).

It's all a bit of a mess, but it should do the trick. However I've not had a chance to test it yet.

[adamsutton]

I think the latest code on the epg-rewrite branch will solve this. However I've not done enough testing yet to say for sure.

[adamsutton]

Andy reports this is now working on his setup.