EventCmdRecStartedWriting/REC_STARTED_WRITING not working for V4L tuners

[kmpatel@…]

The EventCmdRecStartedWriting handler does not seem to be called on my V4L-based masterbackend. All other event handlers seem to work fine, and EventCmdRecStartedWriting is callable thru the use of mythutil --systemevent REC_STARTED_WRITING.

On the other hand, the same configuration of EventCmdRecStartedWriting handler is being called just fine on my separate, HDHomerun-based masterbackend.

MythTV Version : v0.27.4-21-g6fdb2d1 MythTV Branch : fixes/0.27 Network Protocol : 77 Library API : 0.27.20141016-1 QT Version : 4.8.6 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_crystalhd using_dvb using_firewire using_frontend using_hdhomerun using_ceton using_hdpvr using_ivtv using_joystick_menu using_libcrypto using_libdns_sd using_libfftw3 using_libxml2 using_lirc using_mheg using_opengl using_opengl_video using_qtwebkit using_qtscript using_qtdbus using_sdl using_taglib using_v4l2 using_x11 using_xrandr using_xv using_profiletype using_bindings_perl using_bindings_python using_bindings_php using_mythtranscode using_opengl using_vaapi using_vdpau using_ffmpeg_threads using_mheg using_libass using_libxml2

[Jim Stichnoth]

This has been working for me ever since the event was added, for both HD-PVR and HDHomeRun.

Can you attach the "mythbackend -v network" log for an example of a successful recording where the RecStartedWriting event fails to appear?

[kmpatel@…]

during recording, output of mythbackend -v network

[kmpatel@…]

Yeah, I don't have this problem with a HDHomeRun tuner, just the V4L.

As requested. I've attached a file showing the output of "mythbackend -v network"

Also, illustration of the problem on a backend with a V4L tuner. I have 4 event test handlers, shown below:

+---------------------------+-----------------------------------------------------------------------------------------+
| value                     | data                                                                                    |
+---------------------------+-----------------------------------------------------------------------------------------+
| EventCmdRecFinished       | echo `date +"%F %T"` "<-- recording finished: %FILE% %TITLE%" >> /tmp/backend.event.log |
| EventCmdRecPending        | echo `date +"%F %T"` "<-- recording pending: %FILE% %TITLE%" >> /tmp/backend.event.log  |
| EventCmdRecStarted        | echo `date +"%F %T"` "<-- recording starting: %FILE% %TITLE%" >> /tmp/backend.event.log |
| EventCmdRecStartedWriting | echo `date +"%F %T"` "<-- writing file: %FILE% %TITLE%" >> /tmp/backend.event.log       |
+---------------------------+-----------------------------------------------------------------------------------------+

As you can see below, however, that during the recording period (between 7:28 and 8:02) there is no output for "EventCmdRecStartedWriting". But the event handler is configured properly, as witnessed by the manual use of mythutil --systemevent REC_STARTED_WRITING a few minutes later @ 08:14:55.

2015-04-17 07:28:30 <-- recording pending:  Big Cat Diary
2015-04-17 07:29:00 <-- recording pending:  Big Cat Diary
2015-04-17 07:29:30 <-- recording starting: 9130_20150417113000.nuv Big Cat Diary
2015-04-17 07:29:32 <-- recording pending: 9130_20150417113000.nuv Big Cat Diary
2015-04-17 08:02:00 <-- recording finished: 9130_20150417113000.nuv Big Cat Diary
2015-04-17 08:14:55 <-- writing file: %FILE% %TITLE%

[Jim Stichnoth]

I think you uploaded the wrong log file.

[Kmpatel@…]

Im not sure what log you want. I typed the command as requested (ie "mythbackend -v network"), directed to a file and uploaded it. I will happy to upload another file, if you let me know which one you want.

[Gary Buhrmaster <gary.buhrmaster@…>]

Replying to Kmpatel@…:

Im not sure what log you want. I typed the command as requested (ie "mythbackend -v network"), directed to a file and uploaded it. I will happy to upload another file, if you let me know which one you want.

You uploaded a log for a failed BE start (one was already running). You either need to dynamically change the verbose settings for the running instance, exercise your test case, and upload the entire log, or stop your existing BE, start with the command as requested, exercise your test case, stop the BE, and upload that (likely shorter) log file. Typically I prefer to submit the latter, since the log is complete, and only the interesting stuff is in it.

[kmpatel@…]

UPDATED: mythbackend -v network output

[kmpatel@…]

Got it. Sorry for the confusion. Uploaded is an an updated log file. The test case occurs from around 20:18:49 to 20:20:12. Thanks

[Jim Stichnoth]

This is good, thanks!

It turns out that in dtvrecorder.cpp, the REC_STARTED_WRITING event is only sent when it explicitly notes the first keyframe. By default, the recorder ignores everything before the first keyframe, to avoid displaying garbage at the beginning of playback, and so that the seektable frame numbering is accurate.

It may be that your recorder is configured to disable the first-keyframe check, or that it is using the NuppelVideoRecorder class which may be using a different approach altogether.

Could you provide a few more items?

1. What kind of tuner/recorder is it?

2. What is the mysql output of "select * from capturecard;" (and if there are multiple cards, just point out which is the card in question in case it's not obvious)

3. Similar log file, but this time from "mythbackend -v network,record"

[kmpatel@…]

output of mythbackend -v network,record

[kmpatel@…]

capture card mysql info

[kmpatel@…]

Sorry for late response. I've upload the info you are looking for. I don't anything about the first-keyframe check. If it is disabled, I wouldnt know. The video file format is NUV.

The recorder device is a Hauppauge WinTV-PVR USB2. And it is the only recording on the device. I had previously tested a HDHomerun on the same machine but have since removed it.

[kmpatel@…]

on the new test, the recording business starts at "2015-04-20 20:39:30.000625"

[Jim Stichnoth]

Is it possible for you to test the attached 12328_v1.patch?

[kmpatel@…]

are you talking about patching and building mythtv? or patching the existing installation? I think, from the content of the patch, it is the latter, in which case, I can do it, but I would have to develop the know-how first (including how to do it without wiping out existing repo-based installation). If there is a compiled binary I can swap out, that would be easier.

[kmpatel@…]

ok, i download mythtv-0.27.4, patched, built, install and tested. and it seems like your patch works, at least regarding the missing WRITING event. attached is a log file of the test session, and below is a sample of the event handler outputs

2015-04-22 14:33:02 <-- recording starting: 9070 9070_20150422183300.nuv TEST RECORDING
2015-04-22 14:33:05 <-- recording pending: 9070 9070_20150422183300.nuv TEST RECORDING
2015-04-22 14:33:14 <-- writing file: 9070 9070_20150422183300.nuv TEST RECORDING
2015-04-22 14:33:58 <-- recording finished: 9070 9070_20150422183300.nuv TEST RECORDING

[kmpatel@…]

mythtbackend log with 12328_v1.patch

[Jim Stichnoth]

Thanks for patching/building and testing, that's exactly what I was hoping for.

It seems that it works correctly, given that the event fires, and is reasonably placed between the first FILE_WRITTEN (with size 0) and UPDATE_FILE_SIZE events.

[Jim Stichnoth <jstichnoth@…>]

In c07c21e6c5b7f1380cf7e36e7cbcc8763a5cb225/mythtv:

Error: Processor CommitTicketReference failed

GIT backend not available

[Jim Stichnoth <jstichnoth@…>]

In 8f14d3d1e8c798f8a45b3338a33bb71aec877dc7/mythtv:

Error: Processor CommitTicketReference failed

GIT backend not available