Audio/VBI failures for nuv recordings

[gregorio.gervasio@…]

With git master, I am having audio/VBI failures for nuv recordings on a WinTV or pcHDTV-3000 (analog port) card:

1. SetInputAndFormat? fails trying to set VIDIOC_STREAMOFF

2011-06-04 17:54:57.697 V4LChannel(/dev/video0): SetInputAndFormat(14, NTSC) (v4l v2) input_switch: 0 mode_switch: 1
2011-06-04 17:54:57.697 V4LChannel(/dev/video0) Error: SetInputAndFormat(14, NTSC) 
                        while disabling streaming (v4l v2)
                        eno: Invalid argument (22)
2011-06-04 17:54:57.699 V4LChannel(/dev/video0): SetInputAndFormat() failed
2011-06-04 17:54:57.699 TVRec(14) Error: Failed to set channel to 6006. Reverting to kState_None
2011-06-04 17:54:57.699 TVRec(14): Changing from RecordingOnly to None

The comments seem to indicate this is only needed for some cards so I made local changes not to fail if this happens. Patch is attached but this is probably not the right way to go.

2. Errors setting VBI and audio input options:

2011-06-04 18:07:41.923 RecBase(14:/dev/video0) Warning: SetOption(vbidevice,/dev/vbi0): Option not recognized
2011-06-04 18:07:41.926 RecBase(14:/dev/video0) Warning: SetOption(vbiformat,NTSC Closed Caption): Option not recognized
2011-06-04 18:07:41.926 RecBase(14:/dev/video0) Warning: SetOption(audiodevice,ALSA:hw:0): Option not recognized
2011-06-04 18:07:41.926 AudioIn Error: unknown or unsupported audio input device ''
2011-06-04 18:07:41.926 NVR(/dev/video0) Error: Failed to create audio device: 
2011-06-04 18:07:41.926 NVR(/dev/video0) Error: Failed to init audio input device
2011-06-04 18:07:42.034 NVR(/dev/video0) Error: Invalid audio device (), exiting

Looks like it's not calling V4LRecorder::SetOption?

3. VBI recording thread exits. This appears to be due to "request_recording" not getting set, causing the main thread loop to exit immediately. Also, FormatCC was not updated for the new VBI extraction code.

I have attached another patch to address issues 2 and 3, Not sure if it's the right way to fix issue 2.

4. Tons of VBI select timeout messages

2011-06-04 18:35:49.472 V4LRec(14:/dev/video0) Error: vbi select timed out

I disabled this message in my local tree.

With these changes, closed captions are still not recorded properly -- a few captions show up but most are dropped. It seems the new VBI extraction code is not working well for me. I haven't been able to debug it yet but have temporarily reverted to the old one (in vbi/vbi.c) for my local tree.

[gregorio.gervasio@…]

Do not abort if VIDIOC_STREAMOFF fails

[gregorio.gervasio@…]

Partial fixes for NVR audio/vbi recording

[otto@…]

Related to point 2., I'm also seeing following errors while recording / watching LiveTV from DVB cards. System has only DVB cards and nothing else.

2011-06-05 12:51:35.641 RecBase(11:) Error: SetOption(): Unknown int option: dvb_on_demand: 0

[patrick@…]

For recording analog video this problem seems to be much more severe. I get this error and no audio is recoreded. Video recording works fine.

[Tianon Gravi <admwiggin@…>]

I can corroborate the analog issues patrick mentioned. I tried tweaking every setting I could find / think of to get my audio working, then I found this bug ticket, applied gregorio's v4l_rec_audio_vbi.patch, and my audio and captions are working again, as is my channel changing, although I have to quit and go back in after I change the channel to get the audio back afterwards.

[danielk]

If you add the line "has_stream_io = false" in V4LChannel::Open() after the current "has_stream_io = ..." line, does that fix the problem requiring the first patch?

[danielk]

Also, please attach full backend logs with "-v record,channel"

[gregorio.gervasio@…]

Here is a (slave) backend log after adding "has_stream_io = false". The recording has video but no audio and no captions, I believe because of problem #2.

[gregorio.gervasio@…]

backend log (-v record,channel) for nuv recording

[danielk]

Is this part really needed?

  QMutexLocker locker(&pauseLock); 
  request_recording = true; 

It shouldn't be...

[Github]

Refs #9825. Workaround for bttv driver.

