[is this a bug or a request?] Since the last update to mythtv-backend-32.0-1.30.20220510git26079f815a I get regular aborts at the same address. It is now fixed in master. I am actually on f34 about to go to f36 but the same mythtv version is in both repositories. See thread http://lists.mythtv.org/pipermail/mythtv-users/2022-May/409711.html http://lists.mythtv.org/pipermail/mythtv-users/2022-June/409736.html Can we please have a new build (even for f34). Bug fix was commited on 5/June. Regards
New packages are building now on koji. They take several hours to complete. Note that RPMFusion admins have removed the f34 build target, so I can no longer push builds against that distro. You will need to upgrade to f35/f36 to have access to the latest mythtv builds. I am on vacation this week and responses may be sparse.
Please report back and let us know if this fixes the issue.
(In reply to Andrew Bauer from comment #1) > New packages are building now on koji. They take several hours to complete. > > > Note that RPMFusion admins have removed the f34 build target, so I can no > longer push builds against that distro. You will need to upgrade to f35/f36 > to have access to the latest mythtv builds. Fedora koji did the same on Tuesday. https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/WBORO72RN3RZBVWMVHQ4O2YZCFEQGNZA/
I am now running f36, fully updated, and I get the same crash. I now turned off EIT scan to reduce the number of crashes, but in the past I still had a few crashes a day even so. So far I see here https://ftp-stud.hs-esslingen.de/pub/Mirrors/rpmfusion.org/free/fedora/updates/36/x86_64/repoview/mythtv-backend.html that the current package is still mythtv-backend-32.0-1.30.20220510git26079f815a.fc36.x86_64 which I am on. In short, as I originally requested Can we please have a new build. Bug fix was committed on 5/June. If a new build was done on koji then I guess it just needs to be pushed out. I will check daily and report back. TIA
Patience grasshopper. Package building is a process that can take up to two weeks (usually less) for new packages to hit the stable repo. The new mythtv packages I built earlier this week have just reached the testing repo as of this morning. If you don't want to wait another week for the packages to reach stable, then enable rpmfusion testing to get them now.
This may be related to my problem so I thought it should be mentioned. $ ls -l /dev/dvb total 0 drwxr-xr-x 2 root root 120 Jun 11 13:37 adapter-OPEN-ELEC-1 drwxr-xr-x 2 root root 120 Jun 11 13:37 adapter-OPEN-ELEC-2 drwxr-xr-x 2 root root 120 Jun 11 13:37 adapter-OPEN-ELEC-3 drwxr-xr-x 2 root root 120 Jun 11 13:37 adapter-OPEN-ELEC-4 drwxr-xr-x 2 root root 120 Jun 11 13:37 adapter-OPEN-ELEC-5 drwxr-xr-x 2 root root 120 Jun 11 13:37 adapter-OPEN-ELEC-6 drwxr-xr-x 2 root root 120 Jun 11 13:37 adapter-OPEN-ELEC-7 lrwxrwxrwx 1 root root 19 Jun 11 13:38 adapter0 -> adapter-OPEN-ELEC-1 lrwxrwxrwx 1 root root 19 Jun 11 13:38 adapter1 -> adapter-OPEN-ELEC-6 lrwxrwxrwx 1 root root 19 Jun 11 13:38 adapter2 -> adapter-OPEN-ELEC-2 lrwxrwxrwx 1 root root 19 Jun 11 13:38 adapter3 -> adapter-OPEN-ELEC-7 lrwxrwxrwx 1 root root 19 Jun 11 13:38 adapter4 -> adapter-OPEN-ELEC-3 lrwxrwxrwx 1 root root 19 Jun 11 13:38 adapter5 -> adapter-OPEN-ELEC-4 lrwxrwxrwx 1 root root 19 Jun 11 13:38 adapter6 -> adapter-OPEN-ELEC-5 As you can see, the adapters are renamed to "adapter-OPEN-ELEC-?" and a symlink created to the original "adapter?" (not the same number). This is done such that the names are stable, being USB tuners in a known socket. A few days ago, when I turned off the EIT scan, by accident I scrolled beyond dapter-OPEN-ELEC-7 (in mythtv-setup Capture cards list) and noticed that there was an unexpected entry for adapter0/frontend0 which I never created. And it had EIT scan enabled. I deleted this entry. Now without any EIT scanning I had no abort for three days of recording all programs in two channels (different multiplexes). This leads me to think that the aborts I saw when I thought EIT was off, it was actually on. So the problem seems related to EIT scan. I will still wait for the new build to arrive at "updates" and then enable EIT scan to see how it goes. HTH
I am now running f36 and I just received the new mythtv build from rpmfusion. kernel ====== Linux e7.eyal.emu.id.au 5.17.14-300.fc36.x86_64 #1 SMP PREEMPT Thu Jun 9 13:41:46 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux mythbackend =========== MythTV Version : v32.0-v32.0-36-g7077a824d2 MythTV Branch : fixes/32 Network Protocol : 91 Library API : 32.20200101-1 QT Version : 5.15.3 Options compiled in: linux debug use_hidesyms using_alsa using_jack 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_joystick_menu using_libcec using_libcrypto 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_system_libbluray using_system_libudfread 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 using_libmp3lame package ======= 32.0-1.36.20220605git7077a824d2.fc36 I hope it includes the latest patch. After a few hours (with EIT scan enabled) I got an abort (see gdb log below), 10 minutes after today's first recording started. This recording then restarted and proceeded to complete without more aborts. =================== gdb output Core was generated by `/usr/bin/mythbackend --logpath /var/log/mythtv -v channel,eit --loglevel=debug'. Program terminated with signal SIGABRT, Aborted. #0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44 44 return INTERNAL_SYSCALL_ERROR_P (ret) ? INTERNAL_SYSCALL_ERRNO (ret) : 0; [Current thread is 1 (Thread 0x7f3fa77fe640 (LWP 2787228))] ... Thread 1 (Thread 0x7f3fa77fe640 (LWP 2787228)): #0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44 #1 0x00007f41284d1ca3 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78 #2 0x00007f41284819c6 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #3 0x00007f412846b7f4 in __GI_abort () at abort.c:79 #4 0x00007f412873be40 in std::__glibcxx_assert_fail(char const*, int, char const*, char const*) (file=file@entry=0x7f412abc8013 "/usr/include/c++/12/array", line=line@entry=217, function=function@entry=0x7f412ac117d8 "constexpr const std::array<_Tp, _Nm>::value_type& std::array<_Tp, _Nm>::operator[](size_type) const [with _Tp = unsigned char; long unsigned int _Nm = 184; const_reference = const unsigned char&; size"..., condition=condition@entry=0x7f412abc8000 "__n < this->size()") at ../../../../../libstdc++-v3/src/c++11/debug.cc:60 #5 0x00007f412a5ce04a in std::array<unsigned char, 184ul>::operator[](unsigned long) const (this=0x7f3f9c0106e4, __n=<optimized out>) at /usr/include/c++/12/array:217 #6 std::array<unsigned char, 184ul>::operator[](unsigned long) const (__n=<optimized out>, this=0x7f3f9c0106e4) at /usr/include/c++/12/array:214 #7 TSPacket::StartOfFieldPointer() const (this=0x7f3f9c0106e0) at mpeg/tspacket.h:218 #8 MPEGStreamData::AssemblePSIP(TSPacket const*, bool&) (this=0x7f40fc0233d8, tspacket=0x7f3f9c0106e0, moreTablePackets=@0x7f3fa77fd7bf: true) at mpeg/mpegstreamdata.cpp:312 #9 0x00007f412a5ce580 in MPEGStreamData::HandleTSTables(TSPacket const*) (this=0x7f40fc0233d8, tspacket=0x7f3f9c0106e0) at mpeg/mpegstreamdata.cpp:874 #10 0x00007f412a5d8630 in MPEGStreamData::ProcessTSPacket(TSPacket const&) (this=0x7f40fc0233d8, tspacket=...) at mpeg/mpegstreamdata.cpp:1064 #11 0x00007f412a5cf2b6 in MPEGStreamData::ProcessData(unsigned char const*, int) (this=0x7f40fc0233d8, buffer=0x7f3f9c0106e0 "G@", len=376) at mpeg/mpegstreamdata.cpp:988 #12 0x00007f412ab7c792 in DVBStreamHandler::RunTS() (this=0x7f40fc02e540) at recorders/dvbstreamhandler.cpp:266 #13 0x00007f412ab81b4e in DVBStreamHandler::run() (this=0x7f40fc02e540) at recorders/dvbstreamhandler.cpp:119 #14 0x00007f4128980447 in QThreadPrivate::start(void*) (arg=0x7f40fc0131a0) at thread/qthread_unix.cpp:331 #15 0x00007f41284cfe1d in start_thread (arg=<optimized out>) at pthread_create.c:442 #16 0x00007f41285555e0 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
For completeness, after enabling EIT scan and leaving it on overnight I had a further burst of 25 aborts in 1h. There were probably two recordings at the time.
Have you reported this upstream? The authors will have a much better chance of figuring this out and producing a fix.
An issue was now opened on MythTV repo https://github.com/MythTV/mythtv/issues/589
Thanks, I've subscribed to the issue
New packages containing the proposed fix are building now. https://github.com/MythTV/mythtv/commit/811dad0e91b223bcd3e6f17950e81d296d93fc65
Guys - New packages with the proposed fix to this issue are now available in the RPMFusion repos so I am going to close this one out. Feel free to create a new bug report if the problem, or a variant of this problem, continues to occur.