mythtranscode never completes when transcoding clips with cutpoints

[krizze]

When transcoding mpeg2 recordings that have cutpoints, mythtranscode keeps going forever (Showing over 100% completed in mythweb/system info).

It keeps spitting out: 2008-04-08 20:38:43.063 Fast-Forwarding from 0 to 6630 2008-04-08 20:38:43.092 Fast-Forwarding from 0 to 6630 2008-04-08 20:38:43.120 Fast-Forwarding from 0 to 6630 2008-04-08 20:38:43.150 Fast-Forwarding from 0 to 6630 2008-04-08 20:38:43.178 Fast-Forwarding from 0 to 6630 2008-04-08 20:38:43.207 Fast-Forwarding from 0 to 6630 2008-04-08 20:38:43.236 Fast-Forwarding from 0 to 6630 2008-04-08 20:38:43.269 Fast-Forwarding from 0 to 6630 2008-04-08 20:38:43.299 Fast-Forwarding from 0 to 6630 2008-04-08 20:38:43.328 Fast-Forwarding from 0 to 6630 2008-04-08 20:38:43.356 Fast-Forwarding from 0 to 6630 2008-04-08 20:38:43.385 Fast-Forwarding from 0 to 6630 2008-04-08 20:38:43.414 Fast-Forwarding from 0 to 6630 2008-04-08 20:38:43.443 Fast-Forwarding from 0 to 6630 2008-04-08 20:38:43.472 Fast-Forwarding from 0 to 6630 2008-04-08 20:38:43.501 Fast-Forwarding from 0 to 6630 2008-04-08 20:38:43.529 Fast-Forwarding from 0 to 6630

Problem with fast-forwarding?

[krizze]

Recordings without cutpoints are transcoded as usual, but they are also failing with cutpoints afterwards, so it's not only with mpeg2.

[stuartm]

Can we have the output of mythbackend --version please?

[krizze]

Sorry about that, here it is:

MythTV Version : 16987 MythTV Branch : trunk Library API : 0.22.20080320-2 Network Protocol : 40 QT Version : 4.3.4 Options compiled in:

linux release using_oss using_alsa using_arts using_jack using_backend using_dbox2 using_dvb using_firewire using_frontend using_hdhomerun using_iptv using_ivtv using_joystick_menu using_lirc using_v4l using_x11 using_xrandr using_xv using_xvmc using_xvmcw using_xvmc_vld using_bindings_perl using_bindings_python using_opengl using_ffmpeg_threads using_libavc_5_3 using_live

[krizze]

Nobody else having this problem?

[bill]

Replying to krizze:

Nobody else having this problem?

Yes, I'm having the same problem. When transcoding mpeg2 (or nuv) recordings that have cutpoints, mythtranscode keeps spitting out (in my case its for one cutpoint, just for before the first frame):

2008-06-17 14:25:06.156 Fast-Forwarding from 0 to 1

ie. There seems to be some problem when it tries to fast forward to the first cutpoint.

And like krizzie says, recordings without cutpoints are transcoded as usual.

I've updated everything to run off the trunk version. I thought it might be a protocol mismatch, caused by me mixing versions of different myth* programs, but I don't *think* so. (As I can see all the myth* programs in /usr/local/bin have the same timestamp. ie. from when I did my last "make install")

$ /usr/local/bin/mythbackend --version

Please include all output in bug reports.
MythTV Version   : 17439
MythTV Branch    : trunk
Library API      : 0.22.20080612-1
Network Protocol : 40
QT Version       : 4.3.2
Options compiled in:
linux release using_oss using_alsa using_backend using_dbox2 using_dvb
using_frontend using_hdhomerun using_iptv using_ivtv using_joystick_menu using_lirc 
using_v4l using_x11 using_xrandr using_xv using_bindings_perl using_bindings_python 
using_opengl using_ffmpeg_threads using_live

And I see mythtranscode is being called with the following options:

/usr/local/bin/mythtranscode -j 1045 -V 3 -p autodetect -l

I tried running it by hand, but adding a "-v all" debugging option, to get the same problem, but with this (more verbose) output:

