View Bug Details

IDProjectCategoryView StatusLast Update
0000504DCP-o-maticFeaturespublic2016-05-31 23:57
Reporterandrew.levine Assigned Tocarl  
PriorityhighSeverityfeatureReproducibilityN/A
Status closedResolutionfixed 
PlatformMac OSOS XOS Version10.9
Product Version1.76.0 
Summary0000504: Speedy resume functionality
Description

When DCP-generation is stopped and the app quit it needs a very long time (Job: Checking existing image data) to get started with encoding again.

That might not be necessary if the contents of the media-files have not been changed, that is if their size and date-stamps are identical to the ones stored from the last DCP-generation pass. The user could be asked: "The media files seem to have not been changed since the DCP-render started. Resume without verification? Yes / No." If "Yes" is selected the system would only parse the last ten entries or so and then get cracking again :-)

Additional Information

In the case of my 2h+ movieā€¦

Fri Feb 20 05:30:11 2015: Job: Checking existing image data
Fri Feb 20 05:30:11 2015: Have existing frame 0

[00:54 h later] Generating & checking hash codes I presume?

Fri Feb 20 06:26:45 2015: Have existing frame 143758
Fri Feb 20 06:26:45 2015: Existing frame 143759 has no info file
Fri Feb 20 06:26:45 2015: Job: Encoding image data
Fri Feb 20 06:26:45 2015: Adding 2 worker threads for remote 192.168.178.20
Fri Feb 20 06:26:45 2015: Adding 2 worker threads for remote 192.168.178.40
Fri Feb 20 06:26:45 2015: Adding 4 worker threads for remote 192.168.178.37
Fri Feb 20 06:26:45 2015: New graph for 1920x1080, pixel format 74
Fri Feb 20 06:26:46 2015: Finished locally-encoded frame 0 for mono

[01:22 h later] Not sure what was going on here.

Fri Feb 20 07:48:44 2015: Sending frame 143764 to remote

TagsNo tags attached.
Branch
Estimated weeks required
Estimated work requiredAverage

Relationships

related to 0000519 closedcarl Optimise checking of existing image data 

Activities

carl

2015-02-22 23:33

administrator   ~0000513

I think it probably would be possible to speed up the MXF check. The original reasoning was to spot if the end of a previous encode had been corrupted by a crash / power-cut or whatever. On reflection it seems more sensible perhaps to work back from the end of the existing data and find the first frame that has the correct checksum, then continue the encode from there.

carl

2015-09-03 16:28

administrator   ~0000847

6dc47c78dd7429b5299e21942964dedde8a2c827

Bug History

Date Modified Username Field Change
2015-02-22 13:42 andrew.levine New Bug
2015-02-22 23:33 carl Note Added: 0000513
2015-02-22 23:33 carl Assigned To => carl
2015-02-22 23:33 carl Status new => acknowledged
2015-04-24 15:37 carl Relationship added related to 0000519
2015-06-12 16:41 carl Estimated work required => Average
2015-06-12 16:41 carl Priority normal => high
2015-08-27 16:56 carl Target Version => 2.x
2015-09-03 16:28 carl Note Added: 0000847
2015-09-03 16:28 carl Status acknowledged => resolved
2015-09-03 16:28 carl Resolution open => fixed
2016-05-31 23:57 carl Status resolved => closed