WolframAlpha time travel

Scenario: I'm encoding a 3½ hour video of an undisclosed but easily guessable subject matter. I want to know how much longer it will take, but my encoder only gives me:
 the total number of frames encoded
 the number of frames encoded in the last second
 various quality settings of the video
 the current size of the output file
 the current timestamp of the output file
 the current bitrate
 the number of frames duplicated or dropped
From this, I devise a simple formula:
Answers WolframAlpha gives:
 2 hours 56 minutes 31.74 seconds
 2038 hours
 7.335×10^{6} seconds
 122253 minutes
 84 days 21 hours 33 minutes 12.2 seconds
 84.9 days
 12.13 weeks
 0.2324 average Gregorian years
 ≈ 0.23 × orbital period of Earth (≈ 1 Julian year )
 ≈ 0.38 × orbital period of Venus (≈ 0.62 Julian years )
 ≈ 0.97 × orbital period of Mercury (≈ 0.24 Julian years )
 ≈ 0.044 × halflife of cobalt60 ( 1.6635×10^{8} s )
 ≈ 0.089 × halflife of sodium22 ( 8.2108×10^{7} s )
That's not Discoursistency™, that's actually a single positive answer followed by several negative answers. I'm going to assume the different answer is an anomaly.
This isn't a problem with mismatched units, as you can verify by removing hz from 50hz. Apparently my video has already finished encoding and I have to go back in time to find it.

3½ hour video of an undisclosed but easily guessable subject matter
Gay bestiality porn?
This isn't a problem with mismatched units, as you can verify by removing hz from 50hz.
It chokes on the multiple time units separated by spaces part, if you remove the x minutes and x seconds you get a (I assume) correct answer, if you add minutes again it chokes. I don't really know Wolfram, maybe it just doesn't accept this?

You can put + after hours and minutes and it works, but adding a unitless number to time^{2} and then dividing by time^{1} shouldn't give me a wildly incorrect answer in time^{1}. It should either give me an error or a technically correct answer in time^{3}.

but adding a unitless number to time^{2} and then dividing by time^{1} shouldn't give me a wildly incorrect answer in time^{1}. It should either give me an error or a technically correct answer in time^{3}.
Not to get all pedantic on you but ... Oh who am I kidding? You really have your units all B*****med up. Here's you original equation, units only:
(s)Hz  {no unit}
HzSince Hz is basically s^{1}, this can be simplified to:
(s)s^{1}  {no unit}
s^{1}Which reduces to:
{no unit}  {no unit}
s^{1}So your finally result should be in terms of time^{1}, as you put it. Where did you get all this crap about time^{2} and time^{3}?
Edit: I see how you can get an intermediate step which contains time^{2} by bringing the bottom Hz up top, but that doesn't fit with your previous post, so I chose to ignore that route. In case someone else chooses to call me on this, here it is:
((s)s^{1}  {no unit})s
(s^{2})s^{1}s

There are two possible interpretations of X hours Y minutes Z seconds:
 (xyz×3600×60) seconds^{3}
 (x×3600 + y×60 + z) seconds
WolframAlpha chose "neither".

There are two possible interpretations of X hours Y minutes Z seconds:
(xyz×3600×60) seconds3
(x×3600 + y×60 + z) seconds
WolframAlpha chose "neither".
Well, clearly, there are more than two possible interpretations, neh?

the problem is the unitless 97971. put it in frames and then put frames per second instead of Hz.
both adding as
(((3 hours + 22 minutes + 7.49 seconds)(50 frames per second))  97971 frames) / (48 frames per second)
or
(((3 hours 22 minutes 7.49 seconds)
(50 frames per second))  97971 frames) / (48 frames per second)
work fine if you do it right.
(I am buttuming that you mean frames per second when you put Hz)

TRWTF may be using a tool like Wolfram Alpha for something that a simple calculator can handle. Alpha is clearly too complicated for its own good.