Green Blocks on DGIndex Screen working with .tsp files from Dishnet DVR-625

[jk]

Green Blocks on DGIndex Screen

I have two issues, and I am hoping that someone (hopefully DG) will be able to help me, at least with the first one.

1) I have a set of .tsp files that I copied to my hard disk from my DishNet DVR-625. Some of these work very well with DGIndex 1.4.0. Some others result in screen full of Green blocks. I have seen a few threads on this forum about Green blocks, but they all pertain to VOB files. Mine is with .tsp files. Here's what I do to reach the Green blocks screen. Filename used is an example.

- I run DGIndex
- From File -> Open, highlight es8014.tsp, and click on Open
- On the File List window, click on OK
- DGIndex program runs for a few seconds, and then a pop-up error message is displayed, that says "WARNING! Opening GOP is not closed. The first few frames may not be decoded correctly."
- I click on the OK button on the error message window, which closes it.
- A couple of seconds later, the DGIndex screen filled with Green blocks, except for a few blocks along the top edge. All menu items are enabled except the "Stream" menu.

This happens with several of my .tsp files. How can I solve this?


2) The second issue is with files that I have successfully demuxed. I have a few .mpa and their corresponding .m2v files that I created through DGIndex. I run these, in pairs, through DVDPatcher (only the .m2v) and IFOEdit (both files, specifying the audio delay), to make short DVD scenes. Upto this point, everything works fine. Now, I also wish to combine VOBs, and make chapters in the combined VOB. (I have successfully made chapters in the uncombined individual VOBs, using CellTimes.txt) The methods that I have used in IFOEdit, to do this, gives me the error "INTERNAL ERROR: additional data required but no free space in input buffer". (I can give the exact steps that I follow, but I believe that this is a known issue, and I am hoping that someone already knows the way around.) When the DVD authoring is finally completed, the it plays without audio except for the part that corresponds to the first of the combined VOBs. I had noticed that the audio delays for the individual VOBs were different. Is that the reason why in the combined video, only the audio that corresponds to the first VOB (first in the set of smaller VOBs that I combined) played, and the rest didn't play?

Thanks in advance.

JK

[jk]

I was reading other threads, and saw that DG usually asked users to ftp files that needed to be diagnosed. I went ahead and uploaded my file also at the ftp server. Unfortunately, I had no way of uploading only the first few MBs of the file, so I ended up FTP-ing a large file. Hope it doesn't cause any problems. The filename is es8014.tsp

Thanks again,
JK

[neuron2]

Please do not cross-post! I deleted the other copy.
:readrule:

Also, put separate problems in separate threads. Your problem 2 belongs in the DVD authoring forum, certainly not here.

I'll look at your file.

[neuron2]

When I deleted the 790,000 bytes of zeros at the start of the file, it decoded fine! It's Indian music.

Now I'll find out why the zeros are bothering DGIndex. In the meantime, HEdit is your friend.

[neuron2]

I have it fixed. I was looking for a transort sync byte only within the first 188 bytes of the file, which is normally OK. But your file has a lot of leading junk. So I increased it to look in the first 1,000,000 bytes and I made the sync byte emulation more robust to prevent the increased parsing depth from creating any problems.

It will be in Version 1.4.1 final. In the meantime, use a binary editor to remove the junk.

You might want to investigate why some of your files have this leading junk. If it goes beyond 1,000,000 bytes of zeros, you're on your own.

[jk]

Thanks, DG, for the quick analysis.

First of all, let me apologize for having inadvertently posted my questions on two different threads. By the time I realized and figured out that I should, ideally, have opened a new thread, I had already, by mistake, posted my issues in an existing thread which I was reading until then. And yes, I'll split different issues into appropriate threads. Sorry, I'm learning. Thanks for pointing these out.

I am not sure how the leading junk got in there. All I did was to copy the files from my DVR-625's hard disk after connecting it to my PC, mounting it and reading it using the Ext2Fsd drivers. The file that I FTP-ed to your server was the smallest file that I had problems with. If this 37MB file had 790 K bytes of zeros, I wonder how many leading zeros there will be in some of the 3GB and 4GB files that I have the same problem with.

Thanks again.
JK

[neuron2]

If this 37MB file had 790 K bytes of zeros, I wonder how many leading zeros there will be in some of the 3GB and 4GB files that I have the same problem with. My final solution just skips all leading nulls, no matter how many there are. I trust that you find version 1.4.3 satisfactory.

[jk]

Sure! I am looking forward to see and use ver 1.4.3. In the meanwhile, I have been using HEdit to trim my "problem" files. From one of my .tsp files, I cleared 621,268,991 leading nulls! Yes, 621 million.

If I can suggest an enhancement/feature for DGIndex, here's one:

As you know very well, the current version of DGIndex allows TRIMming of the video file by using "[" and "]" as the begin and end markers. If would be very helpful if the user could specify multiple pieces to be TRIMmed out of the same video file, which, when demuxed, will be written out as a single m2v (and its corresponding mpa) file. i.e., multiple TRIMmed pieces to be joined, and treated as a single, continuous video file. The scenario that I go through where such a feature would be very useful is when I demux .tsp files that are two-hour movies with frequent two-minute commercial breaks. It would be very convenient to specify multiple trim-points on the scrollbar along the bottom of the DGIndex screen, as below,

[__________] [_____________] [______]

and then select the "demux" option.

I understand that TRIMming is not what DGIndex is mainly intended to be doing. Still, just a thought.

Another wish-feature is for the frame number to be displayed as the scroll pointer is moved along the scroll line.

Thanks for all the help.

JK