Superb quality and spec AB-Com PULSe 4K SE. Crazy offer! Only £99! FREE UK DELIVERY! 4K UHD, Enigma 2, Multiboot 4 images & more!...
Superb quality and spec AB-Com PULSe 4K Rev II Twin Satellite tuner only £149! FREE UK DELIVERY! 4K UHD, Enigma 2, SATA HDD facility, Multiboot 4 images & more!...

[VU+ Solo2] Softcam issue?

Is there any progress on sorting this out via an update? I downgraded to 5.4.007 and Oscam- emu was still stopping but ecm times were low. I've gone back to 5.4.012 and Oscam-emu still stopping and ecm times are high.
 
Best imo to go back to 5.3.39 or to just start oscam up manually, if you wish to use 5.4.12, although it does eventually stop (with me after about 30 hours)
 
I went back to 5.4.006, disabled the freeze check in softcam manager, and have the box unthicked for restarting oscam, not 100%, but better then above 5.4.006.
 
So having had an issue with Oscam and reboot initialisation times, I added these changes to Scriptrunner to enable scripts to be run at startup time - it may or may not fix these issues experienced here but I would be interested in users trying the changes.
So in ViX Scriptrunner I have provided the means to enable a script to be run at bootup time or manually started (Softcam.sh) or stopped (SoftcamClose.sh) - the scripts are in the attached Softcam.zip and should be copied to usr/script.

So scripts are currently setup for oscam-latest and need to be changed if softcam is changed or is installed to differently directory (currently usr/softcam )

1. using Putty, login & stop the system (init 4)
1. copy plugin.py, ScriptRunner.py and setup.xml to /usr/lib/enigma2/python/Plugins/SystemPlugins/ViX
2. copy the unzipped softcam scripts (Softcam.sh & SoftcamClose.sh) to usr/script
3. in Putty reboot - init 6
4. Disable SoftcamManager (blue button), menu disable freeze check and everything else.... don't forget to save changes
5. Blue button, ViX -> ScriptRunner - Menu -> Enable script ----> don't forget to save changes
6. Reboot

Let me know if it improves the Oscam access.

You can also manually Start/Stop by selecting in ScriptRunner and hitting Run.

If it works for you then I will issue a Pull to ViX.
 

Attachments

@twol I have applied your changes, and will let you know what happens.
Running openvix 5.4.007 on an ET8000 box, non standard oscam.

Personally, I dont think it makes any difference if oscam is started by init.d or by a python console.
I believe that the issue was introduced between openvix 5.4.004 and 5.4.005!
Will post my results in the next day or two.

WW
 
Last edited:
“ Personally, I dont think it makes any difference if oscam is started by init.d or by a python console.“ - in terms of speed probably not, I was just trying to find out if implementing the change this way fixed the issues people were seeing and also make it easy to control softcam start/stop from Enigma.

Will be interested in your results
 
A "non standard oscam" adds an extra parameter to the equation.
 
@twol - So to follow up, as expected running oscam using the changes you suggested did not fix MY problem

My situation

OSCAM
Running a mipsel only version on an ET8000, and an arm only version on a GigaBlue UE.
Both report to be oscam-1.20_svn-r11686.
Both reference libcrypto.so.0.9.8, so need a symbolic link to run.

PROBLEM
Noticed a number of weeks ago, that oscam would stop after a while on the mipsel box - could manually restart it straight away.
Lost a few recordings due to this so decided to look into it more.
Added the restart option '-r 2' to the command line.
Added a logfile option in 'oscam.conf' to point to a usb stick, and ran it in max debug mode '-d 65535' to see if it would log why it was stopping.
Neither option were any help.
Noticed in SoftCamManager the stack size was being set at 1024Kb (ulimit -s 1024), so decided to start it manually from the command prompt because both the stack size and open files values were not reduced (8192Kb and 16384).
Again, no change.

What I did discover was that the oscam process stopped after 300 minutes +/- a few.

The other discover was that the oscam process only stopped on the mipsel box - no issues on the arm box!


TESTING
To test consistently I would start a recording for 8hrs or so and check it after 300+ minutes to see if oscam process was still running.

IMAGES TESTED (in order)
Openvix 5.4.009, .010, .012 then back down to .007 as some posts said it still worked
Oscam stopped in all of the above after approx 300 minutes.

OpenATV 6.4 20210522
Worked perfectly with no stopping - tested over long weekend and was able to make a 12hr recording

Openvix 5.3.039
Worked perfectly with no stopping - tested over a week and was able to make an 18hr recording

openvix 5.4.003
Worked perfectly with no stopping - tested over a week and was able to make an 6hour recordings

