T536, T537, & T538 are co-mingled

[KSchlining]

It looks like T536 was merged with the log for T537. Can we re-merge it with the correct log file? There are no annotations for T537 but all the annotations for T536 & T538 are in VARS under that dive #. Reported previously in JIRA #VARS-626 and #VARS-741. Also, the metadata for the video resolution for the T536 files is showing up as HD instead of SD when browsing to the files in the VAM.

[hohonuuli]

Links to JIRA issues:

• https://mbari1.atlassian.net/browse/VARS-626
• https://mbari1.atlassian.net/browse/VARS-741

[hohonuuli]

Sanity checks. Here's the URLs to inspect the video assets for the dives:

• http://m3.shore.mbari.org/vam/v1/videosequences/name/Tiburon%200536
• http://m3.shore.mbari.org/vam/v1/videosequences/name/Tiburon%200537
• http://m3.shore.mbari.org/vam/v1/videosequences/name/Tiburon%200538

The video tapes for all 3 dives are all in Tiburon 0537

[hohonuuli]

Proposed Fix for T0536. Tested on fog server:

UPDATE videos SET video_sequence_uuid = '67282c6d-adda-4d79-9726-7fbbd6a0caaa'
WHERE video_sequence_uuid = '9b614cca-3e6b-4aa7-ae48-2967cb4ab35f' AND name LIKE 'T0536-%'

[hohonuuli]

Proposed fix for T0538. Tested on fog server:

UPDATE videos SET video_sequence_uuid = '379ffa5b-c3fc-4c2e-9079-e6479685aada'
WHERE video_sequence_uuid = '9b614cca-3e6b-4aa7-ae48-2967cb4ab35f' AND name LIKE 'T0538-%'

[hohonuuli]

The tape video references for T0536, T0537, and T0538 are now in the correct video sequences. Output from fixes:

[2023-12-12 11:16:29] Connected
M3_VIDEO_ASSETS> use M3_VIDEO_ASSETS
[2023-12-12 11:16:29] [S0001][5701] Changed database context to 'M3_VIDEO_ASSETS'.
[2023-12-12 11:16:29] completed in 11 ms
M3_VIDEO_ASSETS> UPDATE videos SET video_sequence_uuid = '67282c6d-adda-4d79-9726-7fbbd6a0caaa'
                 WHERE video_sequence_uuid = '9b614cca-3e6b-4aa7-ae48-2967cb4ab35f' AND name LIKE 'T0536-%'
[2023-12-12 11:16:29] 9 rows affected in 58 ms

M3_VIDEO_ASSETS> UPDATE videos SET video_sequence_uuid = '379ffa5b-c3fc-4c2e-9079-e6479685aada'
                 WHERE video_sequence_uuid = '9b614cca-3e6b-4aa7-ae48-2967cb4ab35f' AND name LIKE 'T0538-%'
[2023-12-12 11:17:53] 9 rows affected in 11 ms

[hohonuuli]

Using the m3-merge project to correct the start timestamps and re-merge. Timestamps for the tape vide references have been corrected using:

cd m3-merge
sbt pack
cd target/pack/bin
mv ../conf/production.conf ../conf/application.conf
adjust_tape_timestamps "Tiburon" 536
adjust_tape_timestamps "Tiburon" 537
adjust_tape_timestamps "Tiburon" 538

[hohonuuli]

These dives have been remerged using:

merge_rov "Tiburon" 536
merge_rov "Tiburon" 537  # Does nothing as there's no new data to remerge
merge_rov "Tiburon" 538

[hohonuuli]

@KSchlining Everything should be good now. Take a look and let me know and I'll close the issue if all is well.

[kwalz]

@hohonuuli associated with this, see attached screenshot, can we edit the tape start and end parameters and/or duration parameters? Here this one says tape is duration 15 hours (dive was that long but not tape). We're seeing a lot of errors for tape start and end times and it is causing issues for new IMES files and old annotations. It may have to be a manual edit and I can take those on as I go through issue tapes.

[hohonuuli]

I think just opening the tape in VARS and then switching to another will fix the 536, 537, and 538 dives. But I'll double check.

[hohonuuli]

Sanity check that looks for tapes longer than 60 minutes:

SELECT
    COUNT(*)
FROM dbo.unique_videos
WHERE
    duration_millis > 60 * 60 * 1000 AND
    uri LIKE 'urn:tid%'

Returns 9851 rows. They probably have annotations with a 1970 recorded_timestamp in them. 🤔

[kwalz]

I think those tapes have dive start and end times instead of just tape duration :)

[hohonuuli]

@kwalz I've moved the issue regarding duration parameters to #85 as a separate issue. So just review the tape dimensions in this issue, so I can close it.

[hohonuuli]

Tapes only have start times and durations. The end time is calculated from those.