Panic volume buffer

[garyellis]

I get this line several times in the log file just before comskip crashes..Its on a large 3 HR HD file....

"Panic volume buffer"

I'm using version 143...

Any help?

Thanks,

Gary Ellis

[erik]

Yes,
This means the sound format in the broadcast can not be recognized.
Could you first test with build 144 and if it still does not work upload a small recording (50 MBytes) to my FTP server?

[garyellis]

Thanks....I'll load 144 today and see what happerns...

Gary Ellis

[garyellis]

Sorry, I was wrong, I was already using 144.

I'm recording another 4 hour HD show today (golf tournament)...Let's see if I get the same error. If so, then I'll need to figure out how to send you the piece of the file that is causing the problem.. I believe that it is well into the show before the problem occurs, because the log file is very long before it gets to panic volume buffer....

Thanks,

Gary Ellis

[erik]

I assume it will be in the middle of a commercial or some other break during the show
Probably where there is switching between MPEG or AC3 sound or two types of AC3 sound.

If you record in MPEG2 PS you can use the free mpeg2cut2 tool to cut out the part that is causing the problems.

When you set
output_framearray=1
you can see in the generated .csv file where the sound stops

Or you can drag and drop the generated .csv file onto comskipGUI.exe and click at the timeline at the top of the window to see where the sound stops (the green line at the bottom gets flat from then on)

[garyellis]

I'm not figuring it out....

I changed output frame array to 1 and didn't get any csv file..of course since comskip crashed before finishing, it would have to have written it as it went along.

I also cut a 10 minute scene out from commercial to next commercial in the area that i think it crashed..When I ran comskip on that scene..it worked just fine. But, when I ran it on the total 4 hour golf tournament, compskip crashes...I've done it 4 times now on the total.

2 times it had many "panic volume buffers" at the end of the log file..but the other 2 times it did not.

Here is the last 15 or 20 lines of the log file...


start: 103616, end: 104541, len: 30.86s

start: 103616, end: 104541, len: 30s
--start: 104541, end: 104997, len: 15.22s 46.08s
--start: 104997, end: 106356, len: 45.35s 91.42s
--start: 106356, end: 107259, len: 30.13s 121.55s
--start: 107259, end: 107569, len: 10.34s 131.90s

Output: 0 - start: 41 end: 2962
Output: 1 - start: 30676 end: 34633
Output: 2 - start: 43093 end: 49848
Output: 3 - start: 57916 end: 61873
Output: 4 - start: 67494 end: 71448
Output: 5 - start: 89778 end: 93737
Output: 6 - start: 103629 end: 107580
Frame 108963 - Black frame because large scene change of 6, uniform 6855
Resizing cc text array to accomodate 1901 cc text groups.
Resizing scene change array to accomodate 6000 frames.
Frame 117455 - Black frame because large scene change of 6, uniform 554
Resizing cc text array to accomodate 2001 cc text groups.
Frame 119874 - Black frame because large scene change of 1, uniform 6441
Frame 121052 - Black frame because large scene change of 3, uniform 13623



Any ideas what I can try next?

Thanks,

Gary Ellis

[erik]

Try disabling cc decoding to rule out a memory problem in cc decoding.
Set
output_timing=1
that will create a *.timing.csv file that will be written even when comskip crashes till where things go about wrong.
Could you mail me the full log file?
I am interested in "AC3 detected" or "mpeg2 detected" loggings.

[garyellis]

not sure how to disable CC decoding..... I created a line called cc_decoding=0.....we'll see if that did it...

Thanks...I'll let you know what happens,

Gary

[erik]

You need to disable it in the detect_method setting

As the detect method is the sum of 1=uniform (black or any other color) frame, 2=logo, 4=scene change, 8=resolution change, 16=closed captions, 32=aspect ration, 64=silence, 128=cutframe
subtract 16 from the detect_method setting

[garyellis]

Thanks....I figured that out after running it once more.... It crashed again when I had the CC enabled...

So, I changed it to not use CC in the detection method and it went through the full 4 hours without a problem...So, that seems to be it. For my education, what does that mean?

Now that its solved, what can I send you to help? You asked for the log file...do you still want it? Do you want the one that crashes or the one that makes it all the way through?


Thanks a bunch for your help with this...

Gary Ellis

[erik]

Could you enable the CC again and set
output_data=1
in the ini file.
When comskip is running it will produce a dump of the CC data (with the .data extension) that can be analyzed by me.
Comskip will crash but most probably after the CC data interpretation went wrong.
Then you should also send me a .csv file generated with disabled CC and output_framearray=1
When I combine the two I hope to be able to simulate the crash.
If you need access to my FTP server because the files are too large to send otherwise then I will send you username, password and address by PM.

CC means Closed Caption and enabling it will tell comskip to interpret the metatdata that is send along in the MPEG stream. This meta data has all kind of information that can be relevant for the classification between show and commercial. But it is not essential.

[garyellis]

I sent them to your email address...Please let me know that you got them... Looks like comskip works for just over 1 hour before crashing..Let me know that you got the files..

Thanks,

Gary

[Addict]

Hi there. Sorry to bring back an old thread, but I'm seeing the same situation every few recordings from my HD-PVR TS files.

I'm running the donators version 0.80.025.

I have all comskip detect options turned on (255), and will disable CC if I need to...but am curious if the system has been updated to fix this natively.

Thanks for any help! (and a great product...)

[Addict]

Sorry, deleted this post because I posted something inaccurate. Above post is correct.

[erik]

Sometimes the broadcast changes.
Could you test with build 0.80.027?