I can test on 0.28/Fixes and master backends with an XTI 3340 (1x DVB-S,1x DVB-S2, 2x DVB-T).
I can also run more limited tests using XTI 3442 (2 x DVB-T.T2). I say limited because it is in use on my production system (master), although I can remove it for a few days as this system also has a TBS-6280 (2 x DVB-T/T2 PCI-e card) which it will fall-back to.
Mike
Vbox Multirecord
Forum rules
Please be reasonable and positive with your feature requests, remember that all contributions to MythTV are by volunteers in their spare time. MythTV won't support piracy in any form, including torrents and use of soft cams, so to avoid embarrassment please do not ask.
* One suggestion per thread please. Do not post new suggestions in replies. *
Please be reasonable and positive with your feature requests, remember that all contributions to MythTV are by volunteers in their spare time. MythTV won't support piracy in any form, including torrents and use of soft cams, so to avoid embarrassment please do not ask.
* One suggestion per thread please. Do not post new suggestions in replies. *
Re: Vbox Multirecord
@paulh
Just found a problem with my multirec patch,some mythtv services API calls are not working correctly. There will some more changes, will let you know when I have it sorted. It involves some default parameters in dtv_multiplex table, the VBOX works properly, just not services API.
Mike
Just found a problem with my multirec patch,some mythtv services API calls are not working correctly. There will some more changes, will let you know when I have it sorted. It involves some default parameters in dtv_multiplex table, the VBOX works properly, just not services API.
Mike
Re: Vbox Multirecord
@paulh
Here is the updated patch which applies cleanly to master 245e078 bump ABI after constructor changes.
The changes fix the services API issue by giving some default values.
I have also stopped xmltvid being updated when the VBOX is rescanned in mythtv-setup, user is likely to have changed the xmltvid, so we should not overwrite it
The patch includes the temporary fix to iptvtuningdata.h (stops mythsingledownload)
Also included in the patch is a change to videosource,cpp which moves Signal and Channel timeouts to the main configuration screen, instead of Recording Options, the defaults have been increased to 7000 and 10000. I did try just changing the values in the vbox extra panel but this does not work (also affects 0.28/fixes) - there is something strange going on just selecting Recording Options causes the Capture Card to be created in the database with type V4L, defaults of 1000 and 3000 for the timeouts, the type is then immediately updated to VBOX, I suspect a reload at this point picks up the 1000 and 3000 values instead of 7000 and 10000.
The patch has been tested using two VBOXs details as follows:
Mike
Here is the updated patch which applies cleanly to master 245e078 bump ABI after constructor changes.
The changes fix the services API issue by giving some default values.
I have also stopped xmltvid being updated when the VBOX is rescanned in mythtv-setup, user is likely to have changed the xmltvid, so we should not overwrite it
The patch includes the temporary fix to iptvtuningdata.h (stops mythsingledownload)
Also included in the patch is a change to videosource,cpp which moves Signal and Channel timeouts to the main configuration screen, instead of Recording Options, the defaults have been increased to 7000 and 10000. I did try just changing the values in the vbox extra panel but this does not work (also affects 0.28/fixes) - there is something strange going on just selecting Recording Options causes the Capture Card to be created in the database with type V4L, defaults of 1000 and 3000 for the timeouts, the type is then immediately updated to VBOX, I suspect a reload at this point picks up the 1000 and 3000 values instead of 7000 and 10000.
The patch has been tested using two VBOXs details as follows:
Code: Select all
# VBOX INFO
VBOX XYI 3442
Dual DVB-T/2 Tuners
Board Information
Serial Number 000000 000000 344221 644C97
Hardware Revision A0
Manufacture ID 0828
Product Number 3442
Product Name 3442-21
Software Versions
Software Version XTI_VJ.2.56
Linux 3.4.100_stm24_0309.3-rc1-B2064_h205-STSDK
Kernel Image VJ04
Boot Loader Image 3.1.3
Disk Image IVB-2.0-25
VBOX XTI 3340
Dual DVB-T tuners, single DVB-S tuner, single DVB-S1/2 tuner
Board Information
Serial Number 000000 000000 001637 643852
Hardware Revision H0
Manufacture ID 0827
Product Number 3345
Product Name 3345-21
Software Versions
Software Version XTI_VB.2.56
Linux 2.6.32.42_stm24_V4.0-HDK7111_7111-STSDK
Kernel Image VB04
Boot Loader Image 2.1.20
Disk Image IVB-2.0-25
- Attachments
-
- vbox_multirec_20170212.patch.zip
- vbox multirec patch
- (4.96 KiB) Downloaded 248 times
Re: Vbox Multirecord
Thanks Mike,
I've just committed your latest patch to master more or less as is for now, just cleaned the formatting up a little in a few places.
I'll come back to it when I have more time for Myth to fix the remaining issues.
I've just committed your latest patch to master more or less as is for now, just cleaned the formatting up a little in a few places.
I'll come back to it when I have more time for Myth to fix the remaining issues.
Re: Vbox Multirecord
@paulh
Thanks.
Just a heads up, nothing to with the patches, but there is a channel tuning problem following commit https://github.com/MythTV/mythtv/commit ... f5d5e7cdbc
Edit:
Ticket has now been resolved, software fix has been committed to mythtv master branch
I have raised a ticket see https://code.mythtv.org/trac/ticket/13002
Thanks.
Just a heads up, nothing to with the patches, but there is a channel tuning problem following commit https://github.com/MythTV/mythtv/commit ... f5d5e7cdbc
Edit:
Ticket has now been resolved, software fix has been committed to mythtv master branch
I have raised a ticket see https://code.mythtv.org/trac/ticket/13002
-
- Junior
- Posts: 33
- Joined: Tue Nov 18, 2014 7:44 am
Re: Vbox Multirecord
Is it possible / likely to have this commit (https://github.com/MythTV/mythtv/commit ... 846b7bfe4b) pushed down to fixes/0.28?
I don't have the VBOX but it looks like the workaround applied to mythtv/libs/libmythtv/recorders/iptvchannel.cpp initiated from ticket 12773 (https://code.mythtv.org/trac/ticket/12773) which is bundled together with this commit may resolve (work around) my segfault.
If it is not possible for this commit as a whole to apply to fixes/0.28 could the ticket 12773 changes be separated out and be applied individually?
I don't have the VBOX but it looks like the workaround applied to mythtv/libs/libmythtv/recorders/iptvchannel.cpp initiated from ticket 12773 (https://code.mythtv.org/trac/ticket/12773) which is bundled together with this commit may resolve (work around) my segfault.
If it is not possible for this commit as a whole to apply to fixes/0.28 could the ticket 12773 changes be separated out and be applied individually?
Re: Vbox Multirecord
@paulh
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
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
- Attachments
-
- iptv-protocol-changes-paul-h3-select-distinct.patch.zip
- (4.93 KiB) Downloaded 194 times
-
- iptv-protocol-changes-paul-h2.patch.zip
- (4.89 KiB) Downloaded 192 times
-
- iptv-protocol-changes-paul-h.patch.zip
- (4.82 KiB) Downloaded 194 times