This status is more important then it may at first appear because * We condition retry on it * Condition job launch on it * May be other things in future given 2 already Feb 12, 2020 Realized suspect that without the lock (on both), if it happens
(self)
| 1198 | self.session.add(video) |
| 1199 | |
| 1200 | def video_status_updates(self): |
| 1201 | """ |
| 1202 | This status is more important then it may at first appear because |
| 1203 | * We condition retry on it |
| 1204 | * Condition job launch on it |
| 1205 | * May be other things in future given 2 already |
| 1206 | |
| 1207 | Feb 12, 2020 |
| 1208 | Realized suspect that without the lock (on both), if it happens |
| 1209 | to update the video to pushing frames after it's complete |
| 1210 | that can cause issues. Context that we now process on say |
| 1211 | 8 different threads / frames running in parallel |
| 1212 | |
| 1213 | I wonder if it would be better pro actively flag this |
| 1214 | ie flag it when we insert it. |
| 1215 | |
| 1216 | Also could build in a retry here, so that the |
| 1217 | last one retries a number of times to mark it complete... |
| 1218 | (ie if by chance another thread had the other status update |
| 1219 | and the state estimate was off...)... |
| 1220 | |
| 1221 | Started trying to refactor this into it's own thing. |
| 1222 | |
| 1223 | TODO not super happy with this whole sorta setup with |
| 1224 | # parent_input code duplication here |
| 1225 | # The rationale is that we only want to fire this request when needed |
| 1226 | # perhaps these could be separate functions are something? |
| 1227 | |
| 1228 | I think we may need to abstract the conditional statement |
| 1229 | so that we only run that once... |
| 1230 | |
| 1231 | Main leave off is not sure if super happy with how aggressive |
| 1232 | get_parent_input_with_retry() is, |
| 1233 | Is there a way we can pass a paremeter to the retry thing? |
| 1234 | ie want it to be very aggressive (at getting thing) |
| 1235 | for final one but less so for status updates. |
| 1236 | |
| 1237 | Jan 23, 2020 |
| 1238 | The magic number for this is a little tough |
| 1239 | In large jobs, most of this updating is not needed |
| 1240 | However we do need to update every so often to keep |
| 1241 | retry system happy |
| 1242 | and for smaller jobs, too large of a number may |
| 1243 | result in bad UI experience. perhaps this should |
| 1244 | scale on some factor of video length. |
| 1245 | |
| 1246 | |
| 1247 | Why the +2? |
| 1248 | It's possible the frame number could be slightly off from the video parent length. |
| 1249 | """ |
| 1250 | if not self.input.video_parent_length: |
| 1251 | return |
| 1252 | |
| 1253 | if self.input.mode == 'copy_file' and self.num_frames_to_update != 0 and self.frame_completion_controller is not None: |
| 1254 | # For video copy update every 10th part the amount of total frames |
| 1255 | run_every_x_number_of_frames = int(round(self.num_frames_to_update / 10)) |
| 1256 | run_every_x_number_of_frames = max(1, run_every_x_number_of_frames) |
| 1257 | # If we're at least 20 frames before the last one. It means we're near the last frame. |
no test coverage detected