186 replies to this topic

[Erik Slagter]

Thx blzr.

[Huevos]

briefly tested on et9500 / vuzero which share same unicable(1) installation - definitely did not look good,

when e.g. set recording on tuner A (scr1), zapping to any other service (tuner B scr2) took over 5 seconds, then sometimes picture froze after few seconds, or couldn't get picture at all

 

switched back to master enigma for now...

 

will try to test more in the afternoon (when I'm back from ice rink )

How have you got the tuners configured? I've tried Unicable 1 on Solo 4K and Solo2 at the same time and it works fine.

[Huevos]

Also, tested 2x Solo4K STBs side by side.
Receiver one, Tuner A, C, D, E, F, G & H one feed from splitter. Tuner B not configured.
Receiver two, Tuner A, C, D, E, F, G & H one feed from splitter. Tuner B not configured.
SCR1, 2, 3, 4, 5, 6 and 7 receiver 1 and SCR8, 9, 10, 11, 12, 13 & 14 on receiver 2
Able to record 7 services from each (14 total) with no interference whatsoever.

[Huevos]

Can I suggest to BLZR to please clear settings file and configure tuners from scratch.

[blzr]

ok, further testing:

updated e2 again, reconfigured tuners from scratch: et9500 A scr1, B scr2, vuzero scr3)

in general everything seems to be ok - no freezes. lock problems (as described above),

but,

zapping is significantly slower (e.g. on et9500 when recording using tuner A, and zapping using B )

to make 100% sure, again switched back to master e2 -- it's definitely much faster...

 

does this unicable2/jess patch also includes mentioned above 'fix timing problems with sendDiseqc and nonblocking ioctl' patch?

that might be the culprit...

 

 

 

 

[athoik]

Hi Huevos,

The following part of code is JESS related code or JESS/VU+ FBC code?

I see lot of getTop functions that remind me FBC look alike code.

-			frontend.setSecSequence(sec_sequence);
+//get top tuner
+			if(((eDVBFrontend *)&frontend)->has_prev())
+			{
+				eDVBFrontend *fe = (eDVBFrontend *)&frontend;
+				fe->getTop(frontend, fe);
 
+				int state;
+				fe->getState(state);
+				if (state != eDVBFrontend::stateClosed)
+				{
+					eSecCommandList sec_takeover_sequence;
+					sec_takeover_sequence.push_front(eSecCommand(eSecCommand::TAKEOVER, (long)&frontend));
+					fe->setSecSequence(sec_takeover_sequence, (eDVBFrontend *)&frontend);
+					eDebugNoSimulate("takeover_sec %d",fe->getDVBID());
+
+					sec_sequence.push_front( eSecCommand(eSecCommand::WAIT_TAKEOVER) );
+					sec_sequence.push_back( eSecCommand(eSecCommand::RELEASE_TAKEOVER, (long)&frontend) );
+					eDebugNoSimulate("waittakeover_sec %d",frontend.getDVBID());
+				}
+			}
+			frontend.setSecSequence(sec_sequence);

[athoik]

Also regarding the style of the code...

This:
 

advanced_lnb_satcr_user_choicesEN50607 = [("1", "SatCR 1"), ("2", "SatCR 2"), ("3", "SatCR 3"), ("4", "SatCR 4"), ("5", "SatCR 5"), ("6", "SatCR 6"), ("7", "SatCR 7"), ("8", "SatCR 8"),
							   ("9", "SatCR 9"), ("10", "SatCR 10"), ("11", "SatCR 11"), ("12", "SatCR 12"), ("13", "SatCR 13"), ("14", "SatCR 14"), ("15", "SatCR 15"), ("16", "SatCR 16"),
							   ("17", "SatCR 17"), ("18", "SatCR 18"), ("19", "SatCR 19"), ("20", "SatCR 20"), ("21", "SatCR 21"), ("22", "SatCR 22"), ("23", "SatCR 23"), ("24", "SatCR 24"),
							   ("25", "SatCR 25"), ("26", "SatCR 26"), ("27", "SatCR 27"), ("28", "SatCR 28"), ("29", "SatCR 29"), ("30", "SatCR 30"), ("31", "SatCR 31"), ("32", "SatCR 32")] 

Can be done like this:
 

>>> [("%d" % i, "SatCR %d" % i) for i in range(1,4)]
[('1', 'SatCR 1'), ('2', 'SatCR 2'), ('3', 'SatCR 3')]

advanced_lnb_satcr_user_choicesEN50607 = [("%d" % i, "SatCR %d" % i) for i in range(1,33)]

Also this is not good:
 

+				lof=[]
+				lof_append = lof.append
+				lof_append(int(product.get("lofl",9750)))
+				lof_append(int(product.get("lofh",10600)))
+				lof_append(int(product.get("threshold",11700)))
+				positions_append(tuple(lof))

