Trouble descrambling channel since certain commit.

[rbrouwer]

My Digital Devices Max A8i with Octopus Duo CI has trouble streaming scrambled channels since commit: ba0f41d.

It works fine with c2fee8c and with ba0f41d if channels that do not require the CAM.

[catalinii]

can u upload a log ?
./minisatip -f -l http

[rbrouwer]

Wanting to provide a good log and a bad log, I noticed I could not get that to work on the mentioned commit, so had to revisit many commits to see what works. I also tested without Emby in-between (It magically was hiding stuff by playing good buffer). VLC + TVHeadend shows me what Emby was hiding.

• faf4a68 works with public and scrambled channels without any lagging.
• bd512c8 public and scrambled channels do tune but lag.
• b476d53 public and scrambled channels do tune but lag.
• 60b4bf8 public and scrambled channels do tune but lag.
• 160cda3 public and scrambled channels do tune but lag.
• 33ef979 public and scrambled channels do tune but lag.
• 019d667 public and scrambled channels do tune but lag.
• dd0bdda public and scrambled channels do tune but lag.
• c25240b public and scrambled channels do tune but lag.
• 1d68d26 public and scrambled channels do tune but lag. A lot less though.
• 0034196 public and scrambled channels do tune but lag. Same as prev.
• cea642f public and scrambled channels do tune but lag.
• c2fee8c public and scrambled channels do tune but lag.
• ba0f41d public and scrambled channels do tune but lag.
• e63c7bd public and scrambled channels do tune but lag.
• 614403c public and scrambled channels do tune but lag.
• e505a96 public and scrambled channels do tune but lag.

What I mean with lag is that it sends a whole bunch of stream and then nothing for a bit and then again a whole bunch. I'm guessing Emby is acting as a large buffer and therefore can make sense of the stream and then send it along properly, which made me not really notice it. As long as it was within limits that Emby could handle, it would still work. Descrambling always takes a bit to start, which caused that to be outside of what Emby would handle. That probably got me to my previous conclusions. Sorry for that.

Anyway: Hereby a log from faf4a68 in minisatip_good.log
and e505a96 in minisatip_bad.log

It also means I'm probably somewhat identical to #1309 . Should I maybe close this issue and join in there?

[Jalle19]

Yeah, it's the same underlying issue

[rbrouwer]

I guess the best advise I can give is, see what happens when running minisatip on just 1 core. If i run e505a96 with 1 core (minisatip doesn't use much CPU, so why not?) it lags massively and all the time. If I run with that same version with 2 cores, it actually seems to work much better.

[rbrouwer]

I will re-test with 856996b and report back (next week). Good thing it provides additional logging, so in case it were to lag, I have logs.