MarkCommercials fails when recording ID gets large enough for AppleScript to use exponential notation

[ivanski]

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 and 6.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:

on getSelectionRecIDs()
	tell application "EyeTV"
		set sel to selection of programs window
	end tell
	set recIDs to {}
	repeat with rec in sel
		tell application "EyeTV"
			set recID to unique ID of rec as inches as string
			set recIDs to recIDs & {recID}
		end tell
	end repeat
	return recIDs
end getSelectionRecIDs

on run
	tell application "EyeTV"
		set rec to my getSelectionRecIDs()
		my RecordingDone(item 1 of rec)
	end tell
end run

[dblanch369]

I hadn't seen that yet, I wonder what causes it to get a number so large?

[ivanski]

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.

[ivanski]

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.

[essandess]

@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.

[ivanski]

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.

[dblanch369]

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.

[essandess]

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.

[ivanski]

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.