PowerVU AFN only works when cacheex is on #9
Comments
gi 8120 Taapat-based Openpli5-image with Joeuser hardware-des-drivers-powervu |
Just FYI for a complete situation: I would be nice to have OSCAM-EMU not require the CachEx workaround. VU+ Zero and DM720HD STBs OpenPli 6 & 4 respectively with OSCAM R11392-R764 on AFN 9E Both require CacheEx to be set in oscam.server for Emulator to:
|
From my experience only Probably this is not an Emu's problem, but OSCam's problem. |
Probably this is not an Emu's problem, but OSCam's problem.I thought it was a timing issue with PowerVu and that it could be corrected in the EMU. If I am wrong, has anyone (who understands the issue) asked to have it fixed in OSCAM? |
I don't think there's anyone that understands the issue. If there was, it would have been fixed. At least from our side. Do you know how cacheex works? There's no information about it (and many other parts of oscam), so I can't tell what is being done different, when activated, that makes afn work. And I won't read the whole oscam code to find out... |
Maybe the approach should be to take CachEx out of the process and see what the underlying issue is that does not allow the channels to clear and then decide if it can be fixed in EMU or OSCAM without the CachEx workaround. Just a thought. Wishing all a Merry Christmas. |
Well, Emu is an oscam reader. It is sent an ecm request and its job is to respond with a cw, if possible. In the case of afn, the cw is found and sent back to oscam. Oscam has to take the cw and sent it to the box to clear the channel. It's been many times that we had to do modifications to the oscam's dvbapi part for powervu to work properly. Maybe this is the case here as well. I am not very familiar with the internals of powervu or dvbapi though. Other users have contributed many fixes over time. I am sure if anyone of them knew what's wrong, we would have a fix already. Merry Christmas to all! |
Thanks for the explanation. Maybe someone with the detailed understanding of dvbapi will take this on. |
FWIW, the cacheex doesn't actually do anything to help afn work. Cacheex is just cached cw exchanging between many oscam servers. Oscam caches all answered ecm requests in a local cache. And cacheex (cache exchange) is just a way to share all these ecm<->cw "pairs" among oscam servers. Nothing related to our case. Also, the cacheex feature actually has to be enabled on the user side to work. Why it works if we add In this case the oscam's local cache is used for the 1st ecm request (remember we zap very quickly, so the ecm is already decrypted and the cw is stored in the cache). For the next ecm requests the cache is not used, so we get a black screen. So to summarize, if the ecm request is served from the cache, then afn works. If the ecm request is served directly from the emu reader, then afn doesn't work. |
This seems not emu related problem. OpenPLi on Spark works just fine without cacheex = 1. It could be the driver on the enigma2 image itself. |
Thanks for the feedback. |
Sorry, never looked at this before. To update, with my image, it is true that it works without cacheex for the simple case of viewing a channel, but if you try to record one channel and view another, usually you will get no video, only audio on the second channel. But, the cacheex trick works to fix this and does not affect the simple case of viewing just a single channel. It is on my todo list to investigate (as I also need cacheex enabled for tvheadend) but I never seem to have the time... |
We now need more than just cachex as AFN changes something in the code... |
AFN uses Hashmode 15 now, the EMM updates are still CacheMode 10 though. Does somebody have an algo or table for hashmode 15? ;-) |
After almot a year I think it's time to close it. Fixed commit oscam-emu/oscam-patched@654a5e0 in Emu r780. |
I suggest the title says enough...
The text was updated successfully, but these errors were encountered: