TS-Doctor program blocked at "PCR Check" level

[TUK]

High again,

-  Initial problem : The program blocks during "PCR check" : at the top of the main frame, one can see "Cypheros TS Doctor ( Ne répond pas)".
In the past when I tested  TS Doctor, it appeared sometimes the same indication  " Ne répond pas" corresponding to a temporary blockage, but after a while the program continued and finished the job.

- After a few more investigations, VLC indicates that from time 21,4' to 22,25' there is a "bad file descriptor" on my video which last 2 hours ( 7,7 Go). Moreover, out of this bad area, VLC reads the file without any difficulty.

- I have then tried to use the raw cutter to try to eliminate the bad area but no success and confirmation of the problem at 17% of the total duration.

- Now, after reading answers to post "First PCR not found 1 2 ", I have used "open trimmed"  and played with the raw cut beginning and end functions. I succeded ( by chance ?) to save once the last 2/3 of the file and the new file is clean ( no errors).
I said may be by chance because it seems that the "raw cut at the end" value cannot exceed 2,14 Go. Consequently if I try to save the first 20' of the video it does not work !!!

- Question : is that true that there is a limit to both  "raw cut"  and, if yes, how to proceed in my case to eliminate this dammed 1 mn of bad recording ( knowing that the rest presents a good quality) ?

Conditions :
  - video file : XX .TS of 7,7 Go for 2 hours ( AVC/MP2)  DVT ARTE
  - PC : W7, Intel processor i7  3,5 GHz,  64 bits, RAM 16 Go
  - TS Doctor : last version

Regards

[Cypheros]

Hi,

the PCR check can take some time if the source drive is slow or connected via network. Errors in the file can slow down the process, too.
Take a look at the HD Led and the Taskmanager if the TS-Doctor is still processing data.

The RawCutter is a tool to cut out samples for later upload.

The only way is to open the file with TS-Doctor and cut out the "bad" area with the cutting feature. 

You could try to activate the "Enhanced PCR check" under Settings/Preferences/Correction Behavior or send the file though the "TS Packet Filter" under Expert tools. Leave all PID checkboxes unchecked but select "Delete invalid packets".

If this is not working, I can offer you a FTP server to upload the file and I'll try to find a way to fix it.

[TUK]

Hi,

- Thanks very much for your answer. I have tried to better identify the problem and before sending you my heavy file ( 7,7 Go) I let you know what appends using the raw cutter method which is operating but time consumming : see after.

- As already said, my case can be descrided as is : I work on a file XX .TS of 7,7 Go  ( AVC/MP2)  /  French ARTE DVB-T. After several investigations I can say that there is one single "very bad area" of 40", the remaining 2 hours are clean ( I used VLC to locate the problem area and visualize the video, and later TS doctor ).

- Results concerning of the use  of the " raw cutter" :

   - First I got the beginning and the end of the bad area with VLC ( let say sart T1 =21',35 , end T2=22',42 ).

   - I converted these data in "Packets Values PVT1 and PVT2", conversion factor =  max time (VLC) / max Nb of packets ( raw cutter),  and  I tried first to eliminate the bad area directly : no success.

- Now I fed the raw cutter with ( 0 , PVT1 ) to get the good part 1, and (PVT2, max Packets) to get the good part 2. It works not so badly after readjusting these values but the cutted area was not 40" but more, let say a minute.

-In order to improve the result, I had to fed the raw cutter 10 times with 10 couples of packet values on both sides ( video 1 and video 2 ) to come very close to the 40". Indeed I built a plot each time I got a new file Y = size of the file given by the PC , X = time line (close to the problematic area ).
On video 1(starting at 0 ), the curve is linear to a certain point and looks like a saturation and the raw cutter  is no more operating, I stopped the process but I got each time a file.
On video 2, it is different : the curve is linear, no saturation but a clear stop corresponding to the maximum informations which can be recovered.
The procedure is time consumming mainly because it seems to me that the correspondence  time / packet is not valid in that case. I dream of a simpler procedure !

