• 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".
 
In Search (fast) mode the speed can now be reduced by repeated presses in the opposite direction.
I find this quite annoying. If I've been searching forward at high speed and have just gone past what I was looking for, then I want to go backwards immediately, not have to press the button several times to do so (I don't accept the "go to a slower Fwd search so I can find the end of the adverts" argument - I find the end by having gone past it, as I expect does everyone).
Additionally, the Search forward mode now doesn't reach x32 - it stops at x16; nor does it go back to x1 after x32 like it did previously, and still does when in reverse.
I don't think x1 reverse is much use either - you get about 1.5 frames/s.

The Slow mode options seem to work OK for me.

Because of the above, I can't really live with 0.5 and am going back to 0.4
 
Additionally, the Search forward mode now doesn't reach x32
I initial presumed that you just meant when the transportx control is activated after pressing pause, but I see that it happens when go direct to the fast forward button without pressing pause first.
Slightly annoying on MP4 playback but not so significant on playback of recordings as what Humax calls "x32" is only 20% faster than what Humax calls "x16", and "x16" with recordings is close to x45.

I find this quite annoying. If I've been searching forward at high speed and have just gone past what I was looking for, then I want to go backwards immediately, not have to press the button several times to do so (I don't accept the "go to a slower Fwd search so I can find the end of the adverts" argument - I find the end by having gone past it, as I expect does everyone).
The quickest way to reverse like that using 0.5 when the transportx control has been activated is to press pause when you have just gone past what you were looking for and then use the reverse button.
This used to be easier on the PVRs which the link in post #31 were discussing as their combined pause/play button was between the fast forward and reverse buttons. Unfortunately with the layout of the RM-F04 the 0.5 style of transport control is a bit awkward in comparison.

(I don't accept the "go to a slower Fwd search so I can find the end of the adverts" argument
Your was is also how I do that, which with transportx installed is still possible by going straight to fast forward without activating transportx by pressing the pause button.
On DS that guy's method sounds very awkward especially if you don't know how long the add break is, or how far you are through fast forwarding.
 
Last edited:
Back
Top