Repeated crash with UK external XMLTV file - buffer overrun? about pvr.vbox HOT 61 CLOSED

Can you upload a copy of your external XMLTV file somewhere? That should be enough to be able to reproduce it. If you happen to have a Kodi crashlog then please upload that as well.

from pvr.vbox.

Thanks Jalle19

I have put it on Dropbox - https://www.dropbox.com/sh/xfqki8fyu6xcclz/AAAKTLbhqzV2pkNC9HmXr86-a?dl=0

Please let me know when you have it downloaded so I can close the link but actually you don't need it - just use the examples I give below:

However, please note that after spending hours editing xmltv.xml files, I've already pinpointed the problem as I detailed above - I'm pretty sure you could make your own xmltv.xml file with more than 995 characters in the <desc> tag and you'd get a crash:

This xmltv.xml file:

`

<tv> <channel id="3.radio.bbc.co.uk"> <display-name lang="en">BBC Radio 3</display-name> </channel> <programme start="20150602003000 +0100" stop="20150602063000 +0100" channel="3.radio.bbc.co.uk"> <title lang="en">whatever</title> <desc lang="en">aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa</desc> </programme> </tv>

doesn't crash

This one:

`

<tv> <channel id="3.radio.bbc.co.uk"> <display-name lang="en">BBC Radio 3</display-name> </channel> <programme start="20150602003000 +0100" stop="20150602063000 +0100" channel="3.radio.bbc.co.uk"> <title lang="en">whatever</title> <desc lang="en">aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa</desc> </programme> </tv>

does - every single boot. Nothing in the xmltv.xml file matters except the character length of the <desc></desc> contents. The only difference between the two examples I just gave you is the length of this: 995 vs. 996. Hopefully this is now clear.

from pvr.vbox.

Thanks, you can delete the Dropbox link now. I'll try to look into this tomorrow.

from pvr.vbox.

Unfortunately I'm not able to reproduce this. What platform are you using?

from pvr.vbox.

Raspberry Pi model B - which is inherently memory limited I guess - OpenElec 15 - all builds, same behaviour - currently Milhouse build #603 but the 5.95.1 official beta has same behaviour, so I think it is more to do with RPi

from pvr.vbox.

Can you check if you have any crash logs stored on your Pi? The should be in your home directory.

from pvr.vbox.

OK - will do this evening - thanks for looking into this

from pvr.vbox.

ok - log uploaded to same dropbox

from pvr.vbox.

Was the log helpful? Anything else I can do to help? - I read through your xmltv code and nothing jumps out at me - I suspect a problem in tinyxml2 on the pi but that's just a hunch - it seems clear that the problem is one of memory allocation somehow because I can reliably trigger the crash by adding a single character to the length of the description string in the 'desc' xml tag - despite trawling through the header files in tinyxml2, I can't see anything wrong with the way it's coded - it's a pity you cannot reproduce the bug - if you're prepared to give pointers to get me up and running with building your plugin/kodi on OS X for the RPi, I would be willing to have a crack at debugging it for you but, as I've not attempted cross-compiling for the RPi or buildling Kodi before, I'd probably get stuck without some help.

from pvr.vbox.

I tried reproducing this on a Raspberry Pi using a separate program but I couldn't reproduce it. Do you mind running the test program for me to see if it fails on your device? Here's how:

wget http://werket.tlk.fi/~negge/test-xmltv-description.tar.gz
tar -xvf test-xmltv-description.tar.gz
cd test-xmltv-description
g++ -std=c++0x -o test-long-description tinyxml2/tinyxml2.cpp test-long-description.cpp
./test-long-description

It should just print the description.

from pvr.vbox.

I certainly wouldn't mind - I'd be very happy to help in fact - but I cannot compile this on my RPi as I switched from a full OS to OpenELEC recently to improve stability / performance. As you know, this is a limited distribution that lacks compilers etc. I only have one working SD card at the moment as my other one is broken but I will go and buy one and get a version of debian up and running to do as you ask - I wonder if this is another piece of the puzzle - perhaps it is something to do with Kodi on OpenElec, rather than Kodi on debian? By the way, in case you don't read my reply on the Kodi forum, I apologise if my post came over as critical of your addon - that was not the intention - I wanted to warn other buyers of vbox that they might have problems.

