• The forum software that supports hummy.tv has been upgraded to XenForo 2.3!

    Please bear with us as we continue to tweak things, and feel free to post any questions, issues or suggestions in the upgrade thread.

Beta [transportx] Additional 'transport' functions

I don't like to bite the hand that feeds, and I admit to not having got around to trying it yet, but there strikes me to be a usability issue.

As standard, there is only slo-mo forward available, and this innovation provides reverse slo-mo - I get that, and I congratulate you on working it out.

I see a lack of intuitivity though, regardless of lack of reverse half and reverse eighth. By "lack of intuitivity", I mean there is no means to speed up slo-mo. Having arrived at x1/16, the only exit is to interrupt slo-mo entirely.

Allowing that I don't know what inputs are available (in the form of remote control button presses), may I suggest the following scheme:

Slo-mo button: enter slow motion playback mode, forward direction;

Cursor left/right buttons (or skip buttons): reverse/forward slo-mo, at current rate;

Rew/FF buttons: accelerate/decelerate in intuitive direction, ie Rew decelerates forward slo-mo and accelerates reverse slo-mo;

Play/pause/stop: exit slo-mo;

Slo-mo (while in slo-mo mode): exit slo-mo.
 
I think it should be possible to implement most of what you suggest but this has to fit around what the Humax app is doing (or what it thinks it is doing).

The cursor buttons are not very useful for interception because they don't always call the nexus functions so it would have to be the skip buttons.

With version 0.2 of transportx, pressing pause does not exit slow mode, it just suspends it with frame advance capability. Pressing ffwd or rew will resume slow mode.

The last item on your list may be problematic but as in your list, slow mode can be exited using play (or stop when viewing the tsr buffer).
 
While holding the channel change '0' key and the central 'OK' key together for a set time, puts the system into handset frequency change mode, are there any other keys or key combinations that could be used to place the handset or the unit into a certain mode whereby further keypresses have a different function
 
Slo-mo button: enter slow motion playback mode, forward direction;
When in slow mode the skip buttons do not call the nexus playback functions so there is nothing to hook into. It would need some other mechanism, maybe a hook into the ir package.
 
I see a lack of intuitivity though, regardless of lack of reverse half and reverse eighth. By "lack of intuitivity", I mean there is no means to speed up slo-mo. Having arrived at x1/16, the only exit is to interrupt slo-mo entirely.

Allowing that I don't know what inputs are available (in the form of remote control button presses), may I suggest the following scheme:

Slo-mo button: enter slow motion playback mode, forward direction;

Cursor left/right buttons (or skip buttons): reverse/forward slo-mo, at current rate;

Rew/FF buttons: accelerate/decelerate in intuitive direction, ie Rew decelerates forward slo-mo and accelerates reverse slo-mo;

Play/pause/stop: exit slo-mo;

Slo-mo (while in slo-mo mode): exit slo-mo.
I have been sitting on a new version of this for some time.
I initially implemented something along the lines you suggested but in operation I found it could be very confusing for the user in working out which is the current direction. Ideally the on-screen graphic should show the speed and direction but I don't see an update to this any time soon. The difficulty occurred when slowing down to the slowest speed and a further press would change the direction at the slowest speed. Depending on the content it was not always obvious which way things were moving.

Instead I eventually decided to go for a scheme where the FF/REW buttons would slow it to the minimum speed and no further. In order to change direction you have to first pause when in 'slow' mode and then press the relevant FF/REW to speed up in whichever direction is required.

Hopefully this will be added to the beta repository soon, if people think it is a good idea.
 
Version 0.4 has been added to the beta repository. It implements the new scheme in post 26 above.
I will update the original post later today or tomorrow.
 
The original post has now been updated to match version 0.4

Change Log:

Code:
v0.4: New slow speed scheme using pause to change direction.

v0.3: Fixed rare crash after pressing pause many times.
      (Only happened to me once after about a month)

v0.2: Improved ffwd, rew, pause button interaction in slow speed mode.
      Fixed unresponsive pause button.
      Fixed fwd x1/16 -> rew x1/16 transition.

v0.1: Initial issue
 
Last edited:
A new version (0.5) of transportx is now available in the beta repository. Some ideas for this came from this 14 year old post on DS which I recently found. The new features are:
  • Pressing PAUSE and then FFWD or REW would previously enter x2 mode, it now enters minimum speed slow mode.
  • In Slow mode, repeated presses of FFWD/REW in the same direction would previously increase the speed up to x1/2 forward or x1 reverse. This new release will now go up to x32 in both directions.
  • In Search (fast) mode the speed can now be reduced by repeated presses in the opposite direction. It will jump from x1 forward to x1 reverse and vice versa. The sound is muted in x1 search or x1 slow mode but can be restored by pressing PLAY.
The SLOW button still functions as before but it is now redundant since the PAUSE button can also be used to enter 'slow' mode.

The transportx package has very limited control of the timebar. It will not popup a new timebar if the new speed/direction does not match that at which the Humax firmware thinks it is running at. The timebar will remain on screen for a few seconds after a button is pressed and will still show the old speed until the timeout has occurred.
 
Having recently tried to use slow motion and found how hard it is to freeze on the frame I want, I'll probably have a go at using this now.

What I am finding is programme makers increasingly think we are all watching on 65" screens so they can show a flash of a mobile phone screen for less than a second and everyone will be able to read the important plot point shown. On a 32" screen from 2.8m away I can't read the text even when paused, so I have to first find the frame and freeze it and then get up and walk halfway to the screen to read it (together with screwing my eyes up a bit to get the text to read better defocussed since it's all made assuming 4K as well).
 
What I am finding is programme makers increasingly think we are all watching on 65" screens so they can show a flash of a mobile phone screen for less than a second and everyone will be able to read the important plot point shown. On a 32" screen from 2.8m away I can't read the text even when paused, so I have to first find the frame and freeze it and then get up and walk halfway to the screen to read it (together with screwing my eyes up a bit to get the text to read better defocussed since it's all made assuming 4K as well).
Glad to know that I am not the only one with this problem even though my screen is 49".
 
Back
Top