"--plist" option produces bogus values

Where all the bugs are reported and discussed
Post Reply
wolpertinger
Posts: 4
Joined: Sun Jun 16, 2013 9:51 pm

"--plist" option produces bogus values

Post by wolpertinger » Sun Jun 16, 2013 10:03 pm

Hello,

I am running the donator version 0.81.052. When using the "--plist" option to create a marker file for EyeTV, the resulting file contains totally bogus values. Example:

<array>
<integer>50622202537578000</integer> <integer>117915</integer>
<integer>1464997883083920000</integer> <integer>117981</integer>
<integer>1646334838377604800</integer> <integer>4660552625251334226</integer>
</array>

I have tested this on three different files. In every case incorrect results are produced.

Can you look into this please?

Thanks,

Steve

erik
Site Admin
Posts: 3298
Joined: Sun Aug 21, 2005 3:49 pm

Re: "--plist" option produces bogus values

Post by erik » Mon Jun 17, 2013 6:23 pm

Yes,

Please post a .txt file and the manually created correct file you want.

wolpertinger
Posts: 4
Joined: Sun Jun 16, 2013 9:51 pm

Re: "--plist" option produces bogus values

Post by wolpertinger » Tue Jun 18, 2013 6:48 pm

Hello Erik,

I am not sure what you mean by "the manually created correct file". The Comskip help says that the --plist option "Outputs a mac-style plist for addition to an EyeTV archive as the 'markers' property". As I do not know what unit EyeTV uses for the integer values of it's markers, I cannot create them myself from frame numbers or miliseconds.

Might it be possible that there is an error in the formating of the values that are written to the plist file that causes those seemingly random values?

The Text file that corresponds to the plist file in my first post has the following content:

FILE PROCESSING COMPLETE 106477 FRAMES AT 2500
-------------------
1 3274
83496 94749
106476 106477

If this is not what you meant, please clarify.

Thanks,

Steve

erik
Site Admin
Posts: 3298
Joined: Sun Aug 21, 2005 3:49 pm

Re: "--plist" option produces bogus values

Post by erik » Wed Jun 19, 2013 5:47 pm

OK, that helps
And how should the required output for eyeTV look like?

wolpertinger
Posts: 4
Joined: Sun Jun 16, 2013 9:51 pm

Re: "--plist" option produces bogus values

Post by wolpertinger » Thu Jun 20, 2013 12:54 pm

The current output format itself is fine.

It's only the values themselves that are wrong.

Thanks,

Steve

erik
Site Admin
Posts: 3298
Joined: Sun Aug 21, 2005 3:49 pm

Re: "--plist" option produces bogus values

Post by erik » Fri Jun 21, 2013 4:42 am

That is what I understood but how do you expect me to correct that if you don't tell me what the values should be?

wolpertinger
Posts: 4
Joined: Sun Jun 16, 2013 9:51 pm

Re: "--plist" option produces bogus values

Post by wolpertinger » Fri Jun 21, 2013 12:03 pm

Sorry, there seems to be some misunderstanding.

I was of the impression that as Comskip offers the -plist option that *you* already knew how to calculate those values. :?

Anyway, I did some research and found the sources of a Linux port of Comskip on the XMBC forums (http://forum.xbmc.org/showthread.php?pid=1281840). There in it's comskip.cpp i found the following code:

Code: Select all

flagFiles.plist_cutlist.printf(
					"<integer>%ld</integer> <integer>%ld</integer>\n"
					, (unsigned long)((start) / fps * 90000)
					, (unsigned long)((end) / fps * 90000));
So EyeTVs marker numbers are calculated as Framenumber / Frames_per_second * 90000. I also did some experimenting to verify that this calculation is in fact correct.

I hope everything is cleared up now. :wink:

Thanks,
Steve

erik
Site Admin
Posts: 3298
Joined: Sun Aug 21, 2005 3:49 pm

Re: "--plist" option produces bogus values

Post by erik » Fri Jun 21, 2013 1:38 pm

Sometimes I incorrectly think I know something so I rather double check and assume I do not.
Thanks, this helps. Will be corrected in next build (with unknown ETA)

erik
Site Admin
Posts: 3298
Joined: Sun Aug 21, 2005 3:49 pm

Re: "--plist" option produces bogus values

Post by erik » Sun Jun 23, 2013 11:50 am

Build 0.81.054 in the donators area is supposed to solve this problem
Can you test?

Post Reply