Just thought - how easy would that be to cross-compile on my mac then run from the Pi?

from pvr.vbox.

Try this one instead: http://werket.tlk.fi/~negge/test-long-description.tar.gz, it's precompiled so you only need to untar the archive and run the test-long-description program. I doubt it will fail though, the issue is most likely more complicated.

from pvr.vbox.

Well sorry - you're right - it works fine - no crash, so I guess that rules out tinyxml2, right? - thanks for compiling it (I spent about 5 hours last night trying to get a cross-compiler working on OS X - it's a nightmare - I think I will pursue doing this so that I can start learning how to compile for kodi but I might bail on OS X and try running linux in a VM) - the bug seems quite odd - I am starting to suspect Kodi itself but then how would the simple IPTV plugin not cause a crash?

I have updated my firmware recently to a more recent build of openelec, so I will check to see if your add on still crashes - perhaps something in the RPi kernel or elsewhere has been fixed - will report back soon

from pvr.vbox.

Maybe Simple IPTV trims the long program information?

from pvr.vbox.

I was wondering the same thing - I will investigate

from pvr.vbox.

I'll update the version of tinyxml2 that is used (the current one is very old), that should hopefully solve the issue.

@Mhir it doesn't, but it does use a different XML parsing library.

from pvr.vbox.

Thanks Jalle19 - I did some more investigating - I will report my findings just in case it's helpful.

Firstly, Simple IPTV doesn't care what is in the <desc> tag - it can be any length and it doesn't truncate the contents but rather displays the whole thing just fine as Jalle19 says - as Kodi has no trouble with this, I can't think that Kodi is responsible for the crash (Also the crash happens during the XMLTV file parsing, rather than during display of the EPG information by Kodi).

Secondly, I found something a little bit interesting - pvr.vbox doesn't care about the actual size of the contents of <desc></desc> - it cares about the "line length" - so I can have multiple strings of 995 characters separated by carriage returns and that is fine - it displays them all - but if a single line is longer than 995 characters, it crashes - as before (and this is with the latest build of OpenElec).

I hope this info is helpful. Jalle19 - What I don't understand is how your test code for tinyxml2 ran without crashing as surely it replicates the function within pvr.vbox that is responsible for parsing the XMLTV file?

from pvr.vbox.

The addon uses system libraries on Linux, which means the version is not exactly the same as on Windows or OS X. I've changed it in my work-in-progress branch to use a local copy of the latest version so we can guarantee that the same code is being used on all platforms. I'll most likely make a new release tomorrow, stay tuned.

from pvr.vbox.

OK - thank you very much

from pvr.vbox.

Oh - I think I just realised something else that I wasn't completely clear about - I don't know if it makes a difference to diagnosis but it isn't a proper 'boot loop' that you get but rather that Kodi crashes and then auto-restarts, so the underlying OS doesn't crash and my ssh link stays intact - could this explain why your standalone code ran ok?

from pvr.vbox.

That just means Kodi crashed, not your operating systems.

from pvr.vbox.

sure - i just wanted you to know that in case it helped you to track down the bug

from pvr.vbox.

Hi Jalle19 - I'm sorry to be the bearer of bad tidings but unfortunately the bug persists :(

On the plus side, it crashes much faster, so whatever you have done with tinyxml2 has improved performance! (and more seriously on the plus side - the icon loading works nicely, which is a big improvement - thanks for implementing this - I wasn't able to load a full xmltv file so I wasn't able to check if the graphics in the EPG for each individual show also load like they do on simple IPTV but I will test this when the main bug is eventually found and fixed).

BW

sunstealer

PS - thanks again for all the hard work on this and please let me know what I can do to help you fix it

from pvr.vbox.

Can you post a new crashlog?

from pvr.vbox.

sure - will do shortly

can I ask please - where is EPG_TAG defined? Is it in the kodi headers?

from pvr.vbox.

ok - find the logs in the same dropbox - I just threw the lot in there - obviously the most recent one is probably the most useful but they are all probably the same as I let it crash and restart kodi quite a few times while I was doing something else in the background.

Please let me know what you're thinking - I am trying to set up kodi compilation in a virtualbox vm so that I can help but if you're already figuring it out, then it would be helpful to know

