I'm new and thought the HH:MM:SS had to be converted to seconds
Yes, that's correct.
What time is it? It's not "minutes time.seconds" but HH:MM:SS. I'm not used to calculating the minutes in my head. A 1 hour 23 minute and 04 second video position mark is "83.04" but I'm not used to thinking in those terms.
That's not correct. It's 4 + 23*60 + 1*60*60.
I'd rather have the HH:MM:SS format.
The purpose of having the parameter be a single number is that you can link it, do some math on it, and control it in many different ways. You can't do math with HH:MM:SS or MM:SS.
I found myself having to navigate to the video folder from another software to open it and find the start and stop position times. Opening another window during a live show is not ideal.
I really wish there was a visual way to pick the start and end times instead of dealing with "raw" numbers. Numbers are low level. A higher level abstraction layer with GUI for scrub position ( I think it's called the scrub bar) and transport control (Play, Stop, Pause, etc.) would simplify and speed up the process. Moving a scrub bar, perhaps via a transport control node, if the start and end indicators of the scrub bar then automatically became the start and stop times that'd be more practical.
Ok, honestly I'm not sure if Magic is the right software for you? It sounds like you need more of a traditional video player, and there are lots of "high-level" ones available. Magic is intentionally a "low-level" program. There are much better things out there if your goal is to be able to load and loop video clips dynamically during a performance, especially if the clips are more than an hour long and you need to quickly find very short segments to use as your loop points.
Alternatively, you can use Spout/Syphon to connect Magic to most other VJ programs, and get the "best of both worlds". This is precisely why the Spout/Syphon ecosystem exists.
On a separate note, real-time scrubbing really only works when you have video formats/codecs that are optimized for bi-directional playback (such as M-Jpeg or Hap/DXV). Most common formats, such as .mp4, cannot be efficiently fast-forwarded, rewound, or played in reverse. Doing any of these things during a performance will severely impact your frame rate -- which is, at least for now, why Magic does not have transport controls. There is a tradeoff, and we opted to support as many formats as possible.
I think there is still some scope for video information and transport control for scene development purposes
I hear you on that. But from a functional perspective, it's difficult for us to create features only for development (things you can do at home) but not for live performance (things you can do at your show). How do we enforce the separation? It's not enough simply to say "don't use this during your show", because, to be honest, no one will pay attention
. The result would be a bunch of users wondering why their frame rate is stuttering when they use the transport controls.
Again, other VJ programs solve this by requiring certain codecs to be used. We opted not to go in that direction for the generic VideoFile module. But, I should mention that I have on my list to create a new separate video module specifically for the Hap codec (and perhaps some other bi-directional codecs), which will allow you to scrub in any direction and jump to a specific frame # on demand. This is the best solution I can offer. It will work similarly to the current JpegFolder module, except that it will be for one video file as opposed to many separate image files.
Neither can I advance or find my video positions without guessing. What is the mathematical formula for calculating the conversion in order to enter the minutes and seconds? I thought I had it correct for the end time by the video looped to soon during the show. 