It appears the driver reports supporting streaming but doesn't actually do so.

Branch: master Changeset: ee9814bdaf82c6d7d47fabf8b013fb1f9baab33f

[Github]

Refs #9825. NVR's parent is V4LRecorder not RecorderBase?.

We were bypassing the V4LRecorder::SetOption?() which handles setting some important variables in the V4L recorder.

Branch: master Changeset: fb5c5531cf92b242ddfa4fd203aa488661a47c6d

[Github]

Refs #9825. The FormatCC signature in RecorderBase? was changed but NVR wasn't updated.

One of the few places I find C++ painfully lacking is the missing overrides keyword and detection of signature changes.

Bug found by Gregorio Gervasio.

Branch: master Changeset: b77b9eba918127e663939bec5f70c4ad10806e6e

[Github]

Refs #9825. Call CloseVBIDevice() after thread is destroyed.

Bug found by Gregorio Gervasio

Branch: master Changeset: b5d3479d7e383c4fa01661f539bde80cc43162b6

[gregorio.gervasio@…]

(Sorry for the delay in responding.)

Without "request_recording = true", the VBI recording thread does not enter the main loop in V4LRecorder::RunVBIDevice(), which is checking for IsRecordingRequested?().

[yiannividalis@…]

Up and including commit 6cf957e I was successfully watching and recording videos on my analog saa7134 recorders by applying the two patches from this ticket. After upgrading to 6027231 I cannot longer apply the patches cleanly, and after removing them completely the sound of the live tv is clicking and the video keeps pausing.

I can no longer watch previously recorded analog shows, the "Please wait" message appears for a second and then it's gone. For some recordings the first frame will appear and then nothing, back to the recordings screen.

Unfortunately, I hadn't watched them before upgrading so I don't know for sure it's the recent commits that are causing this. And I cannot checkout a previous commit due to the change in the schema.

Recordings and live tv from DVB-S and dvb-T are not affected.

The only lines that appear on the host holding the recordings are:

2011-12-01 20:40:43.301979 I [5969] ProcessRequest mainserver.cpp:1356 (HandleAnnounce) - MainServer::ANN Playback
2011-12-01 20:40:43.301990 I [5969] ProcessRequest mainserver.cpp:1358 (HandleAnnounce) - adding: eagle1 as a client (events: 0)
2011-12-01 20:40:43.304689 I [5969] ProcessRequest mainserver.cpp:1470 (HandleAnnounce) - MainServer::HandleAnnounce FileTransfer
2011-12-01 20:40:43.304699 I [5969] ProcessRequest mainserver.cpp:1472 (HandleAnnounce) - adding: eagle1 as a remote file transfer

Anything else I should provide?

MythTV Version : v0.25pre-3851-g6027231 MythTV Branch : master Network Protocol : 70 Library API : 0.25.20111201-1 QT Version : 4.7.2 Options compiled in:

linux release use_hidesyms using_alsa using_oss using_pulse using_pulseoutput using_backend using_bindings_perl using_bindings_python using_bindings_php using_dvb using_frontend using_hdpvr using_iptv using_ivtv using_libfftw3 using_libxml2 using_libudf using_lirc using_mheg using_opengl_video using_qtwebkit using_qtscript using_qtdbus using_v4l2 using_v4l1 using_x11 using_xrandr using_bindings_perl using_bindings_python using_bindings_php using_mythtranscode using_opengl using_vdpau using_ffmpeg_threads using_live using_mheg using_libxml2 using_libudf

[yiannividalis@…]

Ok, trying to see if it was a configuration issue on my part I changed the recording profile of the vl4 encoders from mpeg-4 to rtjpeg and live-tv is ok again. But it has been in mpeg-4 mode since before September, at least.

Is this something that affects this ticket or is this for the users' list? Version still v0.25pre-3851-g6027231

[danielk]

Gregorio, it looks like NVR is using encoding for the same thing that request_recording is used for elsewhere. The proper thing to do is probably to change NVR to use request_recording instead of the encoding variable. But until then you can also just add "request_recording = true;" right after each "encoding = true;" line in NuppelVideoRecorder?.cpp

Yianny, I think you are encountering a different issue. The mpeg-4 profile has some options that make it use a lot of CPU. If you run out of headroom the recorder will just dump frames, it doesn't try to switch off the high CPU options or buffer up a lot of frames to smooth over short term encoding delays. Since the NVR is a legacy recorder this is unlikely to get addressed anytime soon.

