Im just installed latest version, and all work as before. I did not change new SoftCam.key
with hashes for Discovery and AFN package. When coming new keys for these packages
we will see how it works.
Im just installed latest version, and all work as before. I did not change new SoftCam.key
with hashes for Discovery and AFN package. When coming new keys for these packages
we will see how it works.
The plan was the old method to work like before. The new method depends on enigma namespace which is not available on all devices.
what about 2 frequency same hash and EMM key not same
2 frequencies with same hash??? This is not possible. Which are they?
what about 2 frequency same hash and EMM key not same
2 frequencies with same hash??? This is not possible. Which are they?
yes its possible.
- channel Animal Planet Japan/APL Japan (4080/V/30000) and channel Liga (4180/H/30000) Satellite Intelsat 19 at 166 E have a same hash.
- when open channel APL Japan autoroll work follow Channel Liga EMM Key because Channel Liga have same hash and Channel Liga EMM Key Lastest in SoftCam.Key list
- Channel Animal Planet Taiwan (3760/V/30000) and channel Animal Planet Southeast Asia (4040/V/30000) Satellite Intelsat 19 at 166 E have a same hash.
- Sorry for my bad english
i'm use wetek play 2 Libreelec official version 9.0.1 arch tecture wetek_play_2.arm
And do you have the same ecm keys for 2 hash or not?
check my last post
- i found 2 frequency have a same hash (Sattelite Intelsat 19 at 166E) and 2 frequency have a different EMM key
- autoroll work follow last hash EMM key in SoftCam.Key list.
Quote from enigma1969it is only available for enigma2 and Tvheadend/VDR software for PC.
this method is only for enigma namespace ..not for stapi ,gxapi, android etc...
And my question before going entirely crazy. How does this method effect finding keys with pvhe?
Are there any other ways to discover them? Most posted here on updates are for European sats.
It is not working for me. I am using TVheadend on libreelec k1Pro. I had it working before, a few days ago it stopped working. I replaced the old oscam binary file and the softcam.key file with yours. Usually it would take 5 mins to key find the keys, but now i have it running for hours and still no key are being found.
Do i have to make any changes into oscam configs?
This softcam.key is only for enigma box
And not for modified software ...
Better use old softcam.key format
Okay, thank you. Works fine with old softcam.key.
Ok
Please read first github wiki oscam-emu
For new method
And my question before going entirely crazy. How does this method effect finding keys with pvhe?
Are there any other ways to discover them? Most posted here on updates are for European sats.
it is not only this method, old method is doing the same job. of course i don't know if all providers are supported (we are talking for powervu) ,
you need the emm keys, a few settings in oscam config, and...
you can do a little search about powervu autoroll/autoupdate for more...
For me it is just a cleaner more organised file, the end result is the same.
Peeps really should read the wiki
The traditional method of getting ECM keys is based on matching the srvid of the channel only. This means the ECM algorithm does not match the group id at all when searching for the ECM key. If many ECM keys with the same srvid (see Note 1 below) are present in the SoftCam.Key, they are all tried until the correct one is found.
In addition, the EMM algorithm does not match the group id as well. The EMM keys used for auto updating can be chosen from various groups (see Note 3) and as a result wrong EMM keys can be used.
The new approach is to utilize the group id of the channel when the ECM and EMM algorithms run. In order OSCam-Emu to know what is the correct group id to use, it calculates a hash based on tsid, onid and enigma namespace of the transponder. The user then needs to enter a new line in the SoftCam.key telling OSCam-Emu which group id to use for each transponder (hash).
The syntax for this line is the following:
Where:
hash (4 bytes) : Transponder hash calculated automatically by OSCam-Emu. Use debug level 2 to display it.
groupid (2 bytes) : The group id that is used for the ECM and EMM keys.
Example:
P BF175115 GROUP 0080 ; 12303 V, 0.8°W
P ACE05CA0 GROUP 0080 ; 12360 V, 4.8°E
P 9798A8F2 GROUP 0900 ; 11804 V, 9.0°E
Transponders using the same ECM and EMM keys should use the same group (this should be the case for the traditional method as well) and thus multiple "GROUP" entries should exist for that group id.
After adding the GROUP instruction for a group, the next step is to remove all ECM keys for that group and enter a new one with the dummy srvid 0xFFFF. For example:
The EMM keys should remain untouched. After restarting the Emu reader, the new method should take over for both the ECM algorithm and the EMM (AU) aglorithm.
The advantages of this new method are many:
On the other hand there is a couple of drawbacks:
For channels with the same service id, the correct ECM key will be detected automatically, but each key needs a unique groupid. If you need different ECM keys for channels with the same service id, make sure they belong to different groups, like in the example:
Duplicate keys (same groupid and same srvid) are not allowed. If there are any duplicates, only the last one in the SoftCam.Key file will be used. This also means that as new ECM keys are found and appended to the file, they will automatically replace earlier keys.
In order the auto update feature to work, the ECM keys must be seeded. This is done by entering a dummy ECM key and a corresponding (i.e. with the same group id) EMM key, for example:
When you tune into the channel with the service id '0004', the auto update function will run. After a while, a new ECM key will be written at the bottom of the SoftCam.Key file. This new ECM key will be used instead of the dummy one when opening the channel. For each service id, a dummy ECM key has to be added. Each EMM key will update all ECM keys in the same group.
Multiple EMM keys are allowed for each group, but there is a maximum number of 32 EMM keysthat will be used when auto updating. When the auto update function runs, the algorithm does not match the group id. This means that these 32 EMM keys are chosen among all groups that have an ECM key with the current channel's service id, and not necessarily from the 'correct' group. The effective number of EMM keys for auto updating is thus 32 per service id (channel). This design has two side effects:
For best results, it is recommended to have no more than 10 EMM keys in each group, especially if you have many groups in your SoftCam.Key file, and make sure there are no EMM keys with the same UA belonging to different groups.
When using the new method for matching ECM and EMM keys based on transponder, all considerations described above are gone. Only limitation is the maximum number of EMM keys that can be used per group are 32.
Configuring DVB-Api (on compatible devices)
Some receivers support PowerVu through direct DVB-Api decryption. If your device supports it, configure OSCam-Emu as follows:
or by editing the oscam.conf file:
or by editing the oscam.conf file:
please new method au config files
Display Morewhat about 2 frequency same hash and EMM key not same
2 frequencies with same hash??? This is not possible. Which are they?
yes its possible.
- channel Animal Planet Japan/APL Japan (4080/V/30000) and channel Liga (4180/H/30000) Satellite Intelsat 19 at 166 E have a same hash.
- when open channel APL Japan autoroll work follow Channel Liga EMM Key because Channel Liga have same hash and Channel Liga EMM Key Lastest in SoftCam.Key list
- Channel Animal Planet Taiwan (3760/V/30000) and channel Animal Planet Southeast Asia (4040/V/30000) Satellite Intelsat 19 at 166 E have a same hash.
- Sorry for my bad english
i'm use wetek play 2 Libreelec official version 9.0.1 arch tecture wetek_play_2.arm
I think you already got your answer. Most probably, in wetek namespace is not available...
how about mtn 57east fix
I have tried the new method with mtn key are found but black screen we need unmaskin
Oscam emu all imagen , in vuzero, how vti 14, no work, please help my.
Thanks
Display MoreFor me it is just a cleaner more organised file, the end result is the same.
Peeps really should read the wiki
Matching ECM and EMM keys based on transponder (new method - May 2019)
The traditional method of getting ECM keys is based on matching the srvid of the channel only. This means the ECM algorithm does not match the group id at all when searching for the ECM key. If many ECM keys with the same srvid (see Note 1 below) are present in the SoftCam.Key, they are all tried until the correct one is found.
In addition, the EMM algorithm does not match the group id as well. The EMM keys used for auto updating can be chosen from various groups (see Note 3) and as a result wrong EMM keys can be used.
The new approach is to utilize the group id of the channel when the ECM and EMM algorithms run. In order OSCam-Emu to know what is the correct group id to use, it calculates a hash based on tsid, onid and enigma namespace of the transponder. The user then needs to enter a new line in the SoftCam.key telling OSCam-Emu which group id to use for each transponder (hash).
The syntax for this line is the following:
Where:
Codehash (4 bytes) : Transponder hash calculated automatically by OSCam-Emu. Use debug level 2 to display it. groupid (2 bytes) : The group id that is used for the ECM and EMM keys.
Example:
CodeP BF175115 GROUP 0080 ; 12303 V, 0.8°W P ACE05CA0 GROUP 0080 ; 12360 V, 4.8°E P 9798A8F2 GROUP 0900 ; 11804 V, 9.0°E
Transponders using the same ECM and EMM keys should use the same group (this should be the case for the traditional method as well) and thus multiple "GROUP" entries should exist for that group id.
After adding the GROUP instruction for a group, the next step is to remove all ECM keys for that group and enter a new one with the dummy srvid 0xFFFF. For example:
The EMM keys should remain untouched. After restarting the Emu reader, the new method should take over for both the ECM algorithm and the EMM (AU) aglorithm.
The advantages of this new method are many:
- One ECM key is used for all channels in a transponder, so the SoftCam.Key has smaller size and it's easier to maintain and update.
- Memory consumption is lower and getting the correct key is faster.
- All problems described in Note 3 are disappeared, which makes creating a proper, trouble-free SoftCam.Key easier for all.
On the other hand there is a couple of drawbacks:
- The application of this new method is limited to STBs utilizing the enigma namespace, like enigma2 and TVheadend, VDR, etc.
- It cannot be used in the stream relay, because non of the tsid, onid, and enigma namespace are available.
For channels with the same service id, the correct ECM key will be detected automatically, but each key needs a unique groupid. If you need different ECM keys for channels with the same service id, make sure they belong to different groups, like in the example:
Duplicate keys (same groupid and same srvid) are not allowed. If there are any duplicates, only the last one in the SoftCam.Key file will be used. This also means that as new ECM keys are found and appended to the file, they will automatically replace earlier keys.
In order the auto update feature to work, the ECM keys must be seeded. This is done by entering a dummy ECM key and a corresponding (i.e. with the same group id) EMM key, for example:
When you tune into the channel with the service id '0004', the auto update function will run. After a while, a new ECM key will be written at the bottom of the SoftCam.Key file. This new ECM key will be used instead of the dummy one when opening the channel. For each service id, a dummy ECM key has to be added. Each EMM key will update all ECM keys in the same group.
Multiple EMM keys are allowed for each group, but there is a maximum number of 32 EMM keysthat will be used when auto updating. When the auto update function runs, the algorithm does not match the group id. This means that these 32 EMM keys are chosen among all groups that have an ECM key with the current channel's service id, and not necessarily from the 'correct' group. The effective number of EMM keys for auto updating is thus 32 per service id (channel). This design has two side effects:
- If there are many EMM keys for each group, there is a chance all 32 EMM keys are chosen from the 'wrong' group. Then the auto update function will never update the ECM keys.
- Since no group id is matched, there is a chance the newly found ECM keys to be written to the 'wrong' group.
For best results, it is recommended to have no more than 10 EMM keys in each group, especially if you have many groups in your SoftCam.Key file, and make sure there are no EMM keys with the same UA belonging to different groups.
When using the new method for matching ECM and EMM keys based on transponder, all considerations described above are gone. Only limitation is the maximum number of EMM keys that can be used per group are 32.
Configuring DVB-Api (on compatible devices)
Some receivers support PowerVu through direct DVB-Api decryption. If your device supports it, configure OSCam-Emu as follows:
- Disable Stream Relay (on by default) through the WebIf:
or by editing the oscam.conf file:
- Select the correct extended CW API:
or by editing the oscam.conf file:
....but it takes twice the time to find the keys, vs old method. So, what is the advantage of cleaner key file over longer time ?
not for me, i used to take 10 to 15 mins to find a key from emm. Now it is 10 seconds to a max of 1 minute
Both the above messages are not accurate.
What is changed with the new vs the old method is what emm keys are "selected" when auto updating. Nothing more.
OSCam-Emu has no way to influence when the provider will send the emm packets. It can only select/choose what emm packets will listen to.
If one or the other method produces better of worse results for you, it just means that your key configuration in your softcam.key was/is not optimal.
The only advantage of the new method regrading auto updating is that it is easier for the non expert user to "assemble" a proper softcam.key, without collisions, especially if there are many channel groups inside.
Don’t have an account yet? Register yourself now and be a part of our community!