Changing channels while watching live tv results in error - Cannot find A/V Decoder (or a black screen)

[William L. DeRieux IV <WilliamDeRieux@…>]

$ mythfrontend --version
Please attach all output as a file in bug reports.
MythTV Version : v0.28-72-g228b05b-dirty
MythTV Branch : fixes/0.28
Network Protocol : 88
Library API : 0.28.20160309-1
QT Version : 5.6.1
Options compiled in:
 linux debug use_hidesyms using_alsa using_oss using_pulse using_pulseoutput using_backend using_bdjava using_bindings_perl using_bindings_python using_bindings_php using_crystalhd using_dvb using_firewire using_frontend using_hdhomerun using_vbox using_ceton using_hdpvr using_ivtv using_joystick_menu using_libcec using_libcrypto using_libdns_sd using_libfftw3 using_libxml2 using_lirc using_mheg using_opengl using_opengl_video using_opengl_themepainter using_qtwebkit using_qtscript using_qtdbus using_sdl using_taglib using_v4l2 using_x11 using_xrandr using_xv using_debugtype using_mythlogserver using_systemd_notify using_bdjava using_bindings_perl using_bindings_python using_bindings_php using_fontconfig using_freetype2 using_mythtranscode using_opengl using_vaapi using_vdpau using_ffmpeg_threads using_mheg using_libass using_libxml2

I am also running Debian/Stretch (testing) and this was compiled using gcc-6.

When starting to watch live tv everything works as expected -- however when I change to another channel it will either exit back to the main menu and display "Could not find A/V decoder" or I will get a black screen.

There were some 0 length nuv files created in the livetv folder, too (seems like the backend may have attempted to restart the recording since it failed -- as the next nuv file was non-zero length but had no audio).

Mythfrontend had also reported that the recordings has 3 or more audio channels (and went as high as 38 channels at one point).

I will be attaching the backend and frontend logs.

Note the log files reference a failing recording due to 'Tuning timeout'. I am using an Analog Capture Card and recording from composite input and thus 'Tuning lock/timeout' is not valid in this context please refer to this bug for more info: ​https://code.mythtv.org/trac/ticket/12572).

Also, I think this issues also happens on scheduled recordings, just not as often -- those recording are sometimes lacking audio (the attached log files do not reference this part, though).

[William L. DeRieux IV <WilliamDeRieux@…>]

mythbackend log

[William L. DeRieux IV <WilliamDeRieux@…>]

mythfrontend log

[William L. DeRieux IV <WilliamDeRieux@…>]

I have been testing several different versions of 0.28 (both from git and the debian stretch/sid repositories) and I have discovered that the issue descbribed here is a direct result of bug#12572 (referenced earlier).

TuningSignalCheck breaks Angalog recordings when a composite/s-video input is used -- after commenting out the lines (as indicated in the supplied patch) I am now able to change channels in Live TV without the issue ocurring.

I know that this functionally might be useful for digital tuners, but if that functionallity is warranted, then TuningSignalCheck really needs to be modified to return: newRecStatus = RecStatus::Recording; if a composite/s-video input is used (as there is no tuning on those inputs).

[William L. DeRieux IV <WilliamDeRieux@…>]

A patch to fix recordings failing on non-tuned inputs.

[michael@…]

Is anybody looking into this, since upgrading to 0.28, all recordings on composite card fail, and causes the backend to segfault.

[JYA]

Please provide a back trace. See wiki on how to produce a back trace.

The patch above is no fix.

[WilliamDeRieux@…]

Replying to jyavenard:

Please provide a back trace. See wiki on how to produce a back trace.

The patch above is no fix.

That's the problem...when using gdb to launch mythfrontend the issue does not generate backtrace.

[WilliamDeRieux@…]

Replying to michael@…:

Is anybody looking into this, since upgrading to 0.28, all recordings on composite card fail, and causes the backend to segfault.

Micheal...for me this did did not gererate a segfault in the backend or frontend.

[WilliamDeRieux@…]

Replying to WilliamDeRieux@…:

Replying to michael@…:

Is anybody looking into this, since upgrading to 0.28, all recordings on composite card fail, and causes the backend to segfault.

Micheal...for me this did did not generate a segfault in the backend or frontend.

