Defective TS files with displayed zero length

[johnsta]

> This logging isn't really intended for what you're using it for,
> and files can get overwritten by later recordings, but it should
> be good enough though. Just after the completion of a recording
> (or simultaneous recordings), the file(s) will be there. I don't
> need all the files - hopefully you'll be able to catch one or two
> that related to a problem recording.

I started three recordings at 6 pm, two of which were defective and
one of which was ok. All three files ran on npvr.

BBC-6-8pm_20180208_18002000.ts - runs ok on vlc

CNN-6-7pm_20180208_18001900.ts - "partially defective" - plays on VLC
using progress bar controls, but displays 00:00 duration.

FNC-6-7pm_20180208_18001900.ts -- "fully defective" - doesn't run at
all on vlc.

In all three cases, I cancelled the recordings after two minutes,
and restarted them with the names:
CNN-6-7pm-restart_20180208_18001900.ts
FNC-6-7pm-restart_20180208_18001900.ts
BBC-6-8pm-restart_20180208_18002000.ts

The one non-defective file did not involve a channel change on the
tuner. The two defective files both required channel changes on their
respective tuners.

I'm attaching three zip files:

part1-fw-1745-1808-180208.zip
part2-fw-1745-1808-180208.zip
-- all file-writer data from 17:45 to 18:08 (in two parts)

nrecord-log-1359-1804-180208.zip
-- all nrecord.log data from 13:59 to 18:04

Thanks,

John

[sub]

How did you split those files into part1/part2? It looks like it's missing stuff, including the start of the recording, which is the bit I wanted to capture.

[johnsta]

> How did you split those files into part1/part2? It looks like it's
> missing stuff, including the start of the recording, which is the
> bit I wanted to capture.

Since the file-writer file gets deleted and recreated at the top of
almost every hour, I used "tail -f" to capture the file as it changed.
I tested this out earlier in the day and it seemed to work. What was
strange this time is that the tail output file was 1.395G in size,
which was much larger than other trials. I decided that must be
because I canceled the three recordings and restarted them, creating a
lot more data. I zipped up the tail file, but it was bigger than your
system allowed, so I used "split" to split it into two parts, one 700M
and one 695M in size, and I zipped those up into two separate zip
files.

Could you just double-check those two parts that I sent you. Maybe
there was some kind of duplication of data, and the data you need is
in there somewhere.

Out of curiosity, is there a gap in the time stamps? At what time
does the gap occur? If I know that, maybe I can try something
different.

I can try it again tomorrow. Do you have a suggestion for a better
way to handle it?

[sub]

Unfortunately that tailed file is unusable. I can't tell where the recordings start etc, and its got a huge pile of nothing taking up at least half the space.

With those registry settings, you should get a file-writer-*.txt files created with each recording. Each new recording will write to a new file, and all of the activity for that recording will go to a single file. One of those new files might overwrite an old file. Ideally you can reproduce the problem with a recording, or series of recordings, and the last recording will have the problem, and you'll be able to supply the original file writer txt file, and it'll show me what happened in that last recording.

[johnsta]

> Unfortunately that tailed file is unusable. I can't tell where the
> recordings start etc, and its got a huge pile of nothing taking up
> at least half the space.

> With those registry settings, you should get a file-writer-*.txt
> files created with each recording. Each new recording will write
> to a new file, and all of the activity for that recording will go
> to a single file. One of those new files might overwrite an old
> file. Ideally you can reproduce the problem with a recording, or
> series of recordings, and the last recording will have the
> problem, and you'll be able to supply the original file writer txt
> file, and it'll show me what happened in that last
> recording.

That's what I thought was supposed to happen, but it's not what's
happening. It's writing to only one file, file-writer-15308.txt. At
the top of almost every hour, it deletes this file and restarts a new
file with the same name.

If what you're saying is true, then there's apparently a bug in the
file-writer creation code. Perhaps you could check this out and send
me a new version.

One thing I'll try in the morning is deleting the registry key and
then setting it again. Maybe that will force the file-writer logic to
reset, and will jog the logic enough that it will start working
correctly. This is probably wishful thinking, but stranger things
have happened.

[sub]

The number is a thread id. Yes, it could overwrite previous file when a new recording is started, if Windows reuses the same thread. It's working the way it was intended to, but for slightly different scenarios I use for testing in my own environment.

At
the top of almost every hour, it deletes this file and restarts a new
file with the same name.

This is happening when a new recording is started.

[sub]

Here is a version which uses a different file naming, which should make it more straight forward for you to collect the logs.

[johnsta]

> The number is a thread id. Yes, it could overwrite previous file
> when a new recording is started, if Windows reuses the same
> thread. It's working the way it was intended to, but for slightly
> different scenarios I use for testing in my own environment.

> "At the top of almost every hour, it deletes this file and
> restarts a new file with the same name."

> This is happening when a new recording is started.

> Here is a version which uses a different file naming, which should
> make it more straight forward for you to collect the logs.

> Attached Files File Type: zip NPVRWriter.zip (48.6 KB, 1
> views)

I replaced NPVRwriter.ax at 8:34am.

At 9am this morning there were three recordings in progress:

Bloomberg-7-10am_20180209_07001000-0.ts
CNBC-9am-noon_20180209_09001200.ts
Varney & Company_20180209_09001200.ts

The Bloomberg recording had started at 7am, and restarted at 8:34am.
The other two started at 9am. The CNBC recording was OK, and the
Varney recording was defective.

I'm attaching two files:

fw-0904-180209.zip
-- contains the four file-writer files at 9:04 am
nr-0904-180209.zip
-- contains nrecord.log for the preceding half hour.

John

[sub]

Sorry, another version. I've added more logging (and changed the filenames slightly).

[johnsta]

> Sorry, another version. I've added more logging (and changed the
> filenames slightly).
> Attached Files File Type: zip NPVRWriter.zip (48.8 KB, 2 views)

Same as last night. At 6pm, CNN* and FNC* recordings are defective,
and BBC* was OK.

http://jxenakis.com/gdgraphics/nr-1820-180209.zip
-- nrecord.log
http://jxenakis.com/gdgraphics/fw-1820-180209.zip
-- file-writer files