Erik Slagter

Oscam cannot know if a request for an ECM is for recording or offline decoding.

The offline decoding delay is measured in milliseconds, so a value of 10000 would be a good starting point.

I think you have a flaw in your reasoning, you think that the decrypting is done by the softcam. That is not the case.

This is how DVB decryption works:

- provider sends (encrypted) EMM packets to subscriber cards to specify what programs should be decrypted and during which period

- provider scrambles (note the use of this word instead of "encrypts") the streams using a control word (actually 2 of them, but let's keep it simple here)

- provider encrypts the control word and probably adds some metadata to it, into an ECM

- provider sends the ECM frequently, about once a second, that's why it takes some time after zapping before you actually have a picture

- enigma builds and sends a caPMT structure from the PMT to inform the CI and/or softcam of the new service + ECM pid(s)

- with the caPMT the CI can start descrambling the service, enigma doesn't do anything to it, it just instructs the SoC to pass the CI output to the demuxer -> audio/video decoders

- with the caPMT the softcam can start fetching the ECMs, hand them to the subscriber card, the card returns a control word and the control word is sent to the descrambler (in the demuxer); also enigma does nothing here

- both a CI and a descrambler in the demuxer (from SoC) will only descramble packets that have one of the "scrambled" bits active. So that's no problem.

- the problem is that for this to work, the current control word always needs to be in the descrambler, because the softcam can never know which parts of the file are still scrambled and even it would, there would be too much delay having the ECM converted into a control words and setup the descrambler.

So, offline decryption of a file that only has parts still scrambled, will only ever work if all ECMs present in the file are handed to the softcam and resolved into control words.

I believe I explained that earlier on, but apparently not good enough.

Apparently. It seems to be fixed now after some work by WanWizard and me but we're not exactly sure how.

I do like it. Why does the list need to be short? I don't see the need for it to be called with another colour key. Most people aren't using this screen anyway, because they don't understand it anyway.

The final word on FCC. I will not implement it because I have too little information on how it works and should be implemented (properly, not reverse engineered from the VU+ image). When VU+ (or someone else with thorough knowledge on this subject) can inform me, I will implement it.

I think if the hardware supports a certain feature, we should make it available to the end user, whether we like the feature or not.

FYI, hd51 (from Mutant, Ax, whatever) have the bcm7251 SoC, the Gigablue and the VU+Uno(SE) have bcm7252 and the Ultimo4k has bcm7444. That is interesting, because the 7251 is a "budget" SoC, the 7252 is "mainline" and 7244 is "high end". That has implications. There are certain things a 7251 simply can't do, you should consider that.

At least SCART can output component video (RGB), cinch is composite which is even worse (far worse) quality.

Do you mean Lcd4Linux?

I will consider it, but it won't be for the upcoming release, because I always need to some adjustments to get it working in OpenPLi.

I have sent a request for VP9 support on capable machines. Now we wait.

Ok, fair point there. Mostly it works quickest if we supply a patch.

BTW I very much doubt if all of these codecs are actually supported. It looks like ATV just added them all without checking. But we could try to get VP9 added for the UHD models after the solo4k (the solo4k doesn't have VP9 support).

Who is talking about sumo?

Sumo is already an old branch from the OE core.

So apparently you did.
 

I'm talking about pyro and the develop branch!
That can not be so difficult to understand, right?

Your words...
 

No matter ...
I am out

Yeah, good plan, go waste someone else's time with your nonsense and hostility.

For me this should be escalated to the driver manufacturer and they should fix it at the driver level (too). Because from what I read here it is supposed to work as ethernet (CSMA-CD) and this should be done at the driver level, since higher you cannot detect collisions.

No it's not (completely) supposed to work like this. Ethernet has always a at least one layer above it for error detection and correction. The collision detection is only there to prevent a situation where packets get sent over and over again unnecessarily.

DiSEqC has, for each version, a counterpart that enables two-way communication (e.g. 2.0 from 1.0, 2.1 from 1.1 etc.). Most devices do actually implement the two-way communication, but enigma2 doesn't use it at all. I am afraid it's a vicious circle; DMM never bothered to implement it's functionality in enigma2, so other vendors didn't bother to add this functionality (probably...) in their drivers. May be the hardware isn't even capable.

Anyway, SCR is not the same as DiSeqC, it only uses most of it's signalling. The good news is that at least JESS (but probably Unicable as well) support inherently two-way communication, but in a different way than DiSEqC. AFAIK there is a command to query the currently assigned user bands, so I guess that's what one should use to check communications. But here also counts the same as for DiSEqC, probably the drivers or even hardware don't support actually reading DiSEqC. Even if only vendor doesn't support it, there would be a problem.

So enigma defaults to the "second best practice", where one sends the command, checks for LOCK and if it doesn't come, try again a few times until time out. It's not beautiful but it is very robust. As said the retransmission of the SEC commands take place a higher level than the SCR handling, so we shouldn't be modifiying code there (SCR). If not already there, I think we should modify the retry pattern into an exponentional backoff one, as described earlier. We could add to the pattern a random fragment, which would make the pattern even more efficient.

My OK button resumes playing as well. It configured it that way because when your fast-forwarding (with picture, which I rarely do), if you see the point you're looking for, you need to react quickly, or it's far beyond that point. In my experience it's way faster to grab the OK button than have to search for the play button.

So, littlesat, stop saying it's not necessary. Let's establish it IS valuable to have. Then who is going to implement it, is another discussion.

Brrrrr, daar krijg je spijt van. Gewoon embedden in de mkv.

Well, I have found how a channel bitrate is improved and will become more efficient. The new DVB-S2X will be useful to make an efficient use of the whole bandwidth of a satelite. 

 

https://en.wikipedia.org/wiki/DVB-S2X

 

spanish wiki seems to have wider information (you can translate)

 

https://es.wikipedia.org/wiki/DVB-S2X

 

greetings,

DVB-S2x will improve bandwidth mostly only marginally. The main way to go is to switch to HEVC and/or use better encoders.

Wat bedoel je met "de laatste 20 regels van de dmesg output " ?

De trace die ik heb gegeven was de volledige output (niet in geknipt of zo)

- inloggen

- type "dmesg"

- laatste twintig regels copy & paste

My NAS can do 60 Mbps and I never see interruptions in recordings. I think my top (real life) use is about eight tuners. I am not doing any business stuff with it, so I am not really that interested, if it works for myself, I am ok with it.