Page 1 of 2

Vbox Multirecord

Posted: Sat Sep 24, 2016 11:56 am
by MikeB2013
I have an Vboxcomm XTI 3442 (dual DVB-T/T2) running firmware XTI_VJ.2.54.2.

I have made an attempt at patching mythtv master to support multirecord on Vbox.

I have successfully had 10 simultaneous scheduled HD recordings on UK Freeview, see attached screen grab from Vbox streaming status screen.
Screenshot from 2016-09-23 11-57-43.png.tar.gz
Vbox Streaming Status
(248.28 KiB) Downloaded 403 times
There is still work to do especially in the area of LiveTV which has some problems, which causes either seg faults or the wrong channel to be shown (seems to be in the area of using previously tuned channel when switching to a new channel - there seems to be some history here which I don't understand).

My current patch is attached for information, but be aware it is work in progress and is not yet suitable for production use and will cause problems with anyone using HLSPlaylists (there is a temporary patch to stop mythbacked seg faults - see Ticket #12856)
vbox_multirec_20160924.patch.tar.gz
vbox multirec patch
(2.41 KiB) Downloaded 355 times
It also has not had any testing with other tuner types, so there could be unexpected side effects.

I would appreciate any thoughts from a developer on this.


Mike

Re: Vbox Multirecord

Posted: Sun Sep 25, 2016 10:15 am
by paulh
Thanks for looking at this Mike.

Looks a lot simpler patch than I imagined :)

Re: Vbox Multirecord

Posted: Fri Sep 30, 2016 11:21 am
by MikeB2013
Just a quick update.

Most of the Live TV problems were due to a bug with multiplex restriction code in Master, I have raised a ticket see https://code.mythtv.org/trac/ticket/12891

I have also tested with a single USB DVB-T/T2 tuner (Astrometa) LiveTV and scheduled recordings are working fine across Vbox and DVB tuners.

Note that the way Capture cards are provisioned has changed in Master (from 0.28/Fixes) in that the maximum number of recordings is now set in Input Connections rather than Capture Cards. I understand this is "work in progress" but there is a side effect which means the order of creation is important otherwise tuners may not be efficiently used. Unless things change it seems that a Capture Card needs to be fully configured before adding the next one i.e. Create Capture Card, Create Video Source, Create Input Connections, then do the next Capture Card. In 0.28/Fixes I was used creating all Capture Cards then Video Sources, followed by Input Connections.

Mike

Re: Vbox Multirecord

Posted: Thu Nov 10, 2016 5:01 pm
by MikeB2013
Another update

Attached is my latest patch, the changes are:
1. Minor changes to keep mythtv-setup happy with vbox firmware version.

2. Check for VBOX presence on network when mythbackend starts, if check fails recorders are marked as errored. The check (IsVBoxPresent) just pings the VBOX. The check fails if response is not received within signal_timeout period specified when the VBOX was configured.

3. The patch includes fixes from track tickets #12856 and #12773 (comment 10) - both caused mythbackend seg faults.

The patch works for both fixes/0.28 and master, most of my testing was done on master. Note that fixes/0.28 limits multirecord to 5 for each VBOX tuner, master limit is 10.

I had 6 frontends (mixture of mythfrontend and kodi - krypton using pvr.mythtv addon 4.9.0) playing LiveTV at the same time.

All recording testing was done using xmltv data (I use SchedulesDirect) with tv_grab_sd_json.

I also added a dual DVB-S/S2 (UK Freesat) tuner to the test configuration, there were no adverse interactions across the tuner types.

Mike

Re: Vbox Multirecord

Posted: Tue Dec 20, 2016 4:21 pm
by stuarta
Is there an open ticket to capture this patch?

Re: Vbox Multirecord

Posted: Thu Dec 22, 2016 1:11 am
by MikeB2013
stuarta wrote:Is there an open ticket to capture this patch?
Not at present, my patch includes a couple of temporary fixes ( trac tickets #12856 and #12773), #12856 breaks HLSPlaylist handling, so I am waiting for these to be fully fixed before refactoring my patch. If it helps I can raise a ticket "as is"

Mike

Re: Vbox Multirecord

Posted: Thu Jan 05, 2017 2:47 pm
by paulh
I'm tempted to just commit this to master has is and see what the fallout is :idea: :?:

What settings on the Vbox does it need? I'm assuming you have to uncheck 'Limit single channel streaming per UPnP device' ? Any others?

Re: Vbox Multirecord

Posted: Sat Jan 07, 2017 9:41 pm
by MikeB2013
From memory (I am not near my mythtv system at present, but will be in few days) there are no other setting changes on the VBox.

Your call about committing to master, but it will break HLSPlaylists, maybe this needs to be fixed first . I can then update the patch. I don't know how to fix the HLSPLaylist issue (bypass test if it is a Vbox), my knowledge of C++ and the mythtv code is not good enough.

Mike

Re: Vbox Multirecord

Posted: Wed Jan 11, 2017 8:32 am
by MikeB2013
Just confirming Vbox configuration, Limit single channel streaming per UPnP device is unchecked, no other changes are required.
My XTI 3442 running XTI_VJ.2.54.2 firmware is stable and has System Uptime of 42 days.

My mythtv setup for Vbox is as follows on master v29-pre-262-g95d217e-dirty on Mythbuntu 16.04
Capture Card: Recording Options Signal timeout (ms) 7000, Tuning timeout (ms) 10000 (I was seeing occasional tuning timeouts with default values when VBox had high CPU load)
Input Connections: Max Recordings 5 (Interactions between Inputs)
Video Sources: Listings Grabber Schedules Direct JSON API (xmltv)

Note when configuring Capture Cards in master, do so by adding Capture Cards one at a time, followed by Video Source then Input Connections for each Capture Card (this ensures maximum tuner utilisation with multirecord, as Max Recordings setting has been moved from Capture Card to Input Connections)

I have 4 other tuners in my setup (TBS6981 dual input DVB-S/S2 using UK Freesat, TBS6280 dual input DVB-T/T2 UK Freeview) using official TBS Linux Drivers, all have Max Recordings set to 5 in Input Connections.

Mike

Re: Vbox Multirecord

Posted: Tue Jan 17, 2017 9:23 am
by MikeB2013
Update

I think I have found a solution to trac https://code.mythtv.org/trac/ticket/12856 where MythSingleDownload is being triggered and causes mythbackend seg fault.

Based on my understanding (which is limited) of HLSPLaylists within current Mythtv, the URL should end with either .m3u8 or .m3u.

I have modified IsHLSPlaylist in file iptvtuningdata.h to return false unless URL ends in either .m3u8 or .m3u in which case MythSingleDownload will be triggered. VBox channel URLs (in iptv_channel table) do not end with either .m3u8 or .m3u.

Attached is my latest vbox_multirec patch incorporating this change.

Mike

Re: Vbox Multirecord

Posted: Wed Jan 25, 2017 5:16 pm
by paulh
While that will work for the vbox it isn't necessarily going to work for other IPTV methods. For example you could have a URL that downloads a .m3u8 playlist but the URL doesn't end in .m3u8.

There is also the problem that not all .m3u8 playlists are HLS playlists. HLS playlist are just a specialised playlist with extra tags to tell the player to handle things differently.

I'd rather we eliminated the need to do the test download each time we want to play a IPTV channel just to see if we have a playlist, hls playlist or direct stream. I think we should store the type of channel we are dealing with in the DB, probably determine the type when we do a file scan and store the result in the DB so we only have to do it once.

Re: Vbox Multirecord

Posted: Sun Jan 29, 2017 10:51 am
by MikeB2013
Yes, elimination of the test download seems to be the way forward.

My thinking about testing for .m3u8 was to make it "less broken" (rather than a return false) if you were still thinking of putting it in master and see what the fallout is.

I note that iptv_channel table already has a type field (set to 'data ' for VBOX), is this what you are proposing to modify?

I also noticed that channel table has a field for iptvid which is not currently used.

Mike

Re: Vbox Multirecord

Posted: Sun Jan 29, 2017 11:22 am
by paulh
Yeah something like that.

It's not straight forward since that field in the database is a set so we can't just poke new values in there without updating the database schema first. Need to be careful not to change the order of the values so any new ones would need to be appended to the end of the set.

There's a number of problems though which is why I keep putting looking at it of like updating the DB schema in master is fine. Updating it in 0.28-fixes could be a problem :( Filling that field during a scan is no problem but how do we update existing channels in the DB. It will probably involve a lengthy DB update to check each IPTV channel and update the field in the DB as appropriate.

Re: Vbox Multirecord

Posted: Sun Jan 29, 2017 2:18 pm
by MikeB2013
A few thoughts about upgrade, which as you state could be tricky.

I used a separate Videosource dedicated to VBOX, I have no idea of the effect of using a shared Videosource with multirec on the VBOX will have, I suspect a rescan of VBOX will trash some dtv_multiplex entries for that Videosource.

A rescan of VBOX may overwrite xmltvid in channel table.

I wonder if a better approach to avoid complications, is to add a new tuner type in mythtv-setup Capture Cards, say "VBOX_MR", leaving existing tuner type VBOX behaviour as is. Existing users don't have to do anything. If they want multirec functionality they would need to delete existing VBOX capture cards and add new ones for "VBOX_MR". I can make the necessary code changes for this if you think a new tuner type is a better way to go.

I think the DB schema upgrade would be a lot simpler, no rescanning, just update the type for all entries in iptv_channel table associated with tuner types VBOX and VBOX_MR" if they exist.

Edit 30 January 2017:
On further investigation, no need for a new tuner tyoe. I have just run a test on a 0.28 test system (default install from mythbuntu 16.04 updated to latest 0.28/Fixes via mythbuntu ppa), setup a vbox XTI 3340 running VB2.56 firmware. Built from source 0.28/fixes with my latest patch vbox_multirecord patch applied, the vbox continued to function normally.

Mike

Re: Vbox Multirecord

Posted: Wed Feb 01, 2017 10:56 pm
by paulh
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.