from pvr.vbox.

I really have no idea what's going on with your setup. Can you try to replicate it with a complete fresh profile? You can do that by logging in over SSH and move ~/.kodi to ~/.kodi.bak, then restart. You'll need to configure and enable the addon again of course. If it turns out it doesn't help, copy ~/.kodi.bak back to ~/.kodi. If you're feeling uncertain, create a backup from Openelec the normal way first.

from pvr.vbox.

You really think it's just my setup? That seems very unlikely to me given the nature of the bug (995 vs 966 chars length is surely a memory allocation issue - that seems obvious to me) and the fact that other IPTV plugins are working fine on my setup - but I'm happy to try your test - Were the crashlogs any use? - I didn't look through them.

My youngest is watching a movie right now on kodi but I will try your suggestion as soon as I can and report back - assuming this doesn't fix things, would you be willing to recompile your addon with a few minor variations that I can run as a test? I'll get back to you with the details if your test fails - if you're not willing, I will continue trying to setup compiling kodi on my own so that I can sort out this bug - cheers. I'm not at all phased by moving kodi and trying a fresh install.

from pvr.vbox.

OK - tested - I'm really not surprised to find that your addon still crashes even with a clean kodi install (all I did was enable TV and enable your addon, nothing else). It is still caused by a single line within the description tag exceeding 995 characters - surely this fact is some clue to where the bug is? I was a little surprised that you seem to be thinking this is something unique to my setup as it seems clear to me that the nature of the bug must mean an error in your addon or in the way kodi handles the output of your addon (on OpenElec on the RPi). I suspect the only reason you haven't had others reporting the problem is that there are probably very few owners of vbox in the UK or a country where long description strings exist in their xmltv.xml files, even fewer using Kodi as their media client and possibly only me using the OpenElec install of Kodi on the RPi with your plugin! ;-)

from pvr.vbox.

Can I suggest a test please?

Could you make the following change to client.cpp please?

// Transfer the programmes between the start and end times for (const auto &programme : schedule.schedule->GetSegment(iStart, iEnd)) { EPG_TAG event; memset(&event, 0, sizeof(EPG_TAG)); event.startTime = xmltv::Utilities::XmltvToUnixTime(programme->m_startTime); event.endTime = xmltv::Utilities::XmltvToUnixTime(programme->m_endTime); event.iChannelNumber = channel.iChannelNumber; event.iUniqueBroadcastId = ContentIdentifier::GetUniqueId(programme.get()); event.strTitle = programme->m_title.c_str(); event.strPlot = “”;

If you could send me a binary with this element disabled, then if the code ran without crashing on my xmltv.xml file then we could be sure that the problem was in the way kodi deals with long strings in event.strTitle. If it does crash then we know the problem is with the parsing of the description tag in your code and not in kodi.

from pvr.vbox.

You can trigger that behavior by renaming the channel in the XMLTV file to something that doesn't exist. That way the file will be read, all the events will be parsed, but none of it will be sent to Kodi since it doesn't match any channel.

from pvr.vbox.

Ah yes - ok - that's a great idea - I will do it and report back - thanks

OK - I tried this test - I renamed both the channel-id and display-name tags to be names that don't exist. The add on still crashes with 996 chars and not with 995, as before. So I guess that proves the problem is in the xmltv parsing as I initially thought. However, I am not sure I understand why your code that you compiled for me didn't trigger a problem or why upgrading to the latest tinyxml2 made no difference.

from pvr.vbox.

@sunstealer I have a PRi 2 and I tried to see if I can help.
I followed @MikeB2013 instructions on Kodi and downloaded today's Atlas EPG
I've installed a fresh openELEC 5.95.2 image and configured the vbox.pvr (1.3.2) to use the external EPG

So far it seems to be working well.

Now that I have a system running, is there anything specific that you do to crash the add-on?
Could this be a HW specific issue, maybe RPi 1B vs RPi 2

I've made a short video maybe you can spot the differences - https://youtu.be/65SwtYvR2cA

from pvr.vbox.

Thanks Mhir - great video! I am so pleased to find a fellow UK user!

One thing that occurs to me is that the description that was very long in the first file I had that crashed was for a radio program - did you add those too or just TV channels?

