Changing a Recording's Date and Time settings

C

Code is a Hole

Member
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

Is there a way to edit the weekend episode so that it matches the failed recording's 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
 
Last edited:
@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
 
Andrea Edwards said:
Hello MontysEvilTwin

I notice your edited script expects a .ts file, yet the original expects a .hmt file extension
Click to expand...
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.
 
MontysEvilTwin said:
@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.
Click to expand...
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

  • hmt_touch.txt
    2.2 KB · Views: 11
Last edited:
/df said:
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.
Click to expand...
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.
 
/df said:
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.
Click to expand...
I tried using the hmt_touch-txt and having got it to execute (scripts are not my strong point on linux) I ran the file, tried every possible combination of parameters, though I did get different error messages, the results were not as expected

May I offer hopefully, an ease of use suggestion, allow the expert user to enter the date and time as you have programed,, but allow an occasional/notice user the ability to have the error captured and the script offers to interact, by asking a few questions and taking input from the user, rather than

= = = = =
Humax# pwd
/media/My Video/Datestamp
Humax# ls -l
-rw-r--r-- 1 root root 2072 Nov 5 09:38 Datestamp_20201017_1500.hmt
-rw-r--r-- 1 root root 4374592 Nov 5 09:38 Datestamp_20201017_1500.nts
-rw-r--r-- 1 root root 43680 Nov 5 09:38 Datestamp_20201017_1500.thm
-rw-r--r-- 1 root root 400605888 Nov 5 09:38 Datestamp_20201017_1500.ts
Humax# hmt_touch
Usage: /mod/usr/bin/hmt_touch <date-time> <filename>
eg: /mod/usr/bin/hmt_touch "2017-05-05 14:00" recording
See 'info date GNU' online for valid date-time formats.

Humax# hmt_touch "2020-10-13 20:15" "Datestamp_20201017_1500.ts"
date: invalid date '2020-10-13 20:15:00+0100'
Humax#
= = = = =
So I tried a few options based on the error message
= = = = =
Humax# hmt_touch "2020-10-13 20:15:00" "Datestamp_20201017_1500.ts"
date: invalid date '2020-10-13 20:15:00+0100'
Humax# hmt_touch "2020-10-13 20:15:00+0100" "Datestamp_20201017_1500.ts"
date: invalid date '2020-10-13 20:15:00+0100'
Humax#
= = = = =

As you can see, I have entered the date and time as shown on the 'eg' line, I did a search for 'info date GNU', offered no help

My goal is to be able to replace a recording that has become damaged or failed to record with a backup recording recorded at a different time, but have the replacement appear at the correct point in the list
 
Luke said:
Executing the diagnostic "fixtimestamps" works for me.
Click to expand...
Thank you Luke, any chance of an example of using fixtimestamps, according to the hummy diagnostic utilities page, ' fixtimestamps = set all recording's timestamps to match the time the recordings finished ', I'm not after fixing a time stamp to when the recording ended, I'm after changing the time stamp to a different date/time altogether, for example, a failed recording on say a Tuesday evening at 8.15pm is reshown on a Saturday at 10am, this recording would not fit in with the other recordings in the correct location when sort on date, it would also not match if any sweeper rules were actioned that involved date or time filtering

I only need to change the datestamp on occasional files, I have my Humax HDR Fox T2 boxes connected to an APC UPS, so no longer suffer from failed recordings due to brown-outs, the failed recordings now are caused by a system crash or timing conflict
 
I think the previous script is failing because it is using the busybox version of 'date'.

Try installing the coreutils package.
 
Andrea Edwards said:
I tried using the hmt_touch-txt and having got it to execute (scripts are not my strong point on linux) I ran the file, tried every possible combination of parameters, though I did get different error messages, the results were not as expected
Click to expand...
@xys321 is on the money. The coreutils package has a "working" version of the date command, rather than the one that comes built into the CF; this was mentioned in the original post, but either forgotten or just omitted above.

Obviously you are due a complete refund if the script failed to satisfy you.

I downloaded the linked attachment, renamed it and made it executable. Then, with coreutils installed:
Code: 
# ./hmt_touch "2018-04-05 21:30" /media/[Video\]/Young\ Sheldon_20180405_2132
# hmt /media/[Video\]/Young\ Sheldon_20180405_2132 | grep 'Recording start'
Recording start:1522960200 (Thu Apr  5 21:30:00 2018) 
# ./hmt_touch "2018-04-05 21:30" /media/[Video\]/Young\ Sheldon_20180405_2132.ts
Then I tried the first example from the first g-hit for 'info date GNU':
Code: 
# ./hmt_touch "2 days ago" /media/[Video\]/Young\ Sheldon_20180405_2132.ts
# hmt /media/[Video\]/Young\ Sheldon_20180405_2132 | grep 'Recording start'
Recording start:1604400600 (Tue Nov  3 10:50:00 2020)
#

I tried many date-time formats with the CF built-in date. Although it would output the standard date-time formats, the only ones that I could make it understand were epoch (eg, the last possible date-time: @2147483647) and date-time in this specific format [[YYYY.]MM.DD-]hh:mm[:ss], where the [] indicate optional parts. The script assumes that the date command understands YYYY-MM-DD hh:mm:ss+zzzz, so the built-in command is not up to the job. I came to the conclusion that it was too painful to adapt the script.

This issue led me to post this summary of the commands missing from the basic CF that one might expect to be available in a shell script.
 
Andrea Edwards said:
so surely if a script uses a particular set of utilities, would it have been prudent to check that the necessary utilities are already available
Click to expand...

What an amazing insight!

I for one would not respond to any change requests (to a non-essential utility) that are submitted with sarcasm. Please respect the people who contribute to this project for free.
 
That being said, a formula like this can be inserted in a shell script to verify a dependent package:
Code: 
_cmp_dotted() { # ver1 <= ver2
    printf "%s\n%s\n" "$(echo $1 | sed -re 's/[a-zA-Z]//g')" "$2" |
        ( IFS='.~-' read -r a1 b1 c1 d1 _; IFS='.~-' read -r a2 b2 c2 d2 _; 
          a1=${a1:-0}; b1=${b1:-0}; c1=${c1:-0}; d1=${d1:-0}
          a2=${a2:-0}; b2=${b2:-0}; c2=${c2:-0}; d2=${d2:-0}
          [ "$a1" -lt "$a2" ] && return
          [ "$a1" -eq "$a2" ] && 
               { [ "$b1" -lt "$b2" ] && return
                 [ "$b1" -eq "$b2" ] && 
                     { [ "$c1" -lt "$c2" ] && return
                       [ "$c1" -eq "$c2" ] && [ "$d1" -le "$d2" ]
                       } } )
}
require_pkg() { # package [version]
    local v
    v=$(opkg status "$1" | grep -E '^Version:' | cut -f2 -d' ')
    # always an octal comparison if versions compared
    [ -n "$v" ] && { [ -z "$2" ] || _cmp_dotted "$2" "$v"; } ||
        { echo Package ${1}${2:+" (version >= $2)"} is missing >&2; false; }
}

#later
require_pkg coreutils || exit
#or
require_pkg coreutils 8.0 || exit
#or
require_pkg coreutils 8.0 2>/dev/null || opkg install coreutils
require_pkg coreutils 8.0 || exit
Possibly this shows why it wasn't done.
 
You must log in or register to reply here.
Back
Top