@paulh
paulh wrote: ↑Wed Feb 01, 2017 10:56 pm
OK I have both your VBOX multi record patch and another patch to store the protocol in the DB so we don't have to keep doing the test downloads in my fork. Just need to test it when the BE isn't busy.
Paul,
I know its been a while, your original changes to store protocol in DB no longer apply to Master (DB has version bump since changes were created)
I have created an updated patch set which stores the protocol in the DB and works with current Master (as of 20180701) and bumps db version to 1349 (from 1348)
When tested it all works. However VBOX's are scanned during DB Upgrade which takes a long time depending on how many VBox units and their configuration. See Test Results below.
I modified the DB upgrade to directly write the protocol (http_ts) value 16 to the iptv_channel table, this is much,much faster than scanning which uses mythsingledownload (also has benefit the Vbox does not have to be online). I did not want to change anything else (as this all worked when adding a new Vbox).
My test system was configured with 2 VBoxes (3340 1x DVB-S, 1 x DVB-S2, 2 x DVB-T, 3442 2 x DVB-T/T2) both running 2.59 firmware and a total of 4 Videosources. Multirec was set to 5 for all Input Connections.
This configuration has 1140 rows in iptv_channel table.
The existing SELECT statement produced 6910 rows for upgrade, whilst this has a lot of redundancy it works but the upgrade takes around 5 times longer than it might.
.
select.prepare("SELECT iptv_channel.chanid, url, capturecard.cardtype "
"FROM iptv_channel LEFT JOIN channel ON iptv_channel.chanid = channel.chanid "
"LEFT JOIN capturecard ON channel.sourceid = capturecard.sourceid");
I think a DISTINCT clause is needed, so it becomes
select.prepare("SELECT DISTINCT iptv_channel.chanid, url, capturecard.cardtype "
"FROM iptv_channel LEFT JOIN channel ON iptv_channel.chanid = channel.chanid "
"LEFT JOIN capturecard ON channel.sourceid = capturecard.sourceid");
Test Results:
Note all timings are from a PC (Intel core i7) with mysql installed to SSD, patches applied to mythtv master at 36a1ff5a6f Fix a couple more EIT issues.
Test 1:
timings - original method using iptv-protocol-changes-paul-h.patch
start 2018-07-02 13:03:16.367316
finish 2018-07-02 13:24:37.934393
Time taken approx 21 minutes, this will probably cause Users concern - thinking nothing is happening
log file: mythtv-setup.20180702120303.17275-orignal-paul-h-patch-updated.log
Test 2
timings - modified method direct update to database using iptv-protocol-changes-paul-h2.patch
start 2018-07-02 13:43:48.326406
finish 2018-07-02 13:43:59.962864
Time taken approx 11 seconds
log file : mythtv-setup.20180701152944.23124-upgrade-with-patch-paul-h2.log
Test 3
timings - modified method with SELECT DISTINCT direct update to database using iptv-protocol-changes-paul-h3-select-distinct.patch
start 2018-07-02 14:04:58.426508
finish 2018-07-02 14:05:00.352316
Time taken approx 2 seconds
log file : mythtv-setup.20180702130451.29049-upgrade-with-patch-paul-h3.log
Also mythbackend.log showing startup upgrade mythbackend-upgrade-with-patch-paul-h3.log
start Jul 2 17:37:53
finish Jul 2 17:37:54
Time taken approx 1 second (note time resolution in log is only to the second.
All the patches are attached in zip format
Assuming I am correct about using SELECT DISTINCT, and you want to use add the protocol change to Master I would recommend using iptv-protocol-changes-paul-h3-select-distinct.patch
I do have mythtv-setup and mythbackend.log files (too big to attach in this forum even when zipped) let me know and I will put them in a Dropbox
Mike