[gregorio.gervasio@…]

Adding "request_recording = true;" after all "encoding = true;" lines in NuppelVideoRecorder?.cpp did not work for me -- it looked like V4LRecorder::RunVBIDevice() gets called before request_recording gets set. However, adding the line after "childrenLive = true;" in NVR::SpawnChildren?() worked.

Also, for b77b9eba918127e663939bec5f70c4ad10806e6e, I had to change the NVR::FormatCC() code1/2 parameters from "uint" to "int".

[danielk]

Patch to address error reporting an child thread shutdown.

[danielk]

Gregorio, I've attached a patch which eliminates the encoding variable and also make NVR use the _error variable instead of it's own errored variable. I also sets the requested_recording variable earlier so it doesn't prevent children from running and also moves the childrenLive down to v4lrecorder and renamed it request_helper.

[danielk]

BTW I don't understand why the NVR::FormatCC() would need to take ints. This function takes a uints in V4LRecording I'm wondering if you have some leftover from an earlier patch that changes the signature in V4LRecording to use int.

[gregorio.gervasio@…]

v1 patch seems to let the VBI recording thread run properly. Thanks.

I think you're right about the NVR::FormatCC() parameters -- they work as is. Sorry about that. However, shouldn't they be ints anyway? The function is called with ints in V4LRecorder::RunVBIDevice() and the lower-level code in CC608Decoder::FormatCC() also uses ints.

There are only two issues left for me:

1. I get tons of "vbi select timed out" messages. I have commented out the line in V4LRecorder::RunVBIDevice() in my local tree.
2. VBI60Extractor seems to drop a bunch of captions. I have reverted to the old extractor (in vbitext/*) to make it work.

[Rick Scott <rwscott@…>]

patch for NuppelVideo? live TV channel changing

[Rick Scott <rwscott@…>]

Nuppel video live tv channel changing

While investigating why channel changing live tv with a V4L source was not working, I discovered that the file for the new channel was missing the header that describes the file. So, when the frontend tried to decode the file, recorded as RTjpeg, the "failed to open jump buffer" message came up because a decoder could not be found. I switched the recording format to MPEG4, and I could now switch channels, however there was no audio.

By adding in the StartNewFile? call in ResetForNewFile?, everything seems to be working as it should. I can record in either format, change channels in live tv, with audio.

Possible related tickets, 9825, 9846, 9830, 9868, 10012.

[Github]

Refs #9825. Addresses VBI startup and error reporting in NVR.

Branch: master Changeset: ec6be27ee75948c9301256642e012cf28976feff

[gilson585@…]

I've been using this 'commit-8677f41' patch and it does fix the issue noted in comment 23 without breaking anything. I'd like to see this or some incarnation of it pushed to master.

[sandybigboy@…]

Rick Scott, thanks for the patch. Only with this patch I was able to get an analoge TV (whith SAA7134 tuner) in mythTV 0.24. I'm not sure that there are no side effects (sometimes crashes the frontend), but nevertheless it works.

[danielk]

Rick, thanks for that debugging, but I don't see what adding that StartNewFile?() does. AFAICT NuppelVideoRecorder::StartNewFile?() is called from two places. Reset(), a vestigial function that hasn't been used since before the 0.21 release, and from ResetForNewFile?(). NuppelVideoRecorder::ResetForNewFile?() and it is called from RecorderBase::CheckForRingBufferSwitch?() which calls NuppelVideoRecorder::StartNewFile?() within a few statements of calling ResetForNewFile?().

A new "-v record,channel" log of the channel change with the latest trunk may be helpful...

[rwscott@…]

Replying to danielk:

Rick, thanks for that debugging, but I don't see what adding that StartNewFile?() does. AFAICT NuppelVideoRecorder::StartNewFile?() is called from two places. Reset(), a vestigial function that hasn't been used since before the 0.21 release, and from ResetForNewFile?(). NuppelVideoRecorder::ResetForNewFile?() and it is called from RecorderBase::CheckForRingBufferSwitch?() which calls NuppelVideoRecorder::StartNewFile?() within a few statements of calling ResetForNewFile?().

A new "-v record,channel" log of the channel change with the latest trunk may be helpful...

A little slow in responding, I know ...

I just updated to master, and this no longer seems to be an issue.

[danielk]

Great, thanks for replying.