dvr-ms timing off becuase of dual-core CPU?

[engnz]

I just installed 1.0.16 and my dvr-ms recordings show wrong durations for the shows. The 18min recording below shows up as 1h 35mins @50fps. See FFMpeg output below.

I've been using 99.12 on a single core CPU in the past with no problems and recently upgraded to dual-core. Enclosed is the recording log.

Is this a problem in the DVB-S source (NZ Freeview) itself or the way in which the DVR-MS file is written?




===========================
FFmpeg version SVN-rUNKNOWN, Copyright © 2000-2007 Fabrice Bellard, et al.
configuration: --enable-static --enable-memalign-hack --enable-libmp3lame --en
able-xvid --enable-gpl --enable-libfaad --enable-libfaac --enable-w32threads --e
nable-liba52
libavutil version: 49.3.0
libavcodec version: 51.38.0
libavformat version: 51.10.0
built on Mar 12 2007 19:22:21, gcc: 3.4.5 (mingw special)
datapos2: 3262

Seems stream 1 codec frame rate differs from container frame rate: 25.00 (25/1)
-> 50.42 (605/12)
Input #0, asf, from 'G:\TV\How 2\How 2_20071021_17451800.dvr-ms':
Duration: 01:39:45.0, start: 0.000000, bitrate: 847 kb/s
Stream #0.0: Audio: mp2, 48000 Hz, stereo, 256 kb/s
Stream #0.1: Video: mpeg2video, yuv420p, 720x576, 15000 kb/s, 50.42 fps®
Output #0, dvd, to 'G:\TV\How 2\How 2_20071021_17451800-b.mpg':
Stream #0.0: Video: mpeg2video, yuv420p, 720x576, q=2-31, 15000 kb/s, 25.00 fp
s©
Stream #0.1: Audio: mp3, 48000 Hz, stereo, 256 kb/s
Stream mapping:
Stream #0.1 -> #0.0
Stream #0.0 -> #0.1
Press [q] to stop encoding
error, non monotone timestamps 164250 >= 157050
error, non monotone timestamps 164250 >= 160650
error, non monotone timestamps 175050 >= 167850
error, non monotone timestamps 175050 >= 171450
[dvd @ 0080E444]buffer underflow
[dvd @ 0080E444]buffer underflow
error, non monotone timestamps 175050 >= 171450
frame= 5144 q=0.0 size= 103436kB time=207.2 bitrate=4090.1kbits/s

[sub]

I've got a dual core machine here, and have never noticed any problems like this, so I doubt its to do with the CPU.

It might be worth trying the Cyberlink or ATI mux to see if it performs any better. The mux filter is mostly responsible for this timing stuff. I cant think what would be causing the dvr-ms to start misbehaving in this way though.

[engnz]

Not sure if is makes a difference but mine is an AMD dual core not an Intel one. The above recording was done when the system was under load doing a 6hr Xvid ffmpeg transcode. Both CPUs were running at about 59%.

Do you know if the dvr-ms mux filter is sensitive to system load? I read somewhere that dvr-ms is the most tolerant format for glitches in the data stream. I tried Cyberlink in the past but the SRT was out of sync during playback.


What happens if I change the following in config.xml to "false"?
<ForceSingleProcessorAffinity>true</ForceSingleProcessorAffinity>

[-stattik-]

You can also set the affinity for ffmpeg to a single processor (via Task Manager) and test that out.

[sub]

Not sure if is makes a difference but mine is an AMD dual core not an Intel one.

I'm also on an AMD dual core.

[sub]

Do you know if the dvr-ms mux filter is sensitive to system load? I read somewhere that dvr-ms is the most tolerant format for glitches in the data stream

I guess like anything it could be affected by high system load, or poor disk performance. In generate the dvr-ms mux is pretty good, but some people have had problems with it on occassions.

[engnz]

Switched to Cyberlink 5.0.0.727 mux. Timing problems seems better but can't tell for sure as the GBPVR got stuck with a .NET 2.0 runtime error below.

Came back from work and GBPVR still thinks its doing a recording 7 hrs back. Had to do a system reboot to recover. Recording logs enclosed.

