[mythtv] Ticket #9726: Unicable / Satellite Channel Router / DIN EN 50494
Warpme
warpme at o2.pl
Sun Apr 7 10:58:01 UTC 2013
>was thinking about how testing works for users and came to the
>conclusion that it might be easiest to get the "final" database changes
>in first as its hard to have multiple parallel developments in that
>area and the plain schema changes have a low risk of breaking stuff.
>
>So if you come up with a "final" schema change we could add that sooner
>rather than later.
>
>Regards,
>Karl
Karl,
Final schema depends how complete unicable implementation we want to have.
I think current one (#9726 + all patches) seems to be complete with
following assumptions/exceptions:
1.Only single SCR bus is supported.
2.Disecq resend/repeat selection is done via repeat value bands.
Ad1: If setup will have more than one SCR bus - then (as far as I
remember) only last bus reset will be correct (for details pls look on
http://code.mythtv.org/trac/ticket/9726#comment:18). If we want to
implement unicable support for more that 1 concurrent unicable bus then
I think disecq code changes will be quite significant. I think if dev
decide to implement this level unicable support - then it is worth to
consider whole disecq code refactoring as code changes will be probably
comparable with refactoring changes.
Ad2: this potentially require additional field in disecq tree - but I
consider such addition as purely code elegance move. With current value
bands, functionally we can achieve is exactly the same - but this
approach is not elegant nor following myth code standards. Also UI
support with this approach will be little more complicated...
So Q is about trade-off: code elegance - effort to add functionality
I personally think current code (being prof of concept) changes are
worth to add to main tree with status "experimental feature". This will
allow wider testing of feature. When we gather feedback & iron last bugs
then I think devs will have enough knowledge/experience/test user base
to refactor code for elegant unicable implementation. It will IMHO allow
unicable refactor code in one hop without turbulences for users....
BTW: I use current code during last 6 months without (IIRC) single issue
related to unicable subsystem.
On 4 DVB-S2 tuners I already record approx 4900 recordings so stability
it is pretty good for me.
br
-------------- next part --------------
A non-text attachment was scrubbed...
Name: warpme.vcf
Type: text/x-vcard
Size: 83 bytes
Desc: not available
URL: <http://www.mythtv.org/pipermail/mythtv-dev/attachments/20130407/6ff93c7d/attachment.vcf>
More information about the mythtv-dev
mailing list