On Wednesday 03 August 2016 12:07:55 Piotr Oniszczuk wrote: > Just user perspective:
> IIRC this change is related to move from cardid/inputid to flat inputid.
> gigem implemented this and results are very positive in my case. This
> results with huge (I believe) speed-up & clean-up code.
> I see this in LiveTV: channel change is now faster&reliable than ever and
> in many cases faster that channel change in commercial STB's.
> All cardid/inputid to flat inputid are needed (I believe) to implement
> group scheduling. Results are in my case like this:
> For me above improvement (cyclic; seen by user) is worth additional
> learning curve in setup area (one time; seen by administrator).
I have big difficulties in believing that the (over)simplification
of the input structure have an influence on channel change speed.
An extra pointer jump only takes some microseconds for
the CPU... So if that was the case something else was
The result at the moment is that multi LNB setups
are described by multiple instances of the same adapter.
This was not allowed in the original design and has
thus created big issues in other parts of the code.
At the moment the multi LNB doesn't work in master...
I still am of the opinion that the program and the setup should
describe the real life physical structure. Otherwise there
will be constant problems and special cases popping up. Like now.
Group scheduling is fine, but I am sure that could have been
implemented with a more reasonable structure - If it would have
been given enough thought before things got ripped out. And with
a big enough sample of _different_ users to test on.
And about the learning curve: Where is the instructions/documentation
for the new setup? Specifically for multi LNB:s.
BTW. This is a mailing list. I don't think we should top-post.
mythtv-dev mailing list
firstname.lastname@example.org http://lists.mythtv.org/mailman/listinfo/mythtv-dev http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org