Unexpected error in horizon.tv thread about tvgrabpyapi HOT 18 CLOSED

Try deleting the source definition files in ~/.xmltv/sources (in the userdirectory of the user running it!), so they get downloaded afresh.

from tvgrabpyapi.

from tvgrabpyapi.

I found the cause for the KeyError and am mostly surprised I have never seen it before. It comes from an error in tv_grab_API.json I just fixed. It might take ten minutes or so to propagate through any cashed data between you and github.
The weird thing is that this code bit deals with switching between the regularly alternating urls for horizon and should have shown up long time ago. Let me know if this solves it.

from tvgrabpyapi.

One other question. Does that high load stay indefinitely until you kill the script, and by indefinitely I mean more then 30 minutes?

from tvgrabpyapi.

from tvgrabpyapi.

from tvgrabpyapi.

The same KeyError: u'channel'?
That can't be as that key is no longer in data_def_names["source"]. I changed it to the correct u'channels'.
And tv_grab_API.json is always downloaded from git. So send me a log with the current error.

from tvgrabpyapi.

from tvgrabpyapi.

I guess you're referring to the dummy copy inside the package. I only update that on a new release. The live one is in the sourcematching repository.

from tvgrabpyapi.

from tvgrabpyapi.

OK, I get what is happening and to properly fix it, it needs some code adaption. But I think I can fix it for now by adding dummy entries to the horizon definition. I have to check if that won't have any repercussions else. The trouble is that this happens before the thread is tagged active, so the thread manager is not aware and does not correct the state resulting in an indefinite lock-up.

from tvgrabpyapi.

That's also why disabling the source does not help.

from tvgrabpyapi.

What puzzles me however is that it has not come up before and does not on for instance my system. This part is in place for over a year.

from tvgrabpyapi.

That won't do. The dummy entries get filtered by the conversion. I'll see if I can push a fix sometime soon.

from tvgrabpyapi.

Thanks for being on it. I'm having the same issues as easdue with exactly the same error (line 1996 and 2143). Can send more info if needed

from tvgrabpyapi.

I'm running fedora 27 and I have been using tvgrabpy since this summer. The error popped up I think last week so maybe an update here or there is the culprit (fedora is bleeding edge)

from tvgrabpyapi.

Try https://github.com/tvgrabbers/tvgrabpyAPI/releases/tag/beta-1.0.8-20180310

from tvgrabpyapi.

from tvgrabpyapi.