Open ivanski opened 4 years ago
I hadn't seen that yet, I wonder what causes it to get a number so large?
Not sure, it's generated by EyeTV. I do see the IDs constantly increasing over time, but it's not monotonic. On my EyeTV setup, I see: 567575880, 571539480, 577594681, 578656680, 581137080, 581828281, 601792200, 609220801, 611459880, 611463480, 611463481, 611467080, 611477880, 611479680, 611553480, 611562780, 611557080. Some of these are pretty old (Dec 2018) but the last 3 gave me trouble.
Recording date/time seems to be part of the formula; 611463480, 611463481 were simultaneous recordings at 8pm Pacific on Sunday on different non-adjacent channels. Maybe it's as crude as f(unix time) + an additional number for collision avoidance, but if that were the case I imagine more people would be seeing it.
Interestingly 7:58PDT Sunday
is 1589770680
in unix time, and the delta between that and the 611463480
ID is 978307200
, which maps exactly to midnight 1/1/2001 UTC.
That smells like the ID is just seconds since midnight 1/1/2001 + an increment if there's a collision. But then other people should be seeing this too. Puzzling.
@ivanski thanks for posting this issue.
fwiw, I’m now running geniatech’s EyeTV 4, which fixes a bunch of issues, but doesn’t yet have streaming, and changes the .eyetv
directories a little.
I’d like to update everything to EyeTV 4, but am holding off until it’s development is further along, and until I have cycles to spend to refactor this repo.
Thanks, hope it helps.
Re: EyeTV 4, unfortunately I’m stuck on EyeTV 3 because of the removal of HDHomeRun tuner support, so hopefully it’ll remain backward compatible or that will have to be the end of the line for me and likely a few others.
I just recently bought EyeTV 4 myself, but haven't installed it on my main setup, as I wasn't sure if ETV-comskip would work or not. Ivanski, EyeTV 4 does indeed support HDHomerun tuners BTW. As did the last if the 3.x version that they did, had added those tuners back in.
I just recently bought EyeTV 4 myself, but haven't installed it on my main setup, as I wasn't sure if ETV-comskip would work or not.
This repo doesn’t currently work with EyeTV 4. I’m using the good-old arrow button press, being motivated every time to refactor the repo.
FWIW, I like EyeTV 4, and it does fix more fundamental problems like TV Guide updates, and runs more reliably than the last EyeTV 3 version.
EyeTV 4 does indeed support HDHomerun tuners BTW.
Thanks, that's great news, it may actually entice me to take a look again; I stopped paying attention to geniatech after they borked both HD HomeRun and TV Guide (moved to schedulesdirect+XMLTV). I have essentially a quarantined Mac Mini stuck on Sierra just for that reason. Would love to be able to move it to an OS that's actively maintained.
Once the recording ID numbers get large enough, AppleScript numbers are represented and coerced to strings using exponential notation. The tell is that you get logfiles named things like:
6.1155708E+8_comskip.log
and6.1155708E+8.log
. When that happens, the MarkCommercials python script then fails to find a matching recording (the last line of the log is the list of recordings).The fix for this is to add an additional coercion at the top of the RecordingDone() and similar scripts:
set recordingID to recordingID as inches as string
(any unit will do to remove the exponential notation).Also, a nice addition to the applescripts to allow the testing code to execute on the first selected recording instead of an arbitrary number: