Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Delete Original MKV #17

Open
alavigne12 opened this issue Jan 24, 2019 · 3 comments
Open

Delete Original MKV #17

alavigne12 opened this issue Jan 24, 2019 · 3 comments

Comments

@alavigne12
Copy link
Contributor

Currently, we have to delete the original MKV after the AIP is created. Ideally, vieoaip would do a QC check on the duplicated MKV, then delete the original for us.

@privatezero
Copy link
Member

privatezero commented Jan 24, 2019

By 'QC' check, how granular are you meaning?

We could do something like @dericed's (Dave) approach in this:
https://github.com/mediamicroservices/mm/blob/master/ingestfile#L284
Where it checks to make sure rsync (the command used to move the file) didn't have any errors and then deletes the file. That would be the fast way.

Alternately, we could calculate the checksums for the original file and the copied file and make sure they are the same - that is the SLOW way, but would be 100% accurate as opposed to the simple rsync check which is like 99.9% accurate. (I am making that number up.)

Currently I assume it is just a visual check to see if the file is there before deletion? So I suppose either of these would make the system more robust?

@alavigne12
Copy link
Contributor Author

Dave's method sounds good, but Libby will have to make the final call. Very occassionally videoaip has generated an MP4 that wouldn't play, but that could very likely be a result of faulty input from us. I would be afraid that it would generate a faulty mkv dupe, then delete the original. But it sounds like the rsync option would make sure that didn't happen.

@privatezero
Copy link
Member

I mean, rsync uses checksum verification on the data it sends and is pretty darn safe from my understanding - it just isn't technically 100% infallible. But on some level, hey if it is good enough for @dericed it is probably good enough for us!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants