Crossepg keeps reverting to internal flash ?

[IAmATeaf]

Cut and paste of my posts on DW Sorry it's chapter and verse but the posts below explain what I think the problem might be and the solutions.

This was my hack-ma-jack type fix to get arouund the problem of Crossepg reverting to Internal Flash:

After the changes yesterday, checked the box and git274 is still pointing to the USB for me.

No idea why I didn't think of this before but this might have the simplest of fixes, no idea why it didn't occur to me before.

Crossepg seems to be reverting back to internal flash and point to /usr/crossepg/data so why not just create a symlink so that the data folder points to either /media/hdd/crossepg or /media/usb/crossepg, it doesn't fix the problem per-se (more like masks the problem) but it creates what I think might be a working work around.

With the above in place it doens't matter what Crossepg configures itself to as downloads will all end up in the same place. The only issue might be that when Crossepg points to the USB or HDD the location of the file epg.dat is either /media/usb or /media/hdd but it you purposely set Crossepg to use the Internal Flash then the symlink idea would work.

I then posted specific instructions on how to do the above:

.... do what I suggest above, configure crossepg to save to Internal flash, then using DCC go into /usr/crossepg, have a look in the data folder, if this is a new install there should be nothing in the folder. If the folder is empty, delete it, then create the folder crossepg in either /media/hdd or /media/usb. Then use the right click option in DCC, select symlink to create a symlink, name the link data and then put in either /media/hdd/crossepg or /media/usb/crossepg as the destination/target.

If you've done things correctly, then when you click on /usr/crossepg/data it should take to the crossepg folder on your HDD/USB.

Then do a download and even though it's set to Internal Flash it should push the files onto the HDD/USB.

I'm at work at the mo so the above might be wrongly worded as I've typed the above from memory, but hopefully it should be almost correct.

If the data folder has stuff in it, then back it up before deleting it, I'm sure there should be nothing in there that you need, but better safe

[IAmATeaf]

I then amended the Crossepg Configure screen code so that when it ran it would write out some debug information, this is where I found that it was actually the 'touch' command that was failing:

So although it found the USB and HDD drives, the test that it performs to determine if they are read/write had failed, as this test failed it no longer presents them as options and basically falls through the code with the only thing it can do which is to use the Internal Flash.

I'm going to have a look at the code that performs the read/write test to see what's going wrong in there, not much code in there to be honest it uses the touch command to effectively create a file, if the file exists then it works out that the drive is read/write, if it doesn't then the test fails.

I then had another look at the code:

I've had a look at the code that determines if the partition is read/write and I personally can't see any logic failure:

        [I]def isMountedInRW(self, path):
                testfile = path + "/tmp-rw-test"
                os.system("touch " + testfile)
                if os.path.exists(testfile):
                        os.system("rm -f " + testfile)
                        return True
                return False
[/I]

So it forms a path to a file e.g. /media/hdd/tmp-rw.test, then use the touch command to update the date/time stamp on the file, touch will create the file if it doens't already exist, it then checks for the presence of the file. If the file exists then it deletes the temp file it created and then returns True to signify that the partition is read/write.

So the only way it can return False is if the touch command failed for whatever reason, I can only assume that the touch command failed as I'm sure I checked (but am not too sure) the partitions and the temp file wasn't on either.

As others have pointed out once in this situation you can't select anything other than Internal Flash until a restart of Enigma2 so as a test I created the temp file on the HDD and without a reboot the HDD was then presented as an option with the Configure screen as it fell through the code, determined that the file existed and therefore is read/write.

I'm not too sure how this can be debugged further but I'll have a think.

[IAmATeaf]

I then posted on the OpenPli forums asking for help:

I posted on the OpenPLi forums as to why the touch command randomly fails and I've had a number of answers back.

It seems that making a system call from within python is known to randomly fail, nobody really knows why but it's suspected that the call fails with an out of memory type error. The line of code:

                 [I]os.system("touch " + testfile)[/I]

spawns a new shell and it's the spawning that fails. I've been told to recode the section to use native python code which is exactly what I do in order to create the debug files that I create.

Am working at the mo but will have a go at doing this in the evening.

If the above is true then it sort of confirms what I've found and suspected which is that if you configure Crossepg and then never ever look at the Configure screen ever again it should stay on the setting that you've selected and that it is the Configure screen that's actually causing the problem.

[IAmATeaf]

And then finally what I think might be a fix

Done the changes, if anybody else wants to try then you need to edit the file /usr/lib/enigma2/python/Plugins/systemPlugins/CrossEPG/crossepg_setup.py

Find the section:

        [I]def isMountedInRW(self, path):
                testfile = path + "/tmp-rw-test"
                os.system("touch " + testfile)
                if os.path.exists(testfile):
                        os.system("rm -f " + testfile)
                        return True
                return False[/I]

and change it to

        [I]def isMountedInRW(self, path):
                testfile = path + "/tmp-rw-test"
                open(testfile, "wb").close()
                if os.path.exists(testfile):
                        os.remove(testfile)
                        return True
                return False[/I]

As you can see I've replaced the 2 os.system calls with hopefully what are native python commands. So the code behaves in the exactly the same way but just uses a slightly different method.

After amending the file, delete the file /usr/lib/enigma2/python/Plugins/systemPlugins/CrossEPG/crossepg_setup.pyo, you shouldn't have to do this but I always do, then restart enigma2, on restart it should rebuild the .pyo from the amended .py file. You can check this by the fact that if you deleted the file then it will be there, if you didn't delete the file then date and time stamp on the file will be roughly the reboot time.

Then I suppose it's a case of setting it to USB and waiting

[reddevil157]

Ok, so been looking & asking around. I have set epg download for 03.50 & set up a cron job to reboot after download. Have this going for the last 3-4 days & it hasn't reverted back to internal flash yet, fingers crossed.
tanx to fintannl.

[IAmATeaf]

To be honest from what I found it only reverts if you use the Configure screen to check to see if it has reverted.

I've amended the code slightly as somebody on the OpenPLi forums pointed out that the code would green screen if the partition you were actually testing was read-only:

    def isMountedInRW(self, path):
         testfile = os.path.join(path, "tmp-rw-test")
         try:
             open(testfile, "wb").close()
             os.unlink(testfile)
         except:
             return False
         return True

I'm now investigating another problem where even though the download occurs overnight without any errors the EPG cache file epg.dat doesn't get updated as part of the download process.

[simrec]

CrossEPG

Hi....again

I have tried posting several times not just here but on other forums but nobody loves me ...sob sob :P

I am a newbie and am therefore unable..at this time... to contribute meaningfully to problems posted by others, but we all have to start somewhere

I have tried PM's but no replies

My problem has escalated so that the HDD will not mount (I get GSOD on >blue >blue >devices). I have tried initialising (I get an error message..partition not found) and CrossEPG wont work

I have Vu+ Duo running BH 1.7.9...can anyone take pity on me?

[philly]

Hi....again

I have tried posting several times not just here but on other forums but nobody loves me ...sob sob :P

I am a newbie and am therefore unable..at this time... to contribute meaningfully to problems posted by others, but we all have to start somewhere

I have tried PM's but no replies

My problem has escalated so that the HDD will not mount (I get GSOD on >blue >blue >devices). I have tried initialising (I get an error message..partition not found) and CrossEPG wont work

I have Vu+ Duo running BH 1.7.9...can anyone take pity on me?

I tried the latest BH image on 3 Vu+ duo's and had problems with green screen crash etc. I installed 1.7.6 which worked out OK. Give it a go.
Good luck

[simrec]

OK will give it a try..many thanks