Client loosing timing info

[jcjefferies]

Once or twice a week I have a recording playing on the client which looses the timing info so “Skip” no longer works. Last night the timing info disappeared 47 minutes into a 65 minute recording and the numbers on the time bar all become zero. This morning the same recording played normally on the server so I could skip to the end but several retries on the client all loose timing at around 47 minutes. I mainly use Skip to bypass the adverts as usually it is more reliable than Comskip. This also happened on the previous version.

Enclosed is Client log of test on same file jumping forward normally until at 11:35:37 all the timing goes wrong. Enclosed is Server NRecord log covering the same period.

[mvallevand]

Yes there seems to be a major problem in the time line around 793509648 bytes into the file. I know with my NMT code handling this is really tough even with Timing.Info

Code:

2012-02-06 11:45:36.992    [DEBUG][1]    OnKeyDown() called: {CTRL}Right, Control
2012-02-06 11:45:37.046    [DEBUG][1]    User is trying to skip.
2012-02-06 11:45:37.046    [DEBUG][1]    Current position is: 4.20000014855759E-06
2012-02-06 11:45:37.046    [DEBUG][1]    Asking for position: -1.9999942779541
2012-02-06 11:45:37.046    [DEBUG][1]    After skipping position reports as: 4.20000014855759E-06
2012-02-06 11:45:37.046    [DEBUG][1]    OnKeyDown() done. Took 54 ms

Martin

[sub]

I'd like to look into this, but I'm a bit snowed under with day job stuff right now.

Bump the thread in a few days and I'll take a look.

[jcjefferies]

Thanks Sub will do. Its not a show stopper just an irritation as cannot skip adverts when it happens.

[jcjefferies]

I have another recording made early this morning where the client looses position timing info after about 4:30 minutes into 35 minute recording.

Server displays position time and saves correct timing info all the way to the end.

The client saves the correct position info to the database up to just before 4:30

Client detects there is good “Position” info in the database created by the client or server by offering
the “Resume” option but always starts from the beginning on this recording.

Both my Vista clients on different hardware behave exactly the same

I have found another older recording from back in October with a Zero position database entry and this looses timing position info at 15 seconds into the recording on the client. The time bar starts at about 9 seconds counting up to 15 then quickly jumps to 16, 17, 23, then all zeros. The same recording on the server the position clock counts to 17, jumps to 25 then continues and plays normally and display correct position data. At times the position clock increments perhaps a little more erratically than on most recordings.

Looking again more closely at the first recording above on the server the timing jumps from 4:35 to 4:39 at the point where the client looses the position info but the timing displays correctly and it continues playing normally without any jump is sound or video. It looks as if the clients cannot deal with timing info that is slightly corrupted. Although the clients save the position info up to the suspect bit they seem to refuse to use the position data to “Resume” on these files even when it is before the suspect bit. I do seem to remember have a recording many months ago where the server lost the position info also.

[jcjefferies]

BUMP

Sub last week you said that you wanted to look into this but were busy and to Bump the tread later. As you will see above I have found clues to what causes the problem.