Is this a problem with my version of mux?


=================================
0000: 41 00 70 00 70 00 6c 00 A.p.p.l.
0008: 69 00 63 00 61 00 74 00 i.c.a.t.
0010: 69 00 6f 00 6e 00 20 00 i.o.n. .
0018: 46 00 61 00 69 00 6c 00 F.a.i.l.
0020: 75 00 72 00 65 00 20 00 u.r.e. .
0028: 20 00 67 00 62 00 70 00 .g.b.p.
0030: 76 00 72 00 72 00 65 00 v.r.r.e.
0038: 63 00 6f 00 72 00 64 00 c.o.r.d.
0040: 69 00 6e 00 67 00 73 00 i.n.g.s.
0048: 65 00 72 00 76 00 69 00 e.r.v.i.
0050: 63 00 65 00 2e 00 65 00 c.e...e.
0058: 78 00 65 00 20 00 31 00 x.e. .1.
0060: 2e 00 30 00 2e 00 32 00 ..0...2.
0068: 37 00 38 00 32 00 2e 00 7.8.2...
0070: 31 00 36 00 32 00 35 00 1.6.2.5.
0078: 37 00 20 00 30 00 30 00 7. .0.0.
0080: 30 00 30 00 30 00 30 00 0.0.0.0.
0088: 32 00 35 00 20 00 69 00 2.5. .i.
0090: 6e 00 20 00 6d 00 70 00 n. .m.p.
0098: 67 00 6d 00 75 00 78 00 g.m.u.x.
00a0: 5f 00 35 00 2e 00 30 00 _.5...0.
00a8: 2e 00 30 00 2e 00 37 00 ..0...7.
00b0: 32 00 37 00 5f 00 2e 00 2.7._...
00b8: 61 00 78 00 20 00 35 00 a.x. .5.
00c0: 2e 00 30 00 2e 00 30 00 ..0...0.
00c8: 2e 00 37 00 32 00 37 00 ..7.2.7.
00d0: 20 00 34 00 31 00 30 00 .4.1.0.
00d8: 36 00 37 00 39 00 39 00 6.7.9.9.
00e0: 35 00 20 00 66 00 44 00 5. .f.D.
00e8: 65 00 62 00 75 00 67 00 e.b.u.g.
00f0: 20 00 30 00 20 00 61 00 .0. .a.
00f8: 74 00 20 00 6f 00 66 00 t. .o.f.
0100: 66 00 73 00 65 00 74 00 f.s.e.t.
0108: 20 00 30 00 30 00 30 00 .0.0.0.
0110: 31 00 38 00 66 00 63 00 1.8.f.c.
0118: 63 00 0d 00 0a 00 c.....

[sub]

Is this a problem with my version of mux?

Yes. 5.0.0.727 is known to cause a crash like this (see module name mpgmux.ax in error message).

A good mux is 5.0.1307.

[bigbus01]

I have been having the same trouble with recording time also. If I record with my HVR-1600 QAM, then times are about 4x the actual show times. If I record on the same PC with my ATI HDTV Wonder (over the air) the times are accurate. I don't think the problem is the dual core. I have in the past gone in and reset the MUX to something else, done a recording and then set it back to dvr-ms and then it is ok for a while. After a period of time (or several recordings) it goes back to reporting the wrong show length.

The files play back fine except when you want to fast forward (it takes forever to get through a show--the FF steps are based on 1 minute and the show appears to be 4 hours long for a 1 hour show). Also on these recordings, when you want to fast forward, PVR2X remembers where you were the last time you hit FF and starts there again (which means by the time you watch the whole show, you have actually fast forwarded through the entire show--very annoying)

As I said, the OTA card is reporting the right file length so I think it is related to the QAM card. Any ideas?

Bigbus

[engnz]

Hi Bigbus01. What kind of FPS and bitrate does your recorded video stream report? Mine has ridiculous ones like 50fps.

Has this worked fine before and only started happening recently like me? Does this happen on both your single-core and dual-core servers?

Yes the FF problem when this happens is a pain. In addition, recorded subtitles will not sync up even though they are fine on LiveTV.