This is the command I use to generate a backtrace using gdb
(the same came be done for mythbackend)

$ gdb -ex run mythfrontend
and use 'bt' at the gdb prompt to get the backtrace

[michael@…]

My problem is actualy more like #12572, will add further comments under that bug.

[WilliamDeRieux@…]

Replying to WilliamDeRieux@…:

Replying to jyavenard:

Please provide a back trace. See wiki on how to produce a back trace.

The patch above is no fix.

That's the problem...when using gdb to launch mythfrontend the issue does not generate backtrace.

The main problem in mythtv/mythtv/libs/libmythtv/tv_rec.cpp :: TuningSignalCheck

Is that the code assumes that all inputs are tunable.
Composite, S-Video, and similiar inputs cannot be tuned and when they are used the TuningSignalCheck is causing recordings to fail -- because it returns .

if (signalMonitor->IsAllGood())

either sets RecStatus::Failing / RecStatus::Recording but is never reached -- because the tuning timeout cannot be set on Analog capture cards the option is not exposed through the appropriate UI and thus the .signalMonitor is always in an error state.

else if (signalMonitor->IsErrored()

MythDate::current() > signalMonitorDeadline)

returns RecStatus::Failed, and again when non tuned inputs are used this is always true.

else if (curRecording && !reachedRecordingDeadline && MythDate::current() > startRecordingDeadline)

returns RecStatus::Failing; but is never reached

else

returns NULL; but is never reached

---

The point is that this functions always sets RecStatus::Failed for composite / svideo and as a result causes all recordings to fail.

What we need here is a way to detect the input type and whether or not is can be tuned. If the input can be tuned (DVB, CATV tuner, etc) -- then TuningSignalCheck can be used as is. But for composite/svideo there isn't any point in calling TuningSignalCheck and it should just set newRecStatus = RecStatus::Recording;

[jpoet]

CardUtil::HasTuner() might be helpful. Alternatively, some changes to analogsignalmonitor.cpp to set the "Signal Monitor" in a good state might be the way to go.

I have been (very slowly) working on a new V4L2 encoder recorder "type" which sets the Signal Monitor up 'correctly' for V4L2 encoders. I will try to carve out some more time for that.

[WilliamDeRieux@…]

Replying to jpoet:

CardUtil::HasTuner() might be helpful. Alternatively, some changes to analogsignalmonitor.cpp to set the "Signal Monitor" in a good state might be the way to go.

I have been (very slowly) working on a new V4L2 encoder recorder "type" which sets the Signal Monitor up 'correctly' for V4L2 encoders. I will try to carve out some more time for that.

from my understanding of CardUtil::HasTuner() it only indicates if the hardware has support for tuning and does not indicate if the selected input uses it.

[WilliamDeRieux@…]

Replying to WilliamDeRieux@…:

Replying to jpoet:

CardUtil::HasTuner() might be helpful. Alternatively, some changes to analogsignalmonitor.cpp to set the "Signal Monitor" in a good state might be the way to go.

I have been (very slowly) working on a new V4L2 encoder recorder "type" which sets the Signal Monitor up 'correctly' for V4L2 encoders. I will try to carve out some more time for that.

from my understanding of CardUtil::HasTuner() it only indicates if the hardware has support for tuning and does not indicate if the selected input uses it.

And by input I mean: TUNER (0) / COMPOSITE (1) / S-VIDEO (2) which should not be confused with CardUtil::INPUT_TYPES

Those input values: 0,1,2 are for a
[14f1:8800] Multimedia video controller: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder (rev 05)
Subsystem: [1002:00f8] Advanced Micro Devices, Inc. [AMD/ATI] ATI TV Wonder Pro

[Stuart Auchterlonie]

Moving remaining open 0.28.1 tickets to 0.28.2

[WilliamDeRieux@…]

I opened this issue about 4 months ago (that would have been sometime on or around October 22).

It would seem that this issue has been resolved since then because as of commit: 8db179a4682cfe478fb7bef024fce251e016ee20 I am no longer experiencing a blank screen or messages about the A/V decoder not being found when switching channels in live tv.

I guess this should be marked as fixed (rather than invalid, since it was valid when it was opened).

Thanks.

[paulh]

Thanks for reporting back.