Crossepg DM800se not updating correctly

teaf, Im using your git 290 crossepg and noticed the epg didnt update today, but using the old way by replacing the subprocess.pyo and crossepg.py with the files you uploaded it always did but just crashed sometimes, should i have added those two files or does your modified 290 add them automatically?
 
teaf, Im using your git 290 crossepg and noticed the epg didnt update today, but using the old way by replacing the subprocess.pyo and crossepg.py with the files you uploaded it always did but just crashed sometimes, should i have added those two files or does your modified 290 add them automatically?

The subprocess.pyo should be added by the opkg install python-subprocess command and the py files are included as part of git290.

You've found exactly what I found with my box last night, see my earlier post which mentions that I've added more debugging info to the loader file on my box and am testing it till it fails in the hope that it generates the trace log. Can you check if the log file trc-epg.log is in the folder where crossepg downloads its files overnight.
 
Last edited:
The subprocess.pyo should be added by the opkg install python-subprocess command and the py files are included as part of git290.

You've found exactly what I found with my box last night, see my earlier post which mentions that I've added more debugging info to the loader file on my box and am testing it till it fails in the hope that it generates the trace log. Can you check if the log file trc-epg.log is in the folder where crossepg downloads its files overnight.

no sign of it anywhere :(
 
no sign of it anywhere :(

Tis what I found, was a bit peeved that it didn't appear.

The reason the box no longer crashes is that as part of the modification to crossepg_loader.py I trap any errors or exceptions and then deal with them whereas previously there was no code there to handle a fatal error which is why the box would green screen. The code changes I've made are as below:

Code:
You don't have permission to view the code content. Log in or register now.

So the code in italics was already there and the code in bold is what I've changed/added.

Also, adding swap space definitely does help to keep the amount of free RAM from running really low. So for example without swap I'd have around 2.6mb free but with swap I now have around 4.9mb free as some of the programs in RAM that aren't used that often get swapped out. If you got a USB drive I'd definitely recommend creating say 16mb of swap space on the USB flash drive.
 
Last edited:
Also, adding swap space definitely does help to keep the amount of free RAM from running really low. So for example without swap I'd have around 2.6mb free but with swap I now have around 4.9mb free as some of the programs in RAM that aren't used that often get swapped out. If you got a USB drive I'd definitely recommend creating say 16mb of swap space on the USB flash drive.

Can you recap me how to create the swap space please :) ? I cant find the post :(
 
Last edited by a moderator:
teaf, since upgrading to your 290 version, im back to getting the same problem I was getting before you introduced the subprocess.pyo and crossepg_loader.py fix where it was update fine for a few days but then stop and will require a reboot to get it working again, but didnt you include the fix in this version? any idea?
 
teaf, since upgrading to your 290 version, im back to getting the same problem I was getting before you introduced the subprocess.pyo and crossepg_loader.py fix where it was update fine for a few days but then stop and will require a reboot to get it working again, but didnt you include the fix in this version? any idea?

Yes, the fix is included in the git290 package. Check that you have the file subprocess.pyo, should be in the folder /usr/lib/python2.6. Also check the file crossepg_loader.py, check post #164 above to see the edits I've made.
 
Tis what I found, was a bit peeved that it didn't appear.

The reason the box no longer crashes is that as part of the modification to crossepg_loader.py I trap any errors or exceptions and then deal with them whereas previously there was no code there to handle a fatal error which is why the box would green screen. The code changes I've made are as below:

Code:
You don't have permission to view the code content. Log in or register now.

So the code in italics was already there and the code in bold is what I've changed/added.

Also, adding swap space definitely does help to keep the amount of free RAM from running really low. So for example without swap I'd have around 2.6mb free but with swap I now have around 4.9mb free as some of the programs in RAM that aren't used that often get swapped out. If you got a USB drive I'd definitely recommend creating say 16mb of swap space on the USB flash drive.

thanx mate, i've added the extra code, not sure if i was supposed to delete anything?
 
thanx mate, i've added the extra code, not sure if i was supposed to delete anything?

Hmm, did you check to see if the file already had the edits?

My EPG failed to update this morning and the extra debug code has revealed ........





Drum roll .........






Feck all :(

Code:
You don't have permission to view the code content. Log in or register now.

It looks like whatever happens that stop crossepg from running the external program also fails to run my attempts to debug the code, so in the above code, the crossepg_epgcopy fails and raises an exception, so I trap this and then attempt to run the same command but via strace, this also fails and raises another exception. So it does look like whatever happens to crossepg actually stops any external program from being called and run.

Not too sure what to do next, might try posting on a few forums and see if anybody has any bright ideas.
 
Hmm, did you check to see if the file already had the edits?

My EPG failed to update this morning and the extra debug code has revealed ........





Drum roll .........






Feck all :(

Code:
You don't have permission to view the code content. Log in or register now.

It looks like whatever happens that stop crossepg from running the external program also fails to run my attempts to debug the code, so in the above code, the crossepg_epgcopy fails and raises an exception, so I trap this and then attempt to run the same command but via strace, this also fails and raises another exception. So it does look like whatever happens to crossepg actually stops any external program from being called and run.

Not too sure what to do next, might try posting on a few forums and see if anybody has any bright ideas.

it hads the original edits but not the edits you posted a fewe posts up.
 
I've posted my finding re strace not working on the OpenPLi forums and I've been told that again that this out of memory problem is sort of known and again nobody knows why it happens. I've been pointed to using a callback routine which I tried to get working before but the problem I had is that call is asynchronous so that the code continues to fall through the rest of the code the second the external program is called which normally wouldn't get run until the external program has finished. So with my current knowledge of the callback routine the epgload program is called but then the lines under that continue as the epgload program then effectively runs in the background which then interrupts the plugin when it's finished by which time the plugin has dropped through the rest of the code and exited, result being that the epg data doens't get updated.

I've been told that I should be able to get it working so when I get some time over the next few weeks I'll continue to look at it.
 
Possibly some good news, in the sense that I think that I might have got it going using the callback method.

It certainly works when I force an epg load from the CrossEPG menus.

Will wait and watch what happens when it runs overnight and report back.
 
M8 you a top member all the work your putting into this issue, you should get a medal been working on this for weeks now. :)
 
My revised code appears to be working so here it is for anybody that wants to help with testing it, same story, make a backup of the original file and then overwrite with this copy and then restart enigma2.

If anybody is interested I replaced this section of code:

Code:
You don't have permission to view the code content. Log in or register now.

with this:

Code:
You don't have permission to view the code content. Log in or register now.

Also made similar changes in the loadEDG subroutine.

What the code used to do before was spawn a separate shell process by using the os.system call which would randomly fail.

What the new code does is use an Enigma call which effectively is built in functionality but it runs asynchronously which is what initially threw me. The line def dataAvail gets called whilst the program that processes the EPG runs in the background and the line def appClosed gets called when the program finishes which is why the lines self.epgpatch(eEPGCache.getInstance()) and self.closeAndCallback(True) have been moved when compared to the original code.

So effectively, whereas the previous code used to step through line by line one after the other, the new code performs a callback to the plugin whilst the program that processes the EPG data runs. It all sounds waffly but I can't think of a simpler way to explain it all to be honest.
 

Attachments

  • crossepg_loader.rar
    2.1 KB · Views: 20
installed the file, deleted the pyo file as normal rebooted and then it updated fine, will keep an eye on it for you see how i get on.
 
The revised code has been working fine for with no missed updates. Anyone else have anything to report before I pass the revised code to the author?
 
sorry I havent been keeping up with this thread, I still reboot a couple of times a week to keep epg updated

so the file in post #177 where does this go mate and Ill put it on
 
Back
Top