Can you try a new xmltv file like this (its sort of made up but it should do the trick):

`

from pvr.vbox.

Yes I have both TV and radio channels installed
I have looked into the EPG and found that it has even a longer program desc and there are others at about the same length

I've uploaded the full EPG and channel_mapping file here - http://tinyurl.com/nue6yso

My EPG file is located on an attached thumb drive, I will try a network drive too

from pvr.vbox.

@Mhir - thanks - this is very helpful

My hunch for a while now (I'd be interested in what @Jalle19 thinks) - is that this relates to a compiler setting for the Arm 6 compiled version of OpenElec, which is, of course, a different architecture from your RPi2, such that the size of a string is somehow misallocated.

However, I am not at all sure how this could happen. The other thing to note is that I was able to have very long description tags in my xmltv.xml file too but they were generally broken up by carriage returns within the tag - it turned out that only a single line longer than 995 characters (i.e. no carriage returns) triggered the crash. I tested this by entering strings of 995 'a' characters repeatedly, separated by carriage returns and I could have as many as I liked but if the first one was 996 characters, it crashed. It would be very interesting to know whether the file I pasted above works on your RPi2 - it may well, as I think that's what @Jalle19 used to test the first time (not sure about that) when he found no problem - this would confirm that the RPi2 definitely doesn't have the crash I'm seeing. I might be tempted just to upgrade as a solution if that's the case. When I have a spare moment, I'll try your files to test things the other way around.

Thanks v much for your help

from pvr.vbox.

I'm sad to say that once again I'm not able to reproduce this issue on my Windows machine (with the file you recently posted).

from pvr.vbox.

@sunstealer the xmltv file I am using have your 996 aaa string as well as other long desc.
I've placed it on a network folder and... my RPi2 started to crash, then I copied the same file to the RPi2's uSD and it stopped crashing.
I then configured my Windows to work with the same xmltv from the network folder and it worked without any issues.

• @Jalle19 I couldn't change the settings of the add-on once I've setup the external xmltv every time I changed the file location the add-on either crashed or ignored the change, at the end I've reinstalled the openELEC image

The log files are on the same link - http://tinyurl.com/nue6yso

from pvr.vbox.

So the parsing only fails when the file is on a network share?

from pvr.vbox.

Yes I think so and only with RPi,
I think that it is best if @sunstealer can verify that too

from pvr.vbox.

@Mhir - sorry I just got back home - this is getting weirder and weirder! I cannot begin to fathom how the combination of a network file and 996 vs 995 characters on a single line of text within a specific part of an xml file causes a crash! It's totally bizarre! I am amazed that your test was positive only if the file is on a network drive and will try locating my files on the RPi to see if it works - will report back shortly! Bearing in mind that the same xmltv file works with a different plugin when stored on the same network share, so the fundamental nfs code within linux must surely be alright - I'm totally baffled by this and I expect Jalle19 is too but maybe he's having a moment of genius as we speak! Thanks so much for taking this further - maybe now we can get to the root of the problem.

@Jalle19 - thanks for trying again with the other file - this issue is clearly turning out to be a lot more complex than I ever imagined it would be - I'm not entirely certain now that your addon is actually to blame but maybe your addon is demanding something differently from the OS or from Kodi itself than the other plugins do? I have started looking at nightik's code to see if I can understand how it differs - if I turn up anything potentially interesting, I will let you know but don't hold your breath!! ;-)

from pvr.vbox.

@Mhir - you're only bloomin' right mate! That's bizarre - I am shocked!

I have it working now with an external xmltv.xml file, stored locally on the RPi. This isn't a long-term solution for me because I don't have the atlas grabber compiled for the RPi - it runs on my NAS on a cron job

@Jalle19 - any ideas? This is really very strange.

One thing I did notice that is also very odd is that the time (top right) flickers between the current time and one hour before (we are in British Summer Time right now - it's almost as if the time is being reset to GMT then GMT+1 then back very rapidly - back and forth - each time something loads into the guide) - this happens only when the addon is parsing the xmltv file then it goes back to normal when it finishes. All the entries in the guide flicker in the same way between the current program and the one an hour previously until it finishes the parsing. This might be an unrelated issue - would you like me to start a new bug @Jalle19 for this?

Oh - incidentally, I had to downgrade to the same 5.95.2 build to get things to work - as @Mhir did - the more recent builds ignore the external xmltv file.

from pvr.vbox.

@sunstealer super 👍 , maybe until it get's resolved, you can run the grabber process on the NAS and save the file remotely on your RPi?

from pvr.vbox.

@Mhir - yeh - thanks mate - in the end I went back to Milhouse builds of openelec because they solve other problems that are in 5.95.2, so now I have a higher build of pvr.vbox that doesn't work on the RPi, so I am back on simple iptv client for now as it seems more robust generally at the moment - will keep trying with this though, as and when @Jalle19 makes progress with the bugs.

from pvr.vbox.

What's the issue with the latest release?

from pvr.vbox.

A combination of #76, which seems to be a new bug, unrelated to the problem that @Mhir found the solution to in 5.95.2 and the other weird bug that causes flickering time / EPG during parsing of the external xmltv, which happens on 5.95.2 & the latest builds - this is very strange and sometimes seems to cause crashes if kodi tries to do other things while the parsing is going on, like download updates for addons, for example. I haven't had time to dig into this in any detail I'm afraid but I can't get a stable / fully functioning TV service with pvr.vbox yet unfortunately.

from pvr.vbox.

Sorry - I've been away so wasn't able to check this until now - just tried latest version of pvr.vbox and it still crashes when parsing the XMLTV file as before - this should be reopened I'm afraid

from pvr.vbox.

Do you have a new crash log?

from pvr.vbox.

yes - can do if you think it will help - I never had the impression you found the previous ones helpful but perhaps I was wrong? I am at work right now but will send you another one when I can. Do you need me to enable anything in particular other than the usual debug level?

from pvr.vbox.

The code has changed (which is why I closed this) so it could turn up something new. You can enable debug logging, nothing more is required.

from pvr.vbox.

Sorry for necro-ing this, but as the issue is still flagged as open I thought it would be ok to comment.

I recently purchased a Vbox XTi-3442 and am seeing the same issue as originally described. If I use the OTA EPG from Freeview then there is no issue. If however I switch the Vbox to use an XMLTV file then the add-on crashes Kodi during the EPG parsing phase and Kodi ends up in a crash-restart loop.

If I also specify the XMLTV file directly in the add-on as an External EPG source it causes the same issue, so it would seem to be the parsing of the data within the add-on causing the issue. The Vbox itself appears to have no problem with the XMLTV file.

I'm currently running LibreELEC 8.2 on an x86 machine. I'm not at my machine right now, but is there anything I can supply that might be of help in tracking this issue down?

from pvr.vbox.

@relipo

from pvr.vbox.

Just wondered if anybody had had a chance to look into this? I've updated to LibreELEC 8.2.5, running on an x86 machine, and still see the issue. As before, the Vbox has no problem with the external XMLTV file, but the PVR.Vbox add-on crashes Kodi when opening the file either directly (as an external file) or directly from the Vbox.

from pvr.vbox.

Potentially fixed by:

#226
#227

Note that the external XMLTV is removed in the above PRs.

from pvr.vbox.

I had a similar issue to this on LibreElec with pvr.vuplus. It was a race condition ok loading the initial EPG. I wonder if it could be the same issue here.

from pvr.vbox.

https://github.com/kodi-pvr/pvr.vuplus/blob/96fdedbbcd8d992444a46973bda84d05eb320582/src/Enigma2.cpp#L142

https://github.com/kodi-pvr/pvr.vuplus/blob/96fdedbbcd8d992444a46973bda84d05eb320582/src/Enigma2.cpp#L446

So essentially skip the first EPG load.

from pvr.vbox.

This shouldn't be an issue, we hold a lock in the update thread and stall Kodi's initial EPG request until the lock is released. Could be that there's a bug in that logic though.

from pvr.vbox.

I did the same with vuplus. The issue was caused by two channel updates for EPG at the same time. The problem only ever occurred in *Elec.

from pvr.vbox.

Strange

from pvr.vbox.

Is there someone on this thread who can try this out solution if I implement it?

from pvr.vbox.

Closed by #228 and #229

from pvr.vbox.