Opened 3 years ago
Last modified 3 weeks ago
#13121 assigned Patch - Feature
Sat>IP client support
Reported by: | Owned by: | Klaas de Waal | |
---|---|---|---|
Priority: | minor | Milestone: | 32.0 |
Component: | MythTV - Recording | Version: | Master Head |
Severity: | low | Keywords: | |
Cc: | Ticket locked: | no |
Description
The changes in the branch at https://github.com/cguedel/mythtv/tree/devel/satip add Sat>IP support to the backend. This allows the backend to use Sat>IP compliant networked tuners to record DVB-C/DVB-S/DVB-T programs.
This works relatively stable for me, however I can only test DVB-C on one network. Also, the channel scanner seems to be broken for this network, so I can't really test that.
EIT scanning is also working.
Support for DVB-S is certainly lacking, as the Diseqc configuration is missing altogether.
Also, this only implements the "Unicast Only Profile" as per the Sat>IP spec found at http://www.satip.info/sites/satip/files/resource/satip_specification_version_1_2_2.pdf. Multicast is not supported.
Attachments (8)
Change History (60)
comment:1 Changed 3 years ago by
Component: | MythTV - General → MythTV - Recording |
---|---|
Owner: | set to JYA |
Type: | Bug Report - General → Patch - Feature |
comment:2 Changed 8 months ago by
Owner: | changed from JYA to Klaas de Waal |
---|---|
Status: | new → assigned |
comment:3 Changed 7 months ago by
Milestone: | needs_triage → 32.0 |
---|---|
Severity: | medium → low |
comment:4 Changed 7 months ago by
build from source on Xubuntu 18.04 fails:
make[2]: Entering directory '/srv/mike/build/mythtv/mythtv/libs/libmythtv' ccache g++ -c -pipe -D_FILE_OFFSET_BITS=64 -DPIC -std=c++17 -faligned-new -DNDEBUG -fomit-frame-pointer -fPIC -DQT_DISABLE_DEPRECATED_BEFORE=0x050700 -msse -pthread -g -Wall -Wextra -Wpointer-arith -fvisibility-inlines-hidden -Wdouble-promotion -Wduplicated-cond -Wlogical-op -Wmissing-declarations -Wnull-dereference -Woverloaded-virtual -Wshadow -funit-at-a-time -Wzero-as-null-pointer-constant -Wsuggest-override -I/usr/include/freetype2 -I/usr/include/libpng16 -isystem ../../external/libmythdvdnav/dvdnav -isystem ../../external/libmythdvdnav/dvdread -fvisibility=hidden -D_REENTRANT -fPIC -DMMX -Dusing_libcec -D_GNU_SOURCE -DUSING_LIBCRYPTO -DUSING_LIBASS -DUSING_V4L2PRIME -DUSING_VDPAU -DUSING_VAAPI -DUSING_NVDEC -DFFTW3_SUPPORT -DUSING_X11 -DUSING_OPENGL -DUSING_EGL -DUSING_AIRPLAY -DUSING_MHEG -DUSING_FRONTEND -DUSING_ALSA -DUSING_OSS -DUSING_V4L2 -DUSING_LINUX_FIREWIRE -DUSING_FIREWIRE -DUSING_IPTV -DUSING_HDHOMERUN -DHDHOMERUN_HEADERFILE=\"libhdhomerun/hdhomerun.h\" -DHDHOMERUN_V2 -DUSING_SATIP -DUSING_VBOX -DUSING_CETON -DUSING_IVTV -DUSING_HDPVR -DUSING_DVB -DUSING_BACKEND -DMTV_API -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_XML_LIB -DQT_SQL_LIB -DQT_CORE_LIB -I. -isystem /usr/include/libxml2 -isystem /usr/include/X11 -I.. -I../.. -I../.. -I../../external/FFmpeg -I. -I../libmyth -I../libmyth/audio -I../libmythbase -Impeg -Ichannelscan -Ivisualisations -Imheg -Idecoders -Iopengl -Iio -Icaptions -Irecorders -Irecorders/dvbdev -Irecorders/rtp -Irecorders/vbitext -Irecorders/HLS -I../libmythlivemedia/BasicUsageEnvironment/include -I../libmythlivemedia/BasicUsageEnvironment -I../libmythlivemedia/groupsock/include -I../libmythlivemedia/groupsock -I../libmythlivemedia/liveMedia/include -I../libmythlivemedia/liveMedia -I../libmythlivemedia/UsageEnvironment/include -I../libmythlivemedia/UsageEnvironment -I../libmythbase -I../libmythui -I../libmythupnp -I../libmythservicecontracts -I../../external/libmythdvdnav/dvdnav -I../../external/libmythdvdnav/dvdread -I../../external/nv-codec-headers/include -isystem /usr/include/x86_64-linux-gnu/qt5 -isystem /usr/include/x86_64-linux-gnu/qt5/QtWidgets -isystem /usr/include/x86_64-linux-gnu/qt5/QtGui -isystem /usr/include/x86_64-linux-gnu/qt5/QtNetwork -isystem /usr/include/x86_64-linux-gnu/qt5/QtXml -isystem /usr/include/x86_64-linux-gnu/qt5/QtSql -isystem /usr/include/x86_64-linux-gnu/qt5/QtCore -Imoc -isystem /usr/include/libdrm -I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -o obj/satipstreamhandler.o recorders/satipstreamhandler.cpp recorders/satipstreamhandler.cpp: In member function ‘virtual void SatIPStreamHandler::run()’: recorders/satipstreamhandler.cpp:184:14: error: ‘std::this_thread’ has not been declared std::this_thread::sleep_for(std::chrono::milliseconds(40)); ^~~~~~~~~~~ Makefile:18961: recipe for target 'obj/satipstreamhandler.o' failed make[2]: *** [obj/satipstreamhandler.o] Error 1 make[2]: Leaving directory '/srv/mike/build/mythtv/mythtv/libs/libmythtv' Makefile:265: recipe for target 'sub-libmythtv-make_first' failed make[1]: *** [sub-libmythtv-make_first] Error 2 make[1]: Leaving directory '/srv/mike/build/mythtv/mythtv/libs' Makefile:66: recipe for target 'libs' failed make: *** [libs] Error 2
buildbot for master ubuntu 18.04 is also showing failure https://code.mythtv.org/buildbot/#/builders/22/builds/713
build from source on Xubuntu 20.04 is ok.
Mike
comment:6 Changed 7 months ago by
There is an issue with Multirec and EIT on the SatIP tuner. This can be avoided by disabling Multirec. To do that set the "Max Recordings" to 1 and uncheck the "Schedule as Group" in the Input Connections dialog of mythtv-setup.
comment:7 Changed 7 months ago by
Klaas,
In mythtv-setup Capture Card for Sat>IP I think an "Enable/Disable? EIT" checkbox is required. I ran a quick test with 4 x DVB/S2 tuners setup in minisatip and EIT processing was continuously running on all 4 tuners.
Whilst on the subject of eit, does "SATIP" need to be added in https://github.com/MythTV/mythtv/blob/master/mythtv/libs/libmythtv/tv_rec.cpp
void TVRec::CloseChannel(void) { if (m_channel && ((m_genOpt.m_inputType == "DVB" && m_dvbOpt.m_dvbOnDemand) || m_genOpt.m_inputType == "FREEBOX" || m_genOpt.m_inputType == "VBOX" || m_genOpt.m_inputType == "HDHOMERUN" || CardUtil::IsV4L(m_genOpt.m_inputType))) { m_channel->Close(); } }
Mike
comment:8 Changed 7 months ago by
Klaas,
Just tried DVB-T/T2 UK Freeview and it basically worked, although the "SETUP" messages are out of specification (minisatip does not seem to care), a couple of examples:
Jul 16 13:34:13 2004-satip mythbackend: mythbackend[6844]: D CoreContext recorders/satiprtsp.cpp:233 (sendMessage) SatIPRTSP[2]: sendMessage write: SETUP rtsp://192.168.0.221:554/?freq=498.00&bw=8&msys=dvbt&tmode=auto&mtype=unknownqam&gi=132&fec=auto RTSP/1.0 Jul 16 13:38:08 2004-satip mythbackend: mythbackend[6844]: D TVRecEvent recorders/satiprtsp.cpp:233 (sendMessage) SatIPRTSP[2]: sendMessage write: SETUP rtsp://192.168.0.221:554/?freq=474.00&bw=8&msys=dvbt2&tmode=auto&mtype=unknownqam&gi=132&fec=auto RTSP/1.0
Here are contents of dtv_multiplex table after channel scan:
------+---------+---------------+-----------+--------------+---------+---------+------------+----------------+---------------------+-------------------+ | mplexid | sourceid | transportid | networkid | frequency | inversion | symbolrate | fec | polarity | modulation | bandwidth | lp_code_rate | transmission_mode | guard_interval | visible | constellation | hierarchy | hp_code_rate | mod_sys | rolloff | sistandard | serviceversion | updatetimestamp | default_authority | +---------+----------+-------------+-----------+-----------+-----------+------------+------+----------+------------+-----------+--------------+-------------------+----------------+---------+---------------+-----------+--------------+---------+---------+------------+----------------+---------------------+-------------------+ | 1 | 1 | 16515 | 9018 | 474000000 | 0 | 0 | auto | v | auto | 8 | auto | a | 1/32 | 0 | auto | n | auto | DVB-T2 | 0.35 | dvb | 33 | 2020-07-16 12:40:44 | | | 2 | 1 | 8194 | 9018 | 498000000 | 0 | 0 | auto | v | auto | 8 | auto | a | 1/32 | 0 | auto | n | auto | DVB-T | 0.35 | dvb | 33 | 2020-07-16 12:40:44 | | | 3 | 1 | 4173 | 9018 | 522000000 | 0 | 0 | auto | v | auto | 8 | auto | a | 1/32 | 0 | auto | n | auto | DVB-T | 0.35 | dvb | 33 | 2020-07-16 12:40:44 | | | 4 | 1 | 12294 | 9018 | 570000000 | 0 | 0 | auto | v | auto | 8 | auto | a | 1/32 | 0 | auto | n | auto | DVB-T | 0.35 | dvb | 33 | 2020-07-16 12:40:44 | | | 5 | 1 | 20544 | 9018 | 594000000 | 0 | 0 | auto | v | auto | 8 | auto | a | 1/32 | 0 | auto | n | auto | DVB-T | 0.35 | dvb | 33 | 2020-07-16 12:40:44 | | | 6 | 1 | 24640 | 9018 | 690000000 | 0 | 0 | auto | v | auto | 8 | auto | a | 1/32 | 0 | auto | n | auto | DVB-T | 0.35 | dvb | 33 | 2020-07-16 12:40:44 | | | 7 | 1 | 40960 | 9018 | 746000000 | 0 | 0 | auto | v | auto | 8 | auto | a | 1/32 | 0 | auto | n | auto | DVB-T2 | 0.35 | dvb | 33 | 2020-07-16 12:40:44 | | +---------+----------+-------------+-----------+-----------+-----------+------------+------+----------+------------+-----------+--------------+-------------------+----------------+---------+---------------+-----------+--------------+---------+---------+------------+----------------+---------------------+-------------------+ 7 rows in set (0.00 sec)
Test Configuration:
MythTV Version : v32.0~master.202007151913.b76dbf4~ubuntu20.04.1 combined FE/Backend
UK Freeview from SandyHeath? transmitter
tuner is TBS 6280 Dual DVB-T/T2 PCI-e using TBS drivers with kernel Linux 2004-satip 5.4.0-40-generic #44-Ubuntu SMP Tue Jun 23 00:01:04 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux under Xubuntu 20.04
Minisatip Version: 1.0.3-e8bb03b running on same hardware as mythbackend
Mike
comment:11 Changed 7 months ago by
Klaas,
mythconverg database schema update is required to add SatIP Recorder to profilegroups with associated entries in recordingprofiles otherwise mythbackend reports errors like :
Jul 17 11:20:53 2004-satip mythbackend: mythbackend[5769]: E Scheduler tv_rec.cpp:4159 (LoadProfile) TVRec[1]: Profile 'Default' not found, and unable to load fallback profile 'Default'. Results may be unpredicable Jul 17 11:20:53 2004-satip mythbackend: mythbackend[5769]: E TVRecEvent tv_rec.cpp:4159 (LoadProfile) TVRec[1]: Profile 'Live TV' not found, and unable to load fallback profile 'Default'. Results may be unpredicable Jul 17 11:20:55 2004-satip mythbackend: mythbackend[5769]: E TVRecEvent tv_rec.cpp:4159 (LoadProfile) TVRec[1]: Profile 'Default' not found, and unable to load fallback profile 'Default'. Results may be unpredicable
Manually adding the following to the database stopped the error messages above.
direct to database INSERT INTO profilegroups SET name = 'SatIP Recorder', cardtype = 'SATIP', is_default = 1; Note the id created in this case 19 INSERT INTO recordingprofiles SET name = "Default", profilegroup = 19; INSERT INTO recordingprofiles SET name = "Live TV", profilegroup = 19; INSERT INTO recordingprofiles SET name = "High Quality", profilegroup = 19; INSERT INTO recordingprofiles SET name = "Low Quality", profilegroup = 19;
see dbcheck.cpp dbver == "1339" for an example using Vbox
$SCHEMA_VERSION in mythtv/binding/perl/MythTV.pm and mythtv/bindings/python/MythTV/static.py will also need updating to next schema version.
Mike
comment:13 Changed 6 months ago by
Mike,
Thanks for the testing and for the tips. Expect fixes in the near future.
Issues not solved yet:
- DVB-T2 tuning parameters
- Recording profiles (was this not something from the PVR150/500 days, setting MPEG encoding parameters?)
- MPTS full TS recording; described in the Sat>IP protocol but not yet implemented.
As yet untested:
- DVB-C with minisatip
There are also still some stability issues with the TELESTAR Digibit satellite box.
comment:14 Changed 6 months ago by
Hi Klaas,
I am seeing a mythbackend seg fault on exit from LiveTV
Attached are gdb.txt and mythbackend log relating to the backtrace. I suspect it has something to do with the change that added SATIP to void TVRec::CloseChannel?(void) in tv_rec.cpp
Please attach all output as a file in bug reports. MythTV Version : v32-Pre-699-g0db4df0b2f MythTV Branch : master Network Protocol : 91 Library API : 32.20200101-1 QT Version : 5.9.5 Options compiled in: linux profile use_hidesyms using_alsa using_oss using_pulse using_pulseoutput using_backend using_bindings_perl using_bindings_python using_bindings_php using_dvb using_firewire using_frontend using_hdhomerun using_satip using_vbox using_ceton using_hdpvr using_ivtv using_joystick_menu using_libcec using_libcrypto using_gnutls using_libdns_sd using_libfftw3 using_libxml2 using_lirc using_mheg using_opengl using_egl using_qtwebkit using_qtscript using_qtdbus using_taglib using_v4l2 using_v4l2prime using_x11 using_libbluray_external using_xrandr using_profiletype using_systemd_notify using_systemd_journal using_drm using_bindings_perl using_bindings_python using_bindings_php using_freetype2 using_mythtranscode using_opengl using_egl using_drm using_vaapi using_nvdec using_vdpau using_ffmpeg_threads using_mheg using_libass using_libxml2
comment:15 Changed 6 months ago by
At end of mythbackend.log there are some suspicious messages relating to QT timers and socket operations.
2020-07-19 13:33:57.375449 D [24920/24937] TVRecEvent recorders/streamhandler.cpp:155 (Stop) - SH[1](uuid:11223344-9999-0000-b7ae-c8600014a53d:DVBS2:0): Stopping 2020-07-19 13:33:57.375451 D [24920/24937] TVRecEvent recorders/streamhandler.cpp:158 (Stop) - SH[1](uuid:11223344-9999-0000-b7ae-c8600014a53d:DVBS2:0): Stopped 2020-07-19 13:33:57.375459 I [24920/24937] TVRecEvent mythcommandlineparser.cpp:2643 (operator()) - Qt: QSocketNotifier: Socket notifiers cannot be enabled or disabled from another thread 2020-07-19 13:33:57.375472 I [24920/24937] TVRecEvent mythcommandlineparser.cpp:2643 (operator()) - Qt: QObject::~QObject: Timers cannot be stopped from another thread 2020-07-19 13:33:57.375474 I [24920/24937] TVRecEvent mythcommandlineparser.cpp:2643 (operator()) - Qt: QSocketNotifier: Socket notifiers cannot be enabled or disabled from another thread 2020-07-19 13:33:57.375516 I [24920/24937] TVRecEvent tv_rec.cpp:3638 (TuningShutdowns) - TVRec[1]: Tearing down RingBuffer 2020-07-19 13:33:57.375602 I [24920/24937] TVRecEvent tv_rec.cpp:4438 (ClearFlags) - TVRec[1]: ClearFlags(PENDINGACTIONS,) -> RunMainLoop,RingBufferReady, @ tv_rec.cpp:3644 2020-07-19 13:33:57.375602 I [24920/24920] CoreContext mythcommandlineparser.cpp:2643 (operator()) - Qt: QSocketNotifier: Invalid socket 24 and type 'Read', disabling... 2020-07-19 13:33:57.375609 I [24920/24920] CoreContext mythcommandlineparser.cpp:2643 (operator()) - Qt: QSocketNotifier: Invalid socket 25 and type 'Read', disabling... 2020-07-19 13:33:57.375626 D [24920/24948] ProcessRequest livetvchain.cpp:34 (~LiveTVChain) - LiveTVChain(live-mike-GL62-7QF-2020-07-19T12:33:48Z): dtor 2020-07-19 13:33:57.375689 I [24920/24920] CoreContext mythcommandlineparser.cpp:2643 (operator()) - Qt: QSocketNotifier: Invalid socket 24 and type 'Read', disabling... 2020-07-19 13:33:57.375692 I [24920/24920] CoreContext mythcommandlineparser.cpp:2643 (operator()) - Qt: QSocketNotifier: Invalid socket 25 and type 'Read', disabling... 2020-07-19 13:33:57.375710 I [24920/24920] CoreContext mythcommandlineparser.cpp:2643 (operator()) - Qt: QSocketNotifier: Invalid socket 24 and type 'Read', disabling... 2020-07-19 13:33:57.375713 I [24920/24920] CoreContext mythcommandlineparser.cpp:2643 (operator()) - Qt: QSocketNotifier: Invalid socket 25 and type 'Read', disabling... 2020-07-19 13:33:57.375718 I [24920/24920] CoreContext mythcommandlineparser.cpp:2643 (operator()) - Qt: QSocketNotifier: Invalid socket 24 and type 'Read', disabling... 2020-07-19 13:33:57.375720 I [24920/24920] CoreContext mythcommandlineparser.cpp:2643 (operator()) - Qt: QSocketNotifier: Invalid socket 25 and type 'Read', disabling... 2020-07-19 13:33:57.375723 I [24920/24920] CoreContext mythcommandlineparser.cpp:2643 (operator()) - Qt: QSocketNotifier: Invalid socket 24 and type 'Read', disabling... 2020-07-19 13:33:57.375724 I [24920/24920] CoreContext mythcommandlineparser.cpp:2643 (operator()) - Qt: QSocketNotifier: Invalid socket 25 and type 'Read', disabling... 2020-07-19 13:33:57.375728 I [24920/24920] CoreContext mythcommandlineparser.cpp:2643 (operator()) - Qt: QSocketNotifier: Invalid socket 24 and type 'Read', disabling... 2020-07-19 13:33:57.375729 I [24920/24920] CoreContext mythcommandlineparser.cpp:2643 (operator()) - Qt: QSocketNotifier: Invalid socket 25 and type 'Read', disabling... 2020-07-19 13:33:57.375733 I [24920/24920] CoreContext mythcommandlineparser.cpp:2643 (operator()) - Qt: QSocketNotifier: Invalid socket 24 and type 'Read', disabling... :
comment:19 Changed 6 months ago by
TEARDOWN is sending extraneous ? character after stream identifier:
2020-07-25 17:08:02.306141 D [27761/27801] Scanner recorders/satiprtsp.cpp:235 (sendMessage) - SatIPRTSP[1]: sendMessage write: TEARDOWN rtsp://192.168.0.202:554/stream=1? RTSP/1.0
Change in satiprtsp.cpp see 20200726_satip_teardown.patch
comment:21 Changed 6 months ago by
I am seeing on occasion mythtv-setup seg faulting whilst channel scanning on DVB-T/T2 (UK Freeview)
Attached are gdb backtrace and mythtv-setup log.
In this case minisatip is running remote to mythtvbackend on a Raspberry Pi3 with TVHAT tuner which has the following capabilities:
pi@pi3-20200724:~/build/w_scan2 $ dvb-fe-tool Device Sony CXD2880 (/dev/dvb/adapter0/frontend0) capabilities: CAN_2G_MODULATION CAN_FEC_1_2 CAN_FEC_2_3 CAN_FEC_3_4 CAN_FEC_4_5 CAN_FEC_5_6 CAN_FEC_7_8 CAN_FEC_AUTO CAN_GUARD_INTERVAL_AUTO CAN_INVERSION_AUTO CAN_MUTE_TS CAN_QAM_16 CAN_QAM_32 CAN_QAM_64 CAN_QAM_128 CAN_QAM_256 CAN_QAM_AUTO CAN_QPSK CAN_RECOVER CAN_TRANSMISSION_MODE_AUTO DVB API Version 5.11, Current v5 delivery system: DVBT2 Supported delivery systems: DVBT [DVBT2] Frequency range for the current standard: From: 174 MHz To: 862 MHz Step: 1.00 kHz
Changed 6 months ago by
Attachment: | mythtv-setup.20200730131428.19054.log.zip added |
---|
mythtv-setup log chanscan seg fault
comment:23 Changed 6 months ago by
Hi Mike,
The above patch does solve a stability issue that came up when stress testing with a local DVB-S minisatip and a real networked Sat>IP box, also DVB-S.
However, your DVB-T2 scanning crash does look different. The plan is to reproduce this by attaching a MyGica? USB stick to a RPi3 and run minisatip on that. I do not expect that the hat does make any difference.
N.B. If there is any special incantation for the minisatip that you use please post that also.
comment:24 Changed 6 months ago by
Hi Klaas,
Nothing special for minisatip on Pi3, invoked at default by sudo ./minisatip
built from master source https://github.com/catalinii/minisatip
minisatip configuration Linux DVB: enabled Common Interface (needs DVBEN50221): disabled OpenSSL (AES as part of DVBAPI): enabled Embedded system: disabled DVBCSA (needs libdvbcsa): disabled Netceiver support: disabled SatIP Client: enabled Static: disabled dvbapi: enabled axe: disabled enigma: disabled
I use the same default minisatip build and configuration everywhere including Xubuntu 18.04 and Xubuntu 20.04
Mike
comment:25 Changed 6 months ago by
The segfault when scanning for DVB-T2 channels can be now reproduced, with the MyGica? USB stick and minisatip in my development box. To be continued.
comment:27 Changed 6 months ago by
Hi Klaas,
I am still seeing mythtv-setup seq fault whilst channel scanning on UK Freeview (DVB/T-T2) with latest master e015e7a. In this case it is a TBS6280 tuner with minisatip on same machine.
Attached are mythtv-setup.log and associated gdb backtrace. Note the seg fault happened after a number of channel scans (full scan).
Mike
Changed 6 months ago by
Attachment: | mythtv-setup.20200809123425.79080.log.zip added |
---|
mythtv-setup log tbs6280
comment:28 Changed 6 months ago by
Hi Mike,
Thanks for testing, looks like this is the same crash as before. So the discarding of old packets does not solve it, only makes the problem less frequent. Looks like a concurrency/locking issue as valgrind does not show anything.
Other bugs that are still present:
- When configured with a single tuner instance and Schedule as Group disabled, then the backend crashes on EIT when the single tuner instance is closed. This is accompanied with Qt error messages about doing things in the wrong thread. Removing SATIP from the close in tv_rec.cpp, or having at least two tuner instances, does fix this for now.
- Channelscan timeouts while actually finding all the channels.
Have been testing with minisatip and DVB-C and that works OK.
To be continued.
comment:29 Changed 6 months ago by
Hi Klaas,
I had a bit of time to play around with this and immediately hit the two bugs you mentioned.
I've not managed to find a solution to them but thought I'd add what I've found so far:
The crash appears to be because SatIPChannel::Open is called in ChannelBase::CreateChannel? via TVRec::CreateChannel? at start-up in the main thread, but SatIPChannel::Close is called from the TVRec thread when the recording. This is what is causing the error messages about the wrong threads and appears to be what is leading to the SIGSEGV.
ChannelBase::CreateChannel? almost immediately closes the channel if it's DVB, HDHOMERUN or a V4L card, but not if it's SatIP. Adding SatIP here stops the recording even starting and I haven't had time to investigate why.
Regarding the channel scan, I'm not sure if it's the same issue you are seeing but I had to tell it to use only DVB-S instead of DVB-S2 before the scan would work. The DVB-S2 channels were still found and a brief look in Wireshark seemed to indicate that MPEG-TS packets were being received when DVB-S2 was selected but nothing appeared in mythtv-setup and it timed out on the first transponder.
comment:30 Changed 5 months ago by
Hi Richard,
Thanks for looking into this. You are completely right about the bits in ChannelBase?, I had overlooked this. Getting the recording to start again after the channel has been closed in ChannelBase? is being fixed.
What is still going wrong in the channel scan is timeouts. They are almost all caused by, after doing the tuning, receiving a PAT from the previously tuned frequency. Tuning is complete when all PMTs of all channels have been received and this then never happens. How to filter out the packets from the previous frequency is still an issue. One possibility is to check more on transport ID if that is known, but this is a biggish change to the common code and not limited to SatIP.
About DVB-S/S2, in the "Full Scan (Tuned)" you have to specify the delivery system and the other tuning parameters of the initial frequency you want to start with.
comment:37 Changed 5 months ago by
Current status:
- Supports DVB-C/T/T2/S/S2
- Does NOT support DiSeqC yet
- Supports channel scans
- Tested with minisatip (DVB-C/T2/S/S2) and with the Telebit Digibit R1 box (DVB-S/S2)
- No crashes observed for some time now
Implementation details that might be improved:
- Open/close code. Channels are always kept open because opening and closing gives all kinds of errors.
- Reducing the RTP packet processing interval from 200 to 20 ms does fix a problem with missing RTP packets in MPTS recordings but there is no logical reason why this should make a difference. A possible reason can be the implementation of the underlying packetbuffer code because random numbers are used to identify packets and there is always a risk of collusion when storing a large number of packets.
- Channel scans work OK but sometimes the PAT of the previous transport is processed. This does cause a timeout but the scan results are OK. The difficult part is here that MythTV assumes that as soon as a tuning command is given that everything that is received after that is from the requested frequency. This is not really true in networked environments where packets are buffered. One possible solution, which would improve scanning for all tuner types, is to filter on transport ID when that is known. This requires storage of the transport ID in table dtv_multiplex and it somehow changes the concept of tuning from tuning to a frequency into tuning to a transport ID.
- Tuning timeout default values are quite high and are correct for DVB-S/S2 but could be reduced for DVB-C and DVB-T2. The actual values can of course be configured in the Capture Card page of mythtv-setup.
comment:38 Changed 3 months ago by
I have tried a Telestar Digibit Twin but could only get one input to work and then with some packet loss. I have posted some log fragments in https://forum.mythtv.org/viewtopic.php?f=3&t=4102. It looks to me like the box is defective so I am not posting here as a fault. I will return it in the next few days. I can supply more log info if you think it is a genuine bug rather than defective hardware.
comment:39 Changed 2 months ago by
Testing with a Digibit R1- produces good results with 2 active inputs. Log shows good quality recordings with some but low packet loss
tv_rec.cpp:825 (FinishedRecording) TVRec[3]: FinishedRecording(65791_2020-11-21T00:05:00Z) good recq:<RecordingQuality overall_score="1" key="65791_2020-11-21T00:05:00Z" continuity_error_count="10" packet_count="19911688" />
I use a remote frontend so the network may be busy occasionally. If I up the number of inputs in use to 3 and add EPG, noticeable glitches appear on the display about every 10 mins. My question is have you tested using the standard firmware in the Digibit box :- Firmware Version V1.25.0.157 (30-03-2016 17:48) or are you using https://github.com/perexg/satip-axe.
I note that satip-axe is an implementation of minisatip which supports TCP streaming. If I switch to this firmware would the mythtv client work with TCP streams and do you think it would be a sensible solution.
comment:40 Changed 2 months ago by
I have not changed the firmware in the box and it is indeed "Firmware Version V1.25.0.157 (30-03-2016 17:48)". I have tested with two inputs simultaneously and as noted, this works OK.
However, I found a correlation between "Sequence errors", indicating RTP packet loss and consequently continuity errors, and EIT "write to disk" actions. This could be the cause of the periodic display glitches.
MythTV only supports UDP at the moment. Minisatip can do both UPD and TCP and maybe going TCP is the way forward, but for the moment the plan is to check the UDP packet handling.
comment:41 Changed 2 months ago by
Testing with the SatIP box the "Sequence errors", other than those that appear after tuning to a new channel, are almost all gone when the UDP kernel buffers are increased from 256kb, the default on my system, to 4Mb.
This can be effected with the following commands:
$ sudo sysctl -w net.core.rmem_max=4194304 net.core.rmem_max = 4194304 $ sudo sysctl -w net.core.rmem_default=4194304 net.core.rmem_default = 4194304
Investigation shows that the data is not lost in satiprtsp.cpp; all packets that are received from the UDPSocket are stored in the buffer and retrieved from the buffer without loss.
There are also no lost packets at the interface level; the network driver has no errors and network statistics do not show lost packets.
Therefore all packets are lost in the UDP buffers; the packets are simply not read on time by MythTV. This is demonstrated by the output of
cat /proc/net/udp
of which the last column is the number of packets lost.
Increasing the buffer size does give more latency. A full transport stream from a satellite is about 40Mbit/second which is 5Myte/second, so 4Mb buffering is 800 milliseconds.
I do not know how much buffer memory is used by the /dev/dvb/adapter*/* drivers but mythtv is capable of reading all data from these devices without loss.
Using TCP instead of UDP will not solve anything as the packets are not lost at the network level. TCP allows flow control between MythTV and the SatIP box but the SatIP box will be less capable of buffering the stream than the MythTV PC is.
Note that usually the PID filtering is done by the SatIP box; only when the number of PIDs is more than 30 the full transport stream is received. This is the worst case situation and this can happen with channel scanning on some streams. Normal recording always uses PID filtering by the SatIP box and then the 4Mbyte buffer should be big enough for perfect recordings.
comment:42 Changed 2 months ago by
Increase UDP buffer size for Sat>IP
Try to increase the UDP buffer size for reading the Sat>IP RTP streams to 8Mbytes (decimal). A log message is given when the system maximum only allows for a lower value. Change log messages to have only the cardid and not the device name on each message. This leaves more space for the actual message text.
comment:43 Changed 2 months ago by
Have not yet tried the above commit. Will do so shortly. However by increasing the number of udp buffers in the system I can now record 3 HD streams with no packet loss. This is a big improvement will test further https://medium.com/@CameronSparr/increase-os-udp-buffers-to-improve-performance-51d167bb1360 .Used
If the values are less than 26214400 bytes (25MB) you should add the following lines to the /etc/sysctl.conf file: net.core.rmem_max=26214400 net.core.rmem_default=26214400
comment:44 Changed 2 months ago by
Apologies I had not noticed that you had already posted on the benefits of increasing the UDP buffering. Having increased the buffering and taken f0c708a89a3b762fa3ccbe3d8ccede7745000649 the system is performing well. There was a bad patch yesterday when :-
continuity_error_count="4409" packet_count="21125940"
This bad patch occurred in the last 5 minutes of the recording on BBC One HD - in the overrun time (in the 5 mins after the recording was scheduled to finish). It occurs to me that this was because 'schedule as group' is the default settings in mythtv-setup. So a new recording had been started in parallel on that tuner while the old one was completing its overun time.
I have now removed schedule as group from all the capture card inputs which I think will improve stability.
According to the 'monitor' page of the Digibit, normal HD channels show average rates up to 10000Kbits average. However I am now running
SatIPSH[6](uuid:3eec0475-c365-44e7-bf7c-6d53b0daf8e4:DVBS2:1): Tune url:rtsp://192.168.0.44:554/?fe=2&freq=10847.00&pol=v&ro=0.20&msys=dvbs2&mtype=8psk&sr=23000&fec=34&plts=auto
is showing 50000Kbits average. The BBC One / Two HD mux seems to go straight to 50k independently of how many channels are being viewed.
I have now ditched my USB tuner and am using 3 inputs from the Digibox and it is working great including EPG many thanks.
comment:45 Changed 2 months ago by
Thanks for reporting back.
About the UDP buffer size. I've looked in the HDHomeRun library and there the UDP buffer size is set to 1024x1024 bytes, the actual value depending on the net.core.rmem_max value of the system. Note that it overall saves memory if you only set the net.core.rmem_max value and not the net.core.rmem_default because MythTV only extends the buffer size for the socket that is actually used for the video data stream. There is also a socket for the control data and the buffer size of that socket does not need to be changed.
I've looked into the "bad patch" problem and this is caused by the multirec feature not yet being implemented completely. What happens is that when your second recording starts the box is tuned again, on the same channel. This causes the disruption in your first recording. The correct behavior is to recognize that the channel is already in use and that it is already correctly tuned so the tuning can be skipped. This is how it is implemented for the /dev/dvb/adapter*/* devices (PCI/PCIe, USB) and this is also how it should be done for SatIP.
About the bitrate of the incoming stream. The code is now such that when more than 32 PIDs are requested the full transport stream is received. When there are less PIDs requested then the Sat>IP box is doing the PID filtering so then you only receive the PIDs that are needed. This is done because the Digibit R1 box effectively dies when your request more than 36 or 37 PIDs. The minisatip software, running on a PC, does not have this limitation but we write software for the worst case situation. Still to investigate why recording a channel on the BBC One/Two? HD mux requires so many PIDS that it needs to receive the full transport stream.
Changed 8 weeks ago by
Attachment: | DroppedPacketLog02-12-20.zip added |
---|
comment:46 Changed 8 weeks ago by
Had 5 problem free days running 3 tuners and schedule as group disabled. Allowing two recordings on the first tuner to benefit from BBc One & Two Hd being on the same mux. This should not work for the reasons you describe.
+--------+-------------+-------------+-----------+------------+-------------+-------------+ | cardid | displayname | recpriority | quicktune | schedorder | livetvorder | dvb_eitscan | +--------+-------------+-------------+-----------+------------+-------------+-------------+ | 1 | Frs1 | 4 | 0 | 1 | 1 | 1 | | 2 | Frs2 | 3 | 0 | 1 | 1 | 0 | | 3 | Frs3 | 2 | 0 | 1 | 1 | 0 | | 4 | Frs1 | 4 | 0 | 1 | 1 | 1 | +--------+-------------+-------------+-----------+------------+-------------+-------------+
So connected all 4 inputs to the LNB and ran the system with only one recording allowed per card. This fell over at the transition time 9 pm again with lots of drop packets. A log is attached - it may be noteworthy that there is no tuning attempt for the program Harlots at 9 pm it must be trying to attach to an existing stream. Restarted the backend after 4 mins and it did the same thing again straight away ... mystified. Went back to my original configuration 3 inputs with two recordings allowed on the first. Seems bomb proof have been soak testing it ever since wth every sort of transition I can find between one or two recordings on the first tuner.
Log file added to attachments - apologies seems to have been attached to previous post? Just incompetance.
comment:47 follow-up: 49 Changed 8 weeks ago by
Again thanks for testing!
The latest update, commit f5e0fc0cf812b7615d571ef217e50229301bd5ef, skips the tuning part if you have a second recording on the same multiplex and thus avoids the "Sequence error" and the associated packet loss.
Next step is that the SatIP implementation will be restructured along the lines of how the HDHomeRun support is implemented. This is a comparable device, with four independent tuners and use of UDP packets for the video streaming. The HDHomeRun works OK with only a 1Mbyte UDP input buffer (instead of 8Mbyte) and it does not do extra buffering at the input. The current SatIP implementation is largely inspired by how it is done for Ceton and IPTV.
This should fix the remaining issues:
- inefficient/slow due to buffering all received input data
- allow to close the input device when not in use
- allow restart of the backend
comment:48 Changed 7 weeks ago by
The current implementation is performing very well many thanks. I will test anything you commit.
comment:49 Changed 7 weeks ago by
Replying to Klaas de Waal:
Next step is that the SatIP implementation will be restructured along the lines of how the HDHomeRun support is implemented. This is a comparable device, with four independent tuners and use of UDP packets for the video streaming. The HDHomeRun works OK with only a 1Mbyte UDP input buffer (instead of 8Mbyte) and it does not do extra buffering at the input. The current SatIP implementation is largely inspired by how it is done for Ceton and IPTV.
Klaas, FYI, I had a serious problem this past summer with frequent corruption in most recordings. With help, I traced the problem to lack of buffer space for my HDHR and Ceton tuners. I suspected a Linux kernel change was to blame as I'd never had the problem before and I don't believe the MythTV recorders had changed. Regardless of the cause, I raised my HDRingbufferSize setting to 75200 to get rid of the corruption. I have plenty of memory in my backend so I didn't spend any time backing that value down to see how low it could go without causing the problem.
Do the SatIP devices support TCP? From what I have gathered from other, HDHR users, using TCP does not have the same buffering problem and is also the recommended, access method from SiliconDust?. If the SaiIP boxes support TCP, you should consider using it, at least optionally.
comment:50 Changed 4 weeks ago by
mythbackend version: (HEAD detached at 7de9c58ad4) [v32-Pre-1753-g7de9c58ad4] www.mythtv.org
Had faultless recordings for the last 4 weeks until last night. I think that attempting to record more than one program on the same mux causes tuning problems where only a single channel is allowed. The above condition is unlikely to occur within my configuration so the above failure may be the only occurrence within the period. The issue arises probably due to me over constraining the configuration to get deterministic behaviour. I allow two simultaneous recording off the first mux and constrain the rest to one. This normally works fine as BBC1/2 HD are the lowest channel numbers and are normally allocated to this first mux. In the case in question the first mux was already allocated. Do you recommend me setting Schedule as Group for all tuners or setting max recordings to 2 for all tuners (which do you use).
Dec 31 22:24:30 I TVRecEvent tv_rec.cpp:1620 (HandlePendingRecordings) TVRec[2]: ASK_RECORDING 2 29 0 0 Dec 31 22:25:00 I TVRecEvent tv_rec.cpp:1061 (HandleStateChange) TVRec[2]: Changing from None to RecordingOnly Dec 31 22:25:00 I TVRecEvent mythdbcon.cpp:419 (PurgeIdleConnections) New DB connection, total: 11 Dec 31 22:25:00 I TVRecEvent tv_rec.cpp:3661 (TuningFrequency) TVRec[2]: TuningFrequency Dec 31 22:25:00 I TVRecEvent recorders/satipstreamhandler.cpp:216 (Tune) SatIPSH[2]: Tune 10847000 Dec 31 22:25:00 I Scheduler scheduler.cpp:2889 (HandleRecordingStatusChange) Tuning recording: "The Graham Norton New Year's Eve Show": channel 65792 on cardid [2], sourceid 1 Dec 31 22:25:00 C CoreContext programinfo.cpp:252 (ProgramInfo) ProgramInfo(): Failed to find recorded entry for 0. Dec 31 22:25:01 I CoreContext scheduler.cpp:713 (UpdateRecStatus) Updating status for "The Graham Norton New Year's Eve Show" on cardid [2] (Tuning => Recording) Dec 31 22:25:01 I TVRecEvent tv_rec.cpp:4208 (TuningNewRecorder) TVRec[2]: rec->GetPathname(): '/media/library/TV/65792_20201231222500.ts' Dec 31 22:25:01 I TVRecEvent tv_rec.cpp:4241 (TuningNewRecorder) TVRec[2]: TuningNewRecorder - CreateRecorder() Dec 31 22:25:01 E TVRecEvent recorders/recorderbase.cpp:216 (SetStrOption) RecBase[2](uuid:3eec0475-c365-44e7-bf7c-6d53b0daf8e4:DVBS2:2): SetStrOption(...recordingtype): Option not in profile. Dec 31 22:44:31 I TVRecEvent tv_rec.cpp:1620 (HandlePendingRecordings) TVRec[3]: ASK_RECORDING 3 29 0 0 Dec 31 22:45:00 I TVRecEvent tv_rec.cpp:1061 (HandleStateChange) TVRec[3]: Changing from None to RecordingOnly Dec 31 22:45:00 I TVRecEvent mythdbcon.cpp:419 (PurgeIdleConnections) New DB connection, total: 14 Dec 31 22:45:00 I TVRecEvent tv_rec.cpp:3661 (TuningFrequency) TVRec[3]: TuningFrequency Dec 31 22:45:00 I TVRecEvent recorders/satipstreamhandler.cpp:216 (Tune) SatIPSH[3]: Tune 10847000 Dec 31 22:45:00 I Scheduler scheduler.cpp:2889 (HandleRecordingStatusChange) Tuning recording: "Mock the Week": channel 65791 on cardid [3], sourceid 1 Dec 31 22:45:00 N Scheduler scheduler.cpp:3246 (HandleIdleShutdown) Blocking shutdown because of an active encoder Dec 31 22:45:00 N Scheduler scheduler.cpp:3257 (HandleIdleShutdown) Blocking shutdown because of delay request from external application Dec 31 22:45:00 C CoreContext programinfo.cpp:252 (ProgramInfo) ProgramInfo(): Failed to find recorded entry for 0. Dec 31 22:45:01 I CoreContext scheduler.cpp:713 (UpdateRecStatus) Updating status for "Mock the Week" on cardid [3] (Tuning => Recording) Dec 31 22:45:01 I TVRecEvent tv_rec.cpp:4208 (TuningNewRecorder) TVRec[3]: rec->GetPathname(): '/media/library/TV/65791_20201231224500.ts' Dec 31 22:45:01 I TVRecEvent tv_rec.cpp:4241 (TuningNewRecorder) TVRec[3]: TuningNewRecorder - CreateRecorder() Dec 31 22:45:01 E TVRecEvent recorders/recorderbase.cpp:216 (SetStrOption) RecBase[3](uuid:3eec0475-c365-44e7-bf7c-6d53b0daf8e4:DVBS2:3): SetStrOption(...recordingtype): Option not in profile. Dec 31 23:20:00 I TVRecEvent tv_rec.cpp:1061 (HandleStateChange) TVRec[3]: Changing from RecordingOnly to None Dec 31 23:20:01 N RecThread recorders/recorderbase.cpp:491 (FinishRecording) Finished Recording: Container: MPEG2-TS Video Codec: h264 (1920x1088 A/R: 3 25fps) Audio Codec: ac3 Dec 31 23:20:01 I TVRecEvent tv_rec.cpp:825 (FinishedRecording) TVRec[3]: FinishedRecording(65791_2020-12-31T22:45:00Z) damaged recq:<RecordingQuality overall_score="0.8" key="65791_2020-12-31T22:45:00Z" continuity_error_count="25014" packet_count="10025590" /> Dec 31 23:20:02 I CoreContext scheduler.cpp:713 (UpdateRecStatus) Updating status for "Mock the Week" on cardid [3] (Recording => Recorder Failed) Dec 31 23:20:02 I Scheduler scheduler.cpp:2321 (HandleReschedule) Reschedule requested for CHECK -9 7289 0 UpdateRecStatus2 | Mock the Week | | Dara O Briain and Hugh Dennis are joined by an array of guests in a special edition of the show. Contains some strong language. | fp.bbc.co.uk/m/ek0u Dec 31 23:20:02 I Scheduler scheduler.cpp:2438 (HandleReschedule) Scheduled 79 items in 0.1 = 0.00 match + 0.01 check + 0.11 place Dec 31 23:20:02 I ProcessRequest mainserver.cpp:1801 (HandleAnnounce) MainServer: MainServer::ANN Playback Dec 31 23:20:02 I ProcessRequest mainserver.cpp:1803 (HandleAnnounce) MainServer: adding: tv(55ed2f0fec60) as a client (events: 0) Dec 31 23:20:03 I ProcessRequest mainserver.cpp:1801 (HandleAnnounce) MainServer: MainServer::ANN Monitor Dec 31 23:20:03 I ProcessRequest mainserver.cpp:1803 (HandleAnnounce) MainServer: adding: tv(55ed2ec63030) as a client (events: 1) Dec 31 23:20:16 I MythSocketThread(75) mainserver.cpp:7845 (connectionClosed) Playback sock(55ed2f0fec60) 'tv' disconnected Dec 31 23:20:16 I MythSocketThread(88) mainserver.cpp:7845 (connectionClosed) Monitor sock(55ed2ec63030) 'tv' disconnected Dec 31 23:21:02 N Expire autoexpire.cpp:241 (CalcParams) AutoExpire: CalcParams(): Max required Free Space: 12.0 GB w/freq: 7 min Dec 31 23:23:20 N HttpServer70 services/myth.cpp:950 (DelayShutdown) Shutdown delayed 5 minutes for external application. Dec 31 23:27:20 N HttpServer70 services/myth.cpp:950 (DelayShutdown) Shutdown delayed 5 minutes for external application. Dec 31 23:28:02 N Expire autoexpire.cpp:241 (CalcParams) AutoExpire: CalcParams(): Max required Free Space: 12.0 GB w/freq: 7 min Dec 31 23:30:00 N Scheduler scheduler.cpp:3246 (HandleIdleShutdown) Blocking shutdown because of an active encoder Dec 31 23:30:00 N Scheduler scheduler.cpp:3253 (HandleIdleShutdown) Blocking shutdown because of active jobs Dec 31 23:30:00 N Scheduler scheduler.cpp:3257 (HandleIdleShutdown) Blocking shutdown because of delay request from external application Dec 31 23:30:08 I Metadata_20880 jobqueue.cpp:2196 (DoMetadataLookupThread) JobQueue: Metadata Lookup Starting for "The Graham Norton New Year's Eve Show" recorded from channel 65792 at 2020-12-31T22:25:00Z Dec 31 23:30:11 I ProcessRequest mainserver.cpp:1801 (HandleAnnounce) MainServer: MainServer::ANN Playback Dec 31 23:30:11 I ProcessRequest mainserver.cpp:1803 (HandleAnnounce) MainServer: adding: tv(55ed2ec65a50) as a client (events: 0) Dec 31 23:30:11 I ProcessRequest mainserver.cpp:1801 (HandleAnnounce) MainServer: MainServer::ANN Monitor Dec 31 23:30:11 I ProcessRequest mainserver.cpp:1803 (HandleAnnounce) MainServer: adding: tv(55ed2fc75f70) as a client (events: 1) Dec 31 23:30:15 I MythSocketThread(70) mainserver.cpp:7845 (connectionClosed) Playback sock(55ed2ec65a50) 'tv' disconnected Dec 31 23:30:15 I MythSocketThread(86) mainserver.cpp:7845 (connectionClosed) Monitor sock(55ed2fc75f70) 'tv' disconnected Dec 31 23:30:35 I Scheduler scheduler.cpp:2321 (HandleReschedule) Reschedule requested for MATCH 0 1 0 2021-01-01T00:00:00Z EITScanner Dec 31 23:30:35 I Scheduler scheduler.cpp:2438 (HandleReschedule) Scheduled 79 items in 0.2 = 0.07 match + 0.04 check + 0.11 place Dec 31 23:31:20 N HttpServer59 services/myth.cpp:950 (DelayShutdown) Shutdown delayed 5 minutes for external application. Dec 31 23:35:00 I TVRecEvent tv_rec.cpp:1061 (HandleStateChange) TVRec[2]: Changing from RecordingOnly to None Dec 31 23:35:00 I RecThread mythdbcon.cpp:419 (PurgeIdleConnections) New DB connection, total: 13 Dec 31 23:35:00 N RecThread recorders/recorderbase.cpp:491 (FinishRecording) Finished Recording: Container: MPEG2-TS Video Codec: h264 (1920x1088 A/R: 3 25fps) Audio Codec: ac3 Dec 31 23:35:00 I TVRecEvent tv_rec.cpp:825 (FinishedRecording) TVRec[2]: FinishedRecording(65792_2020-12-31T22:25:00Z) damaged recq:<RecordingQuality overall_score="0.8" key="65792_2020-12-31T22:25:00Z" continuity_error_count="26445" packet_count="22679561" /> Dec 31 23:35:00 I CoreContext scheduler.cpp:713 (UpdateRecStatus) Updating status for "The Graham Norton New Year's Eve Show" on cardid [2] (Recording => Recorder Failed) Dec 31 23:35:00 I Scheduler scheduler.cpp:2321 (HandleReschedule) Reschedule requested for CHECK -9 6760 0 UpdateRecStatus2 | The Graham Norton New Year's Eve Show | | With Tom Hanks, Emily Blunt, Jamie Dornan, Hugh Fearnley-Whittingstall, Nish Kumar and Jessica Chastain. Sophie Ellis-Bextor performs Crying at the Discotheque. | fp.bbc.co.uk/m/eixn Dec 31 23:35:00 I Scheduler scheduler.cpp:2438 (HandleReschedule) Scheduled 78 items in 0.1 = 0.00 match + 0.00 check + 0.10 place
comment:51 Changed 4 weeks ago by
It could be that your SatIP box has become unhappy. I have that incidentally when testing and then I reboot the box with the web interface.
I generally have the "Schedule as Group" enabled and then virtual tuners are created when needed. This does not change the load on the SatIP box that much, only a few additional PIDs are selected. There is a switchover point when more than 32 PIDs are selected; in that case all PIDs are received and all PID filtering is done by software somewhere. Note that this can already happen with a single channel, e.g. channel 101 "BBC One London" wants 36 PIDs.
When I test this with the Raspberry Pi 3B then it can get overloaded especially when it is doing EIT on the second input, which can also need the full transport stream. On a computer with a real 1Gb/s network interface this should not be a limitation.
In your configuration, with (IIRC) a number of inputs configured all to receive the same satellite, I would connect all inputs to the same video source, select "Schedule as Group" on all inputs and let the system figure it all out.
comment:52 Changed 3 weeks ago by
Thanks changed to use "Schedule as Group". Can't currently break it so great!. Currently trying to learn enough python to reset the Digibit when the backend is shutdown.
Thanks for supplying the patch; it is now in v32/master.
The patch has been updated for today's master and there have been some issues fixed.
Testing has been done with minisatip connnected to a DVB-S2 card in the same machine as the mythbackend and with a Telestar Digibit R1 box.
Satellite LNB selection via DiSeqC is defined in the Sat>IP protocol but is not yet implemented.
It is possible to use the same Video Source for a /dev/dvb tuner and for a Sat>IP tuner when they are connected to the same source.
The Sat>IP support is still a new and relatively untested feature; if anybody finds problems when testing this please add comments to this ticket.