I prefer lof.append, it's more clear.

Edited by athoik, 6 March 2016 - 17:14.

[Huevos]

@Athoik, I didn't write this. I just ported to OpenPLi for a clean merge. When we look at other people's code we can always find things we would have done differently.

Right now though the work is 99% done. Before this we were at zero.

 

@blzr, zap timing is a pretty subjective. Possibly more noticeable on a 405MHz receiver when compared to a modern STB. I did the same patch for OpenViX yesterday and have that running currently on my receiver. I've made a video of that so everyone can make their own mind up about zap speed. For me it seems identical to before I added the patch.

 

Video here: http://extra.satelli...xml.org/test.ts (85MB).

 

Also, here is the commit history from when I started grouping the commits the patch was made from.

https://github.com/H...ts/JESS-commits

[athoik]

I see this commit add all the "FBC" like handling:

[unicable] improved tuner handling     
- Simple check if lnb has executed diseqc cmd     
- If tuners in mode "connected to" (recommended), then only the last tuner in the chain is responsible to send diseqc commands. This is to avoid

https://github.com/H...bdd5a5330d614cf

[blzr]

@blzr, zap timing is a pretty subjective. Possibly more noticeable on a 405MHz receiver when compared to a modern STB. I did the same patch for OpenViX yesterday and have that running currently on my receiver. I've made a video of that so everyone can make their own mind up about zap speed. For me it seems identical to before I added the patch.

 

note that I tested on same equipment/configuration, the only difference was the code
(and not sure CPU speed has anything to do in this case...)

also made some (crappy) videos of zapping through same set of services, to show that's rather not a 'subjective impression', you can see a noticeable difference (new_code.avi is e2 with your last unicable patch)

but, in the end, zapping is not a race so, I definitely do not suggest, this should be a showstopper, in a no way...

//nevertheless, I believe it'd be better if all additional unicable 'fixes/workarounds/driver hacks' and actual unicable2/jess implementation were split to separate patches (and yes, I know, easier said than done )

Attached Files

•  zap_tests.zip   6.3MB   10 downloads

[Huevos]

@blzr, judging by old_code.avi that is an extremely slow zapping setup. I've never seen a setup that zaps as slow as that. Is this normal for an ET9x00?

[Dimitrij]

Huevos

I am interested in this technology.

Which is better to buy unicable LNB?

 

https://veicis.lv/?n...1103&pid=751330

http://intersat.lv/?...udl42-uni2l-1pp

or...

Edited by Dimitrij, 7 March 2016 - 11:06.

[blzr]

@blzr, judging by old_code.avi that is an extremely slow zapping setup.

and what would you say on a 'new_code.avi' zapping speed then?

I've never seen a setup that zaps as slow as that. Is this normal for an ET9x00?

I don't know, it is as it is, in 'normal' use it does not look that bad - that was sort of a 'zapping stress test'
note 1. in my tests each subsequent service was from different transponder than previous one (and different quadrant mostly, for that matter...)
note 2. please do not compare auite ancient box to state of the art solo4K

[Huevos]

@Dimitrij, those are just Unicable 1 devices. Here I am testing with one of these.

https://www.hm-sat-s...teilnehmer?c=83

 

@bzlr, both the Vu Zero, and some of the ET's had driver issues, and needed additional safe time (about 100ms). The debug output would show this.

[blzr]

yes, I'm aware of this, I use satellite equipment control plugin, with two values adjusted:
delay_after_change_voltage_before_switch_command=75
delay_after_last_diseqc_command=100

and it's much faster than new code with embedded delays

[Huevos]

And what if you adjust satellite equipment control plugin to match the new code?

 

I don't really think using an antique STB with broken drivers is the best test.

[blzr]

And what if you adjust satellite equipment control plugin to match the new code?

 
well I was under the assumption that embedding delays in unicable code allows to get rid of manual adjustments using satellite equipment control plugin /?/
 

I don't really think using an antique STB with broken drivers is the best test.

actually I agree with this, that's why I wrote:

but, in the end, zapping is not a race so, I definitely do not suggest, this should be a showstopper, in a no way...

OTOH, using the fastest machine in the market for testing - one could argue it's not most reliable test either...

[Rob van der Does]

 I've never seen a setup that zaps as slow as that. Is this normal for an ET9x00?

Normally the 9k zaps just as fast as any other box, even compared with the modern 'fast' boxes.

[Huevos]

Rob, have you watched his old_code.avi file of the box zapping when connected to a Unicable 1 LNB? Would you consider that "normal"?

[Rob van der Does]

I can only say that my 9k has always zapped just as fast as any other box; regardless of the image used.