[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