Page 2 of 2

Re: Vbox Multirecord

Posted: Thu Feb 02, 2017 1:37 pm
by MikeB2013
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.


Re: Vbox Multirecord

Posted: Sun Feb 05, 2017 5:28 pm
by MikeB2013

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.


Re: Vbox Multirecord

Posted: Sun Feb 12, 2017 5:11 pm
by MikeB2013

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

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

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
Kernel Image 		VB04
Boot Loader Image 		2.1.20
Disk Image 		IVB-2.0-25 

Re: Vbox Multirecord

Posted: Sun Feb 19, 2017 11:46 am
by paulh
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.

Re: Vbox Multirecord

Posted: Tue Feb 21, 2017 11:33 am
by MikeB2013


Just a heads up, nothing to with the patches, but there is a channel tuning problem following commit ... f5d5e7cdbc

Ticket has now been resolved, software fix has been committed to mythtv master branch
I have raised a ticket see

Re: Vbox Multirecord

Posted: Sat Apr 08, 2017 11:43 pm
by perkins1724
Is it possible / likely to have this 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 ( 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

Posted: Mon Jul 02, 2018 5:50 pm
by MikeB2013
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.

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