jump-bug in (current) recordings

[Schnurps]

Hi,

I noticed a bug with playing (current) recordings in VOMP 0.2.4 / VDR 1.2.6:
The time seems to not update correctly, 1 sec in the timeline are about 5 sec in real.
So when i skip a minute/10 sec back, je jumps much too long ahead...

Can anybody confirm this?

Schnurps

P.S.: By the way, I still have problems with Audio / Video syncronisation in LiveTV.

[Schnurps]

cp. http://www.vdr-portal.de/board/thread.php?postid=503369

Seems that more users are affected.

[MarkC]

It sounds like the demuxer is not counting the frames properly. I know about one possible problem: if more than one frame begins in the same PES packet, the demuxer will not count them all. But I looked at the VDR code and it seems to guarantee that each frame will start in a new packet. I notice that tobi_w and Toxic-Tonic are using VDR 1.4, so it can't be the VDR version.

Would it be possible for you to make a small amount of one of these recordings available on the 'net for me to download and examine? I probably won't need a lot... one or two megabytes should be enough. If you don't have anywhere to put it then I'll open up ftp on my box for you.

[MarkC]

Thanks, I downloaded the files you provided.

The recording works fine with CVS vompclient. I forgot that there hadn't been a dongle release since I fixed this bug.

So... it will be fixed in 0.2.5 (I hope!)

[Schnurps]

Okay, great! :-)
Then I now look forward to Vomp 0.2.5!

André

[dingo35]

Reading this thread and the comments on vdrportal.de, I believe a lot of people are awaiting the release of the fixed dongle. Is it possible to upload a temporary file for all who "suffer" from this annoying bug?

Seems strange the bug is already solved but nobody can enjoy this new software....?

[MarkC]

Reading this thread and the comments on vdrportal.de, I believe a lot of people are awaiting the release of the fixed dongle. Is it possible to upload a temporary file for all who "suffer" from this annoying bug?

Seems strange the bug is already solved but nobody can enjoy this new software....?

I know... 0.2.4 was done in a bit of a rush. This bug was fixed a week after the release, but I don't think we realised just how long it would be until 0.2.5, or how many people had the problem.

I'll find time to build a cvs-snapshot dongle over the weekend.

[MarkC]

Snapshot dongle available:

http://www.zen50618.zen.co.uk/vomp/vomp-dongle-cvs20060818

[Chris]

Apologies everyone, I wasn't aware it was fixed and in CVS all this time. I am away for work (again) but I will get all this straightened out when I get back.

[dingo35]

@MarkC, thanks, will try immediately...

@Chris, since you are providing us with this marvellous software for free I think "apologies" are not appropriate here...

Thanks again & keep up the good work!

[Schnurps]

Hey Mark,
thanks for the Dongle-Snapshot. I tested it the last days, and the problem described above is solved. Great!!! :-)))
But I now had some crashes of tne mvp-client: when i skip too quickly with yellow,blue, |< or >|, the mvp reboots immediately. I get the bootup screen, and that screen stops at status 3/5.

Any idea? :-)

André

[MartenR]

Hmm... interesting!
I have the same problem of sporadic crashes in the windows port.
First, I though it is a problem of the windows devices implementation, but if it is also present in the mvp version...
@MarkC and Chris
If I remember properly your UK DVB-T channels have one frame per PES packet, thus if the error have something to do with the several frames per pes packet patch, you and Chris won't detect it.
I'll try to track the error mistake down in the windows debug environment at the weekend, if I have some free time, but I don't know how far a get, since it is a sporadic error hard to reproduce, but now, I know where to search.

Marten

[MarkC]

If I remember properly your UK DVB-T channels have one frame per PES packet, thus if the error have something to do with the several frames per pes packet patch, you and Chris won't detect it.

Yes, all recordings of UK channels that I have seen start each frame in a new PES packet. They also have a PTS for every frame, while some German channels (including the sample Schnurps gave me) only have a PTS every 12 frames (i.e. one per I-frame).

VOMP actually still doesn't cover the case where two frames start in the same PES packet. I need to fix this, but since VDR chops the video into 2K packets, it is unlikely that more than one frame start code will appear in the same packet. There also appears to be code in VDR (cVideoRepacker class) to ensure that each frame starts in a new packet in the recording, but I'm not sure if this is in use yet (there are some 'TEST' #ifdefs that refer to this class, at least in 1.4.1.) That won't help with recordings from previous versions of VDR though.

When I made this latest fix, I did plenty of stress-testing by skipping around like crazy, including skipping across and near PTS discontinuities, and didn't experience any problems, so it could be dependent on the format of the recording, or maybe I was just lucky.

[MartenR]

So I have made some tests with the windows version, sometimes after the skipping in the time code display no valid time code is displayed, sometimes a time code much greater than the actual time have to be. If you don't skip this is fixed, after a second, but if you skip, while such a false time code is displayed, vomp crashed.
@Schurps: Can you please confirm, that the timecode in the OSD is annomaly before the jump crashes. If it is the case the bug is the same on windows and mvp and I know where I have to look.

Marten

[Schnurps]

I have to test this, cannot remember... :-)
What I have noticed is, that the audio/video is asynchronous after a skip, and it needs 2-3 seconds to re-synchronise. Perhaps this is associated with your report?

Schnurps