openvix 5.4.005
Oscam stopped after approx 300 minutes each time.

openvix 5.4.004
Worked perfectly with no stopping - tested over a few days

So based on the above, it looks like the problem was possibly introduced between 5.4.004 and 005!

Unfortunately I have no answers or suggestions, can just document what I found testing.

For anyone who understands the build process, or understands what changed were made during this period - does anything jump out?
Maybe a change in the compile or link parameters, or maybe a new method of doing things was introduced into the code!

WW
 
Thanks for all the testing.
I have looked at all the diferences between 004 & 005 and I can see nothing that directly impacts on softcams or connected services.
However, additional functionality was added which could have have reduced memory availability.
Also the fact that the same softcam runs fine when run from the kernel, but not when initiated by E2 (my change runs at Enigma startup and just starts the softcam like the kernel start), implies that the issues are being caused (in my view) by Enigma swapping. It also explains why non Mips boxes run fine using the same softcam version with their larger memory sizes..
 
A few things I forgot to mention:-
- The softcam frozen check was disabled in all tests
- I created and activated a 64MB swap file in all tests (as far as I can remember, it was never used)

Also when looking at htop output (tree display), for the 10 oscam processes they all looked close enough for the VIRT, RSS & SHR memory usage, also nothing unusual with total memory in use!

@twol - just to be clear, in MY setup, the oscam process will stop after 300 minutes regardless of how it is started on versions 5.4.005 and later.
The 300 minutes has me puzzled because it's quite consistent - it must be reaching some sort of limit!

Anyway, I have a workaround, so it's not too annoying.

Thanks for your input, and keep up the good work.

WW
 
Wish there was a clear answer.... it would help if I had an Oscam setup that involved some serious involvement with a card - but unfortunately my 27.5W config is very simple
 
Twol - I have tried to incorporate the latest SoftcamManager.pyo (from the GIT, 5 days ago) into my 5.4.12 image and it doesn't seem to give the slow ecm channels the boost that was needed -- sorry. No change with my oscam ecm times.
 
Twol - I have tried to incorporate the latest SoftcamManager.pyo (from the GIT, 5 days ago) into my 5.4.12 image and it doesn't seem to give the slow ecm channels the boost that was needed -- sorry. No change with my oscam ecm times.

.. you need the changes in post #166 - I added a mechanism to scriptrunner to run scripts(start & stop) on enigma boot up. - I wamted to see if this fixed the issue. So this test shows whether this is a E2 swap issue or not. Your scripts are run by the. Linux kernel. If you have time I would appreciate you trying the code in the post.
I have now added modified code to my Git as I was experiencing long delays on Oscam initialisation on a boot/reboot
 
.. you need the changes in post #166 - I added a mechanism to scriptrunner to run scripts(start & stop) on enigma boot up. - I wamted to see if this fixed the issue. So this test shows whether this is a E2 swap issue or not. Your scripts are run by the. Linux kernel. If you have time I would appreciate you trying the code in the post.
I have now added modified code to my Git as I was experiencing long delays on Oscam initialisation on a boot/reboot

Okay done... but isn't this using a script similar to mine to just manually start up Oscam from E2 at startup? If I incorporate your softcam startup script into my startup script (which seems to just add pid management) is that the same thing as what you were doing with this new script?
Is that going to help us find a solution to SoftcamManager.pyo or are you looking to replace SoftcamManager.pyo with less memory hungry coding?
 
Yes, the scripts are similar (the pids allow you to stop/start in scriptrunner which I needed for testing) - I am trying to check that the issue lies with swapping of the E2 paging set.
If this change bypassed the softcam issues, it means that there is an alternative for less techie users, especially if I supplied the scripts as part of the softcam build.
Really trying to tie down the issue and see if there are alternatives.
I have a fix for my boot/reboot delay issue, just looking at the broader issue here.
 
So is this issue being left to die?

I have tried everything in the book here - compiled diffferent OScams, gone through the softcam with a fine tooth comb(and provided changes), provided an alternative way of starting - none of it apparently helps for Mips boxes.
Basically the Oscam module works, the softcam does what it should do and the alternative method starts Oscam under the E2 namespace so is impacted by memory swapping - so providing a swap doesn't help.

The only apparent solution is to run the Oscam as a script - which works.

There comes a time when you have to recognise that there will be limitations on older boxes.

If you can advise something different, please do so
 
But didn't someone say that OpenATV Oscam runs fine on Mips boxes? Can't some code simply be copied over and run it the same way OpenATV does? (I do know that it will not be as easy as that sounds).
 

OpenViX Feeds Status

Back
Top