EDL files incorrect in eyetv?

[Phillie14586]

It would have to have been a stealth update to EyeTV if the output has changed. I don't remember any updates to EyeTV for a long time.

[chico]

It would have to have been a stealth update to EyeTV if the output has changed. I don't remember any updates to EyeTV for a long time.

My copy is 3.6.1 (7120) - April 17, 2013. I'll get an earlier version, do some recordings, and see if the resulting video files comskip correctly or not.

[erik]

@Chico

You did send me three log files

) from_mpg = log from original EyeTV .mpg file.
This file is confusing comskip as it is adding a lot of video frames causing misalignment of the comskip output with the actual video.
I would like to have this recording uploaded to the ftp server

2) from_mp4 = log from exported (without compression) H.264 .mp4 file.
This one seems to be processed normally. Can you confirm the markings are correct?

3) from_m4v = log from failed comskip of compressed (handbrake) .m4v of same video.
comskip fails to decode this file and aborts.
I like to receive the first say 100MByte of this file.

[chico]

@Chico

You did send me three log files

1) from_mpg = log from original EyeTV .mpg file.
This file is confusing comskip as it is adding a lot of video frames causing misalignment of the Comskip output with the actual video.
I would like to have this recording uploaded to the ftp server

√ Sent to /chico/source_videos/0000000017dd5498.mpg

Sorry it's so big...that's why I compress these things!

This is the original recording from EyeTV. It Comskipped but the markers were all off by a fixed amount.

2) from_mp4 = log from exported (without compression) H.264 .mp4 file.
This one seems to be processed normally. Can you confirm the markings are correct?

Yes. I originally reported that the markers were not set correctly, but after retesting several times I think I must have made an error. The markings are indeed correct.

3) from_m4v = log from failed comskip of compressed (handbrake) .m4v of same video.
comskip fails to decode this file and aborts.
I like to receive the first say 100MByte of this file.

√ Sent to /chico/source_videos/Breaking Bad S5E13 (To'hajiilee).m4v

I accidentally sent the whole file instead of the first 100MB. Sorry...

Since arriving home for the weekend, I've been testing various things. It appears that by exporting the original EyeTV .mpg recordings to .mp4 non-compressed containers (via the EyeTV app), Comskip does its usual excellent job of finding the commercials.

However, there seems to be something broken with Comskip handling EyeTV's .mpg recordings. Comskip usually finds the commercials but mis-marks them. I tested several recordings and for each recording the offset is constant for each marker within the recording, but the offset is different for each different recording.

I have a number of EyeTV recorded .mpg files which Comskip just fails on (even though it can properly handle the same file when exported as an .mp4). I have uploaded the logs of one of these: /chico/zipped_logs/mpg_fails-mp4-ok.zip

I also tried these tests with an earlier version of EyeTV but the Comskipping still failed.

My next tests will be with older versions of Comskip. I'll post back when I get those results.

Thanks for your time and support on this.

[erik]

Can you start the ftp upload of a .mpg file and simply abort after say 100mbyte
WHatever was uploaded will stay on the ftp server and is good enough to test
Don't use Internet explorer but a real ftp client for the upload

[chico]

Can you start the ftp upload of a .mpg file and simply abort after say 100mbyte
WHatever was uploaded will stay on the ftp server and is good enough to test
Don't use Internet explorer but a real ftp client for the upload

Hi Erik - Made some interesting progress.

Using a single EyeTV recording, with comskip81_056_donators, the recording comskips but is mismarked, as discussed above.

But with comskip81_039_donators, the recording is correctly marked, as it used to be.

I have uploaded the single EyeTV .mpg file (trimmed to 100MB) and the logs from comskip processing using both versions 039 and 056 (/chico/source_videos/Portlandia_039_&_056.zip)

I am in the process of trying to determine the version of comskip where the mismarked EyeTV recordings first occurs.

I still tend to think that there's something strange with the EyeTV .mpg container, because some EyeTV recordings are properly processed by comskip (although are mismarked) while others fail altogether. Whatever is wrong with it, it seems to confuse the latest version(s) of Comskip.

So I'll keep trying to find something more definitive about the comskip/EyeTV interaction...

[chico]

I am in the process of trying to determine the version of comskip where the mismarked EyeTV recordings first occurs.

Hi Erik - Here's what I've found so far:

Using the full version of the 30 minute program which I uploaded previously (/chico/source_videos/Portlandia_039_&_056.zip/0000000017e49be0_trimmed.mpg):

With Comskip version 81_056: Comskip generates incorrect markers.

With same file using Comskip version 81_055: infinite loop, must manually quit Comskip.

With same file using Comskip version 81_054: infinite loop, must manually quit Comskip.

With same file using Comskip version 81_053 and before: Comskip generates correct markers.

I have uploaded the logs and associated data for each of these runs: /chico/zipped_logs/053-056_logs.zip

Well, the good news at least is that Comskip was previously able to correctly generate and place the EyeTV markers…hopefully that functionality can be restored to the latest builds without excessive effort.

Please let me know if there is any additional testing or information I can provide.

...chico

[erik]

Weird

When I test build 0.81.056 with your mpg file it creates the right markers so its difficult to find the problem.

I may be able to solve the problem with the .mv4 files.

[chico]

Weird

When I test build 0.81.056 with your mpg file it creates the right markers so its difficult to find the problem.

I may be able to solve the problem with the .mv4 files.

Yeah, weird.

I've gone back to 81.053 and re-comskipped all my recent recordings. Works as well as ever. But with the newer builds I get the issues listed above every time.

If you can think of any variables for me to play with I'm willing to try stuff and test. I don't know how many others are experiencing the problem (the thread starter for one) but I also suspect not everyone religiously updates their comskip installation once they've got something functioning ok. I was happily running 81.039 until recently, when I upgraded to see what improvements had been made.

The .mv4 fix would be nice because it would let me comskip files that I've compressed and no longer have the original .mpg.

Anyway, thanks again for the time and support on this. I remain truly impressed by comskip.

[erik]

You may consider adding
two_pass_logo=0
to your comskip.ini to solve the probelm of the changing logo's