Spaces in filenames are not supported

@vtkeithg, for the video player, does the filename of the captions need to match the mp4 exactly? (If we remove spaces in filenames to run the process, do we need to add the spaces back in the vtt filename or can we leave it as-is?

As it happens, it doesn't need to match the name of the mp4 at all. The mp4 can have spaces and the vtt not, or the reverse, or both names can be arbitrary as long as they have the proper extensions. Relevant code is at the bottom of this post.

I did this because I wanted captions to work whenever possible, but keep in mind that differing filenames could be problematic in the future. When this video playback was put together around 2012 for Event capture, an assumption was made where only one video would be provided for each item. As you know, this was a poor assumption; VTechWorks has had several item submissions where it's desirable to have multiple videos in the same item. I'm not sure, but that might even be true of Event Capture (or whatever the successor is) events.

When we rethink and modify how video works in VTechWorks, if we make changes so that playback works with more than one video per item, we'll also need a way of matching specific captions in an item with specific videos, and the easiest way is with filename.

I'm not sure how to solve the spaces in the filename problem for this project yet. S3 supports spaces in objects, but I was having difficulty. It's probably a very easy fix, but I don't know what it is yet!

 <!-- V.T. display captions -->
               <xsl:if test="./mets:fileSec/mets:fileGrp[@USE='CONTENT']/mets:file[@MIMETYPE='text/vtt']">

               <track kind="captions" srclang="en" label="English" default="default">
               <xsl:attribute name="src">
               <xsl:value-of
                 select="./mets:fileSec/mets:fileGrp[@USE='CONTENT']/mets:file[@MIMETYPE='text/vtt']/mets:FLocat[@LOCTYPE='URL']/@xlink:href" />
               </xsl:attribute>
               </track>
               </xsl:if>

Thank you very much for the information about the caption names. Yes, it would be better to have the filenames match. For AWS, would any of these discussions to use quotes or URL encoding help, https://stackoverflow.com/questions/47642976/how-do-i-handle-aws-s3-returning-file-object-names-with-the-character-in-place and https://stackoverflow.com/questions/50954204/how-to-read-an-object-in-a-bucket-with-pluses-and-spaces-in-its-name?

mentioned in merge request !2 (merged)

Thanks, @alaw. This was helpful. I've corrected two issues - one with not handling spaces properly in a command that deletes files from s3, and another that tried to start transcribe jobs with spaces in the job name.

closed

Just thinking that if you've already tried the simpler instructions, you may need to run a command to get the updated image that works with spaces in the filenames.

docker image pull code.vt.edu:5005/digital-research-services/caption-whale

Something to add to the documentation later, too.

@vtkeithg, thank you very much for fixing this issue.

reopened

I added those instructions in the README as a placeholder. If you don't mind, I'd like to leave this issue open as a reminder to update our documentation for this.

This morning I've updated the instructions in the README.md in the simpler_instructions branch to handle pulling the image if it is outdated, and I'll close this fixed issue about the spaces in filenames now. With the new branch, the command in the run step will always check with the registry first to see if a new image is available; if one is available, it will be pulled. If you already have an up-to-date image on your system, it will just use that.

This step doesn't apply to the original set of instructions because the image was built locally instead of being retrieved from the registry - but I suspect the simpler_instructions will ultimately be easier anyway, and I've submitted a merge request for the simpler instructions.

closed

@vtkeithg, thank you very much. That seems like a great solution.