2008-06-17 14:25:06.156 Fast-Forwarding from 0 to 1
2008-06-17 14:25:06.157 Dec: DoFastForward(1 (4), do discard frames)
2008-06-17 14:25:06.157 Dec: DoRewind(1 (4), do discard frames)
2008-06-17 14:25:06.157 Dec: FindPostion(0, search not adjusted) --> [0(1808)]
2008-06-17 14:25:06.157 NVD: SeekReset(0, 1, do flush, do discard)
2008-06-17 14:25:06.157 VideoBuffers::DiscardFrames(1): UUAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
2008-06-17 14:25:06.158 VideoBuffers::DiscardFrames(): AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA -- done()
2008-06-17 14:25:06.158 VideoBuffers::DiscardFrames(1): AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA -- done
2008-06-17 14:25:06.213 NVP: ClearAfterSeek(1)
2008-06-17 14:25:06.233 Fast-Forwarding from 0 to 1
2008-06-17 14:25:06.234 Dec: DoFastForward(1 (2), do discard frames)
2008-06-17 14:25:06.234 Dec: FindPostion(0, search not adjusted) --> [0(1808)]
2008-06-17 14:25:06.234 NVD: SeekReset(0, 0, don't flush, do discard)
2008-06-17 14:25:06.234 VideoBuffers::DiscardFrames(0): AAAuuAAAAAAAAAAAAAAAAAAAAAAAAAA
2008-06-17 14:25:06.234 VideoBuffers::DiscardFrames(0): AAAaaAAAAAAAAAAAAAAAAAAAAAAAAAA -- done
2008-06-17 14:25:06.234 NVP: ClearAfterSeek(1)
2008-06-17 14:25:06.307 Fast-Forwarding from 0 to 1

Also nuvexport (from the same svn version) is not working anymore. (That complains about "Must specify --fifodir to use --fifosync"; No idea if that's a related problem.)

[nzhook]

Im also getting this issue, however with a little more investigation it appears that the fast forwarding messages disappears if I change the -v level in the command being run (eg. mythtranscode --showprogress -j 8284 -V 3 -p 27 -l -v important) and the showprogress shows that the process is progressing through the video.

The line 5765 of libs/libmythtv/NuppelVideoPlayer.cpp outputs the given message for every frame once a cutpoint is hit hence slowing the process down quite a bit. I also found that becuase this is logged my var file system (where logs are stored) was filling up and stopping anything else from working (eg. MySQL)

However.... on top of this that function never returns a false, hence the process goes on forever (with the verbosiy set to important as shown above the progress shows '5830% Completed @ 113.306 fps' or 'Processed: 117402 of 59904 frames(4696 seconds)'

This issue seems IS caused by the removal of the == NULL check (qt4 port) on line 5743 of the same file, adding a similar check in allows the transcode to complete. Bug introduced with svn #16790

[anonymous]

I am having the infinite transcode behavior as well when use nuvexport. AMD64 as well

[nzhook]

The following is the patch I have been running since making the comment regarding the fix for the issue, this has been working since that time with no sign o the issue. Im posting this before doing an SVN update so someone may have already applied a similar patch, but I dont want to loose the change...

--- libs/libmythtv/NuppelVideoPlayer.cpp (revision 17827) +++ libs/libmythtv/NuppelVideoPlayer.cpp (working copy) @@ -5744,9 +5744,9 @@

if (m_playbackinfo)

m_playbackinfo->UpdateInUseMark?();

• if (honorCutList) Qt4 port: removed dm_iter == NULL &&

+ if (videoOutput->GetLastDecodedFrame?()->frameNumber == 0 && honorCutList) Qt4 port: removed dm_iter == NULL &&

dm_iter = deleteMap.begin();

- +

if (GetDecoder()->GetFrame?(0))

return false;

if (eof)

[scott.milliken@…]

I have built a new system from SVN head on October 4, 2008, and the problem still exists in trunk. However, application of the patch listed above does work around the issue.

[stuartm]

(In [18809]) Fixes lossy transcoding of recordings which was broken during when the QT4 branch was merged to trunk. Thanks to xris and others for testing. Original fix from nzhook. Closes #5180, #5812