Defective TS files with displayed zero length

[johnsta]

> johnsta, do you have the logs showing the recording of that last
> file you posted?

I'm attaching the log files.

A couple of additional notes:

• I created this zip file at about 6:30 pm. I came home just before
  6 pm. Around 6:05 I checked and there were two defective files being
  recorded. I restarted NRecord, and now they're recording OK.
  
  
• If you look at the log file for the last half hour, you'll see the
  above activity. The file BBC* was completely OK. The file CNN* plays
  in VLC, but the length is shown as zero ("partially defective"). The
  file FNC* won't play at all ("totally defective"). So I have a
  bonanza of information all at once. (I can provide all three files if
  you want.)
  
  
• After killing and restarting NRecord at 6:05, all three files are
  recording correctly.
  
  
• I just installed NPVR 4.0.5 yesterday morning. I'm seeing more
  defective files, and I get the feeling that the new version is making
  the problem worse.

Thanks,

John

[Graham]

It would probably be useful if you are able to upload the three before and the three after files.

[mvallevand]

I've attached an updated NPVRTSReader4.ax that should cope better with files like this. With this update, this file is playing for me.

I tried this and the file plays but the timeline is still off.

Martin

[sub]

I tried this and the file plays but the timeline is still off.

if you'd had the timing.info, like johnsta had on his machine, it would have used it and reported the correct duration.

[mvallevand]

if you'd had the timing.info, like johnsta had on his machine, it would have used it and reported the correct duration.

I am still having trouble getting the WBZ file to play with NextPVR with or without timing.info. The reader-automap.log seems to be choosing the wrong PIDs from PMT PID 90 and not the good ones that come later in PMT PID 78 Removing those streams NextPVR plays the file with a good timeline.

Martin

[johnsta]

> It would probably be useful if you are able to upload the three
> before and the three after files.

As I said, these three recurring recordings all started a 6 pm. At
6:05, I checked and there were two defective files being recorded. I
restarted NRecord, and the new recordings were all OK.

Here are the three "before" recordings that started at 6pm:

http://jxenakis.com/gdgraphics/BBC-6-8pm...8002000.ts
^^^ OK

http://jxenakis.com/gdgraphics/CNN-6-7pm...8001900.ts
^^^ Partially defective (plays in VLC, but displays 0 duration)

http://jxenakis.com/gdgraphics/FNC-6-7pm...8001900.ts
^^^ Totally defective (doesn't play at all)

However, since I let the "after" recordings run to completion, the
lengths of the three "after" files is over 4 GB, which is more space
than I have on my web site.

If you really need them, then ask me again, and I'll try to send them
one at a time. Otherwise, I hope that the files described in the next
message will serve the same purpose.

[johnsta]

The following two files may be helpful.

I created these files at 11 pm last night. The recurring recording of
the BBC at 11 pm was "totally defective," so I canceled the recording
after a couple of minutes.

Then I started a new BBC manual recording, and let that run for a
couple of minutes before canceling it.

So the first file is totally defective, while the second file is OK.

http://jxenakis.com/gdgraphics/BBC-11pm-...3000000.ts
^^^ Totally defective -- recurring recording starting at 11 pm and canceled

http://jxenakis.com/gdgraphics/BBC-11pm_...3002310.ts
^^^ OK -- manual recording starting at 11:05 pm, and canceled after a few minutes

Perhaps comparing these two files will help.

[mvallevand]

So the first file is totally defective, while the second file is OK.

It is not defective it is a valid transport stream. With sub's recent patch and timing.info it seems to play fine in NextPVR wih timeline.

The problem is there are a few valid packets in the beginning of the file that some players don't handle, likely from the previous channel, previous show, the tuning process o perhaps in NextPVR's back to back manual recording logic. Restarting simply changes the tuning logic so you won't get those extra packets.

Martin

[johnsta]

> So the first file is totally defective, while the second file is
> OK.

> It is not defective it is a valid transport stream. With sub's
> recent patch and timing.info it seems to play fine in NextPVR wih
> timeline.

> The problem is there are a few valid packets in the beginning of
> the file that some players don't handle, likely from the previous
> channel, previous show, the tuning process o perhaps in NextPVR's
> back to back manual recording logic. Restarting simply changes
> the tuning logic so you won't get those extra packets.

> Martin

Thanks for the information on how to play these files on a modified
version of NextPVR on my own computer. However, I need to be able to
play these files on other computers, on Portable VLC or Windows Media
Player, or send them to friends and family to play on their own
computers.

So please tell me the bottom line: Is this bug going to be fixed?

Another question: If I reinstall an old version (such as
NPVRSetup_4_0_4_170820.exe), will that still work and solve the
problem by recording valid files?

Thanks,

John

[mvallevand]

However, I need to be able to
play these files on other computers, on Portable VLC or Windows Media
Player, or send them to friends and family to play on their own
computers.

Technically that could be is against the license of NextPVR. Even your recording of all thiose news casts raises concerns.

So please tell me the bottom line: Is this bug going to be fixed?

As I mentioned the files are valid and it may not even be caused by a NextPVR bug. If you want files that are more portable, remux them with ffmpeg before sending them out.

Martin