Sorry to be a bit long. If these informations are not useful, I can send, as proposed, the file. In the meantime I will try to apply the other methods you propose.


Regards

[TUK]

Hi again,

- "Enhanced PCR checks" : no success, The PCR verification stops at 17% and the green LED in "off"

- "TS packet filter" : no success, the program stops at 16% after a while.

Regards

[Cypheros]

Hi, I guess the problem is, that you have missing data between T1 and T2, so the bitrate is not constant. You can not estimate the exact packet position if the bitrate is changing too much, especially at the problem area.

You can use the RawCutter to delete anything before T1 and anything after T2, so you get the pure problem area. Maybe it's a good idea to do the cutting not exact at T1 but 10 MBytes before that point and 10 Mbyte after T2. The resulting file size should be easy to transfer.

I guess this file will also crash TS-Doctor during the PCR check. If you could sent me this problem area I will try to find a way to prevent such a crash in the future.

[TUK]

Hi,

- No problem to send the file, give me a FTP server. Right, there is a crash each time one try to use direct processing.

- As you see in my last post I try to cut before T1 and after T2 but as far as there is not a correspondance time line / packet values ( due to the crash area ? ) it does not really work exept by entering data ( PVT1 and PVT2) by iteration with sometimes crash of the program. ( see attached doc).

Question : would it not be possible to enter in "Raw cutting" timeline data( T1,T2) instead of packet data ,(packet data staying obviously the baseline approach in all other cases)?


Miscellenaous : a pannel difficult to interpretate in French ! ( see attached doc )

[Cypheros]

Send you a PM with the access informations.

The problem with the time is, that the time is relative (yes, Einstein told us the same) 

But the play time is relative to the first PCR timer found. There are so many things that can go wrong with timers. The only reason why the RawCutter is not crashing the same way the TS-Doctor is doing during PCR check is, that the RawCutter is ignoring the timers.

[TUK]

Hi,

- Impossible to transfer the 7,7 Go file : indeed I cannot even copy it to any support ( another hard disk etc.). Moreover the upload rate is less than 0,5 Mbit/s ! I leave the transfer open for the next 2 hours just  in case things improve  !
I had recently "quasi" crashes : during the process, the led stop emetting, but waiting a while ( a minute or more ) the process ends up quite normally. I can look to find this type of file if it is of any interest ?

- Thus the video recordings are submitted to Einstein's law, I better understand the difficulties I am facing day after day ...
Let me try another "theoritical" approach. The way I obtain the best results is to enter manually  increasing packet values ( video 1) or decreasing packet values ( video 2). As far as I obtain a new file, I continue. When the program crahes, I stop iterating and  know that I cannot go further. The problem is that  it takes a long time. Now I imagine the same process automated, a loop with increments of delta packets with a test : if the last delta correspond to conditions of a crash, the program stops and keep the file at delta -1. Is it possible to envisage such processing ?

Don't worry if the answer is no , even if every body knows  that there are several ways to skin a cat, I will not bother you anymore on that topic ...
Thanks anyway

[Cypheros]

Hi,

sorry but another User is uploading his "problem file" and so you have to share the bandwidth with him. But the FTP server is open all the time and you can upload as long as you want with one exception. Every 24 hours the connecting is resetted. A dirty trick of my internet provider to prevent continous usage of the internet connection. If you use a FTP client like Filezilla, your client will try to reconnect and resume the upload after a few seconds.

Thanks for your idea of checking the last error position. Maybe I can develope a new fixing or debug methode for such a situation. 

[TUK]

Hi,

I better understand my low upload rate but the problem is my file. It is the first time that I have a file stored on a HD that I can watch ( as any other ) but which is impossible to copy or send away...

I will try later to send another type of file blocking, but only for a while, the program.