Changing a Recording's Date and Time settings

I prefer doing a record a series then watching it all together over a period of hours or days

Recently a series was being recorded and for some reason (not relevant here) the Humax HDR Fox T2 reset itself part way through recording an episode, being present at the time, I initiated a manual record of the programme as soon as the Humax had rebooted

Being aware that this series would be rebroadcast at the weekend, back to back reshowing of the previous week's daily schedule, I selected the relevant episode to be recorded again

I there a way to edit the weekend episode to that it matches the failed recordings date and time, as it keeps getting swept away to the wrong folder as it's now an am recording, not a pm recording

I've tried renaming from the webif OPT+ option, changing the Programme Name_YYYYMMDD_HHMM to match the failed recording date and time, but the file still shows in the recorded items list in its originally recorded date and time place rather than the edited date and time position
 

MontysEvilTwin

Well-Known Member
@Oatcake was kind enough to create a script to do this: see here. I tweaked the script slightly since, as described in this post here, and the posts below. @/df did some modifications to automatically handle BST/ GMT but I could not get this to work so I stuck to my version where it asks you whether to set the flag.
 
Hello MontysEvilTwin

Thank you for that, got it to work after a faff, didn't like the file path, had to create /mod/usr/ then /mod/user/bin was then able to save 'setrecstart' did the chmod command and it worked, though it didn't change the YYYYMMDD or HH:MM in the filename

It seems this would be a good option to be put in the OPT+ list of options to perform

The file has now been correctly swept away to the proper evening folder

Thank you again, all you boffins who do all the magic, making the Humax HDR Fox T2 a useful piece of kit all these years
 

MontysEvilTwin

Well-Known Member
Hello MontysEvilTwin

I notice your edited script expects a .ts file, yet the original expects a .hmt file extension
The HDR-FOX only uses the date and time information within the hmt file, which is set by the script. The original script also used the touch command to set the external timestamp of the hmt file. This file is written to during playback and the timestamp changes anyway. Webif orders recordings based on the timestamp of the ts files. If you point to the ts file while running the script it is the ts file timestamp that gets updated instead by touch, so it appears in the correct order in Webif.
 

/df

Active Member
@Oatcake was kind enough to create a script to do this: see here. I tweaked the script slightly since, as described in this post here, and the posts below. @/df did some modifications to automatically handle BST/ GMT but I could not get this to work so I stuck to my version where it asks you whether to set the flag.
This is the latest version and appears to do the job. I stopped it changing the "Scheduled start" -- is that correct? It also touches the .ts as well which you explained above is necessary to affect the Webif display.

Don't copy the text as it has an embedded tab that won't be preserved (or be prepared to edit it back in); instead use the attachment, but remove the extension and make it executable.
Code:
#!/bin/sh
set -e

if [ $# != 2 ]; then
  echo "Usage: $0 <date-time> <filename>" 1>&2
  echo "  eg: $0  \"2017-05-05 14:00\" recording" 1>&2
  echo "  See 'info date GNU' online for valid date-time formats." 1>&2
  exit 1
fi

# get hmt parameter by number
# (1)Title, Synopsis, HD/SD, LCN, Channel Name,
# (6)Start time, End time, Flags, Guidance, Bookmark count,
# (11)Scheduled start, Scheduled duration, Genre code,
# (14)Resume point, Status/Reason.
hmt_get() { # hmt_file param_no
    local a1 a2 a3 a4 a5 a6 a7 a8 a9 a10 a11 a12 a13 a14 a15
                                   
    hmt -p "$1" |
        ( # the IFS value is a tab!
          IFS='    ' read -r a1 a2 a3 a4 a5 a6 a7 a8 a9 a10 a11 a12 a13 a14 a15 _
          eval printf "%s" "\${a$2}" )
}

# set the hmt field of width 8/16/32 bits at offset loc
hmt_patch() { # hmt_file loc width val
    hmt +patch$3=$2:$4 "$1" >/dev/null
}

main() {
    local dt hmt start end newStart newEnd
   
    # condition the date-time with TZ and 0 seconds
    dt="$(date -d "$1" +"%F %H:%M:00%z")"
    # is this file (without any .ts extension) worth it?
    hmt="${2%.ts}"
    # try with .hmt extension too
    [ -f "$hmt" ] || { hmt="${hmt%.hmt}.hmt"; [ -f "$hmt" ]; } || { echo "\"$hmt\": no such HMT file" 1>&2; exit 1; }
    hmt "$hmt" | grep -v -q -m 1 "Invalid HMT file," || { echo "\"$hmt\": invalid or unreadable HMT file" 1>&2; exit 1; }
    [ -w "$hmt" ] || { echo "\"$hmt\" can't be written" 1>&2; exit 1; }

    # patch DST flag, actually a UTC TZ offset
    tz="$(date -d "$dt" +"%:z")"
    # value is 60*(60*hrs+mins)*sign NB avoid problem with leading 0 => octal (08 is a syntax error)
    case $tz in
        -*)   tz=${tz#-}; tz=${tz#0};
          # assume that negative TZ offsets are stored as 16-bit 2s complement
          hmt_patch "$hmt" 1076 16 -$((60*(60*${tz%:*}+${tz#*:})))
          ;;
        *)    tz=${tz#+}; tz=${tz#0};
          hmt_patch "$hmt" 1076 16 $((60*(60*${tz%:*}+${tz#*:})))
          ;;
    esac

    start="$(hmt_get "$hmt" 6)"
    end="$(hmt_get "$hmt" 7)"

    newStart="$(date +"%s" -d "$dt")"
    newEnd=$(( newStart + (end - start) ))

    hmt_patch "$hmt" 640 32 "$newStart"
    hmt_patch "$hmt" 644 32 "$newEnd"
    # no need to patch "Scheduled start" ??
    #hmt_patch "$hmt" 1272 32 "$newStart"

    touch -d @$newEnd "$hmt" "${hmt%.hmt}.ts"
}

main "$@"
 

Attachments

Last edited:

MontysEvilTwin

Well-Known Member
This is the latest version and appears to do the job. I stopped it changing the "Scheduled start" -- is that correct? It also touches the .ts as well which you explained above is necessary to affect the Webif display.

Don't copy the text as it has an embedded tab that won't be preserved (or be prepared to edit it back in); instead use the attachment, but remove the extension and make it executable.
Regarding the 'scheduled start' parameter, I added that line to make it equal to the actual start time just for neatness, as these values can end up being very different. This parameter is not used for sorting so it is not important. You may prefer not to change it as it will tell you (approximately) the actual time it was recorded rather than what you changed it to with the script. I will stick to changing it so I'll just edit out the hash symbol etc. from the attachment.
 
Top