Media List Order Modification

Black Hole

Black Hole

May contain traces of nut
I am trying to arrange that a set of recordings (including some MP4 downloads) appear in the correct order for my supported user. The default media list sort order is newest recording first. You would think that means it is keyed on the file timestamp...

Right, I thought, I'll just use the Linux 'touch' command to update the timestamps in the order I want them... Sure enough, the WebIf media browser now lists them in the expected order.

But the SUI media list doesn't, they persist in being listed in the file creation order.

Does Linux have separate file creation and file modification timestamps?

The media list shows the recording date and time for the .ts files, and the file creation date/time for the .mp4 files. The former could be derived from the .hmt files. If so, how can I change the recording start time in them - the hmt utility doesn't seem to support that?
 
Black Hole said:
If so, how can I change the recording start time in them - the hmt utility doesn't seem to support that?
Click to expand...
It does, but it involves lots of horridness with the read32/patch32 commands and Unix epoch timestamp conversions etc.
 
So, is it the time stamps or the .hmt that defines the media list sort?

The .ts are in the right order, the .mp4 need ordering. I suppose it might be easier to adjust the time stamps on them (with something other than 'touch').
 
Last edited:
OK, here's what I have deduced:
  • If a media file is "naked" (no .hmt file), the sort date is the modification date logged in the file system (this includes naked .ts files);
  • If a .ts file has a .hmt sidecar file, the sort date is the recording start time logged in the .hmt file.
I have proved the former by test cases, but only deduced the latter from observation - I have not tried modifying .hmt files to see what happens, but the data displayed on the SUI media list can only have come from the .hmt (when present), and removing the associated .hmt from a .ts results in the first clause.

This means that, in order for the WebIF media browser to properly mimic the SUI sort order, it needs to sort as above (and put folders in the list first).

To provide a facility to arrange the order recordings appear on the SUI, a convenient means of manipulating the timestamps in the .hmt would be useful.
 
Bugger! Copying my carefully prepared folder (including the noflatten flag) to the supported user's loan HDR-FOX failed to copy the flag so I was left with the .mp4's and all the .ts's flattened, but the .mp4's were touched by the copy so the order was wrong again when the .ts's were moved back! Bum, bum, bum!!!
 
If you do modify the start time in the hmt you should also modify the end time to match.
Although there is a duration in the hmt the humax (and webif) don't use it and instead calculate duration as end-start.

The alternative to modifying the recording time is to use TVDB integration / dedup / Swweper to modify file name and title to include the series and episode numbers so that it doesn't matter if episodes are recorded out of order
 
Look at this thread here - Oatcake created a script to modify hmt file timestamps.

For my own personal use, I tweaked the script provided by Oatcake in the following ways:
Changed the name to 'rectime'
Tweaked the usage example (type 'rectime' at the command line) to include the '.ts' extension. The original script used the touch command to set the timestamp of hmt file to match the calculated new end time. If you include the '.ts' extension it does this to the '.ts' file instead so the order in the SUI will match that in Webif.
Added a prompt to set the BST 'flag' ('y' sets to BST, 'n' to GMT)
Added a patch command to make the scheduled start time in the hmt file match the modified actual start time.

I have attached this version below. To use it, remove the '.txt' extension, copy to a suitable location (e.g. /mod/usr/bin) and give it execute permissions (e.g. chmod 755). Type 'rectime' at the command line for the syntax and enclose the filename in quotes if there are spaces. To reiterate, Oatcake wrote the script. I hope I have not acted out of turn by posting my tweaked version.
 

Attachments

  • rectime.txt
    0 bytes · Views: 8
Something seems to have gone wrong with the file attachment in the previous post and I don't seem to be able to replace it. I also tried posting it in a zip file but that went wrong too. Here is the modified script as text:
Code: 
#!/bin/sh
set -e

if [ $# != 3 ]; then
  echo "Usage: $0 <date> <time> <filename>"
  echo "  eg. $0  2017-05-05  14:00  programme.ts" 
  exit 1
fi

d=$1
t=$2
hmt=$3

while true; do
    read -p "Set the BST flag [y,n]?" yn
    case $yn in
        [Yy]* ) hmt +patch16=1076:3600 "$hmt"; break;;
        [Nn]* ) hmt +patch16=1076:0 "$hmt"; break;;
    esac
done

start=`hmt "$hmt" |grep "Recording start"|awk -F'[: ]' '{print $3;}'`
end=`hmt "$hmt" |grep "Recording end"|awk -F'[: ]' '{print $3;}'`

let len=$end-$start

newStart=`date +%s -d"$d $t:00"`
let newEnd=$newStart+$len

hmt +patch32=640:$newStart "$hmt"
hmt +patch32=644:$newEnd "$hmt"
hmt +patch32=1272:$newStart "$hmt"

touch -t @$newEnd "$hmt"
 
Last edited:
@MET - thanks for that. Tweaking and passing on is entirely within the spirit of Creative Commons, so no worries there!

MymsMan said:
If you do modify the start time in the hmt you should also modify the end time to match.
Click to expand...
That's the kind of thing I had in mind for extended functionality in the WebIF "Rename" dialogue.

MymsMan said:
The alternative to modifying the recording time is to use TVDB integration / dedup / Swweper to modify file name and title to include the series and episode numbers so that it doesn't matter if episodes are recorded out of order
Click to expand...
I have already used Rename to provide a serial in the media list title, but still regard out-of-order listing as "user unfriendly". It's bad enough that they are listed in reverse, but there's nothing I can do about that when there are new episodes to be added.

That simply copying (SUI) a file updates its time stamp is a significant pain. Maybe if I had used WebIF for the copy instead of SUI it might have been preserved (command line is last resort).
 
This does not help if you are trying to order a mixture of mp4 files and ts files (with hmt etc.) but if you have the undelete package installed the file timestamp is updated when a file is deleted, but is not updated if you copy the file back from the deleted items folder. So if you have a folder containing files to be ordered, if you delete them with Webif in the required order, when you then cut and paste them back (OK to do this in one block action) they will now be in order.
 
MontysEvilTwin said:
Added a prompt to set the BST 'flag' ('y' sets to BST, 'n' to GMT)
Click to expand...

The TZ is implied by the date-time apart from the hour 01:00-02:00 when BST changes to GMT. If you don't mind not being able to set the time to a value 01:00-01:59 GMT on that one day per year, you could instead try something like:

Code: 
if [ "`date -d "$1 $2" +%Z 2>/dev/null`"= "BST" ]; then
        hmt +patch16=1076:3600 "$hmt"
else
        hmt +patch16=1076:0 "$hmt"
fi

No doubt an optional $4=TZ could be added to handle the missing hour. Unfortunately our date command (Busybox) doesn't understand TZ data in the -d parameter, or it would be easy to handle the issue entirely with 'date -d'. Also, Humax, boo to saving date-time data in local time.
 
Last edited:
/df said:
The TZ is implied by the date-time apart from the hour 01:00-02:00 when BST changes to GMT . If you don't mind not being able to set the time to a value 01:00-01:59 GMT on that one day per year, you could instead try something like:

Code: 
if [ "`date -d "$1 $2" +%Z 2>/dev/null`"= "BST" ]; then
        hmt +patch16=1076:3600 "$hmt"
else
        hmt +patch16=1076:0 "$hmt"
fi

No doubt an optional $4=TZ could be added to handle the missing hour. Unfortunately our date command (Busybox) doesn't understand TZ data in the -d parameter, or it would be easy to handle the issue entirely with 'date -d'. Also, Humax, boo to saving date-time data in local time.
Click to expand...
Thanks, I'll try it out. I knew this was possible, just beyond my limited skills to program.
 
/df said:
Unfortunately our date command (Busybox) doesn't understand TZ data in the -d parameter, or it would be easy to handle the issue entirely with 'date -d'.
Click to expand...

You can have the full date command by installing the coreutils package. With that in place, you can punt the date-time handling to the date command, allowing a TZ element in the date-time parameter if needed. In either case, the final touch command wants the -d option, not -t, with the @epoch date format.

Also, according to https://wiki.hummy.tv/wiki/HMT_File_Format, the times are stored as epoch, ie relative to UTC. I suggest that the magic number 3600 in the DST field is just the TZ offset in seconds, stored as a 2s-complement 16-bit value, which would make sense in a product sold in various countries; obvs in UK the non-DST value is 0. If so, I wish to unboo Humax.

The result would be some variant of the code below:

Code: 
#!/bin/sh
set -e

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

# condition the date-time with TZ and 0 seconds
dt=`date -d "$1" +"%F %H:%M:00%z"`
# is this file worth it?
hmt=$2
[ -f "$hmt" ] || { echo "\"$hmt\": no such HMT file" 1>&2; exit 1; }
hmt "$hmt" | grep -v -m 1 "Invalid HMT file,">/dev/null || { echo "\"$hmt\": invalid HMT file" 1>&2; exit 1; }
[ -w "$hmt" ] || { echo "\"$hmt\" can't be written" 1>&2; exit 1; }

# patch DST flag - for non-UK use, other DST strings would apply, eg WEST, CEST, EEST in Europe
if [ "`date -d "$dt" +%Z`"= "BST" ]; then
        hmt +patch16=1076:3600 "$hmt"
else
        hmt +patch16=1076:0 "$hmt"
fi

#or if this flag is actually a UTC TZ offset, something like this instead of the if ... fi above:
#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}; hmt +patch16=1076:-$((60*(60*${tz%:*}+${tz#*:}))) "$hmt";;
#    *)    tz=${tz#0}; hmt +patch16=1076:$((60*(60*${tz%:*}+${tz#*:}))) "$hmt";;
#esac

start=`hmt "$hmt" |grep "Recording start"|awk -F'[: ]' '{print $3;}'`
end=`hmt "$hmt" |grep "Recording end"|awk -F'[: ]' '{print $3;}'`
# or, without grep+awk:
#for v in `hmt +read32=640 "$hmt"`; do
#    start=$v; break
#done
#for v in `hmt +read32=644 "$hmt"`; do
#    end=$v; break
#done

let len=$end-$start

newStart=`date +%s -d"$dt"`
let newEnd=$newStart+$len

hmt +patch32=640:$newStart "$hmt"
hmt +patch32=644:$newEnd "$hmt"
hmt +patch32=1272:$newStart "$hmt"

touch -d @$newEnd "$hmt"

Updated here.
 
Last edited:
/df said:
You can have the full date command by installing the coreutils package. With that in place, you can punt the date-time handling to the date command, allowing a TZ element in the date-time parameter if needed. In either case, the final touch command wants the -d option, not -t, with the @epoch date format.

Also, according to https://wiki.hummy.tv/wiki/HMT_File_Format, the times are stored as epoch, ie relative to UTC. I suggest that the magic number 3600 in the DST field is just the TZ offset in seconds, stored as a 2s-complement 16-bit value, which would make sense in a product sold in various countries; obvs in UK the non-DST value is 0. If so, I wish to unboo Humax.

The result would be some variant of the code below:

Code: 
#!/bin/sh
set -e

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

# condition the date-time with TZ and 0 seconds
dt=`date -d "$1" +"%F %H:%M:00%z"`
# is this file worth it?
hmt=$2
[ -f "$hmt" ] || { echo "\"$hmt\": no such HMT file" 1>&2; exit 1; }
hmt "$hmt" | grep -v -m 1 "Invalid HMT file,">/dev/null || { echo "\"$hmt\": invalid HMT file" 1>&2; exit 1; }
[ -w "$hmt" ] || { echo "\"$hmt\" can't be written" 1>&2; exit 1; }

# patch DST flag - for non-UK use, other DST strings would apply, eg WEST, CEST, EEST in Europe
if [ "`date -d "$dt" +%Z`"= "BST" ]; then
        hmt +patch16=1076:3600 "$hmt"
else
        hmt +patch16=1076:0 "$hmt"
fi

#or if this flag is actually a UTC TZ offset, something like this instead of the if ... fi above:
#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}; hmt +patch16=1076:-$((60*(60*${tz%:*}+${tz#*:}))) "$hmt";;
#    *)    tz=${tz#0}; hmt +patch16=1076:$((60*(60*${tz%:*}+${tz#*:}))) "$hmt";;
#esac

start=`hmt "$hmt" |grep "Recording start"|awk -F'[: ]' '{print $3;}'`
end=`hmt "$hmt" |grep "Recording end"|awk -F'[: ]' '{print $3;}'`
# or, without grep+awk:
#for v in `hmt +read32=640 "$hmt"`; do
#    start=$v; break
#done
#for v in `hmt +read32=644 "$hmt"`; do
#    end=$v; break
#done

let len=$end-$start

newStart=`date +%s -d"$dt"`
let newEnd=$newStart+$len

hmt +patch32=640:$newStart "$hmt"
hmt +patch32=644:$newEnd "$hmt"
hmt +patch32=1272:$newStart "$hmt"

touch -d @$newEnd "$hmt"
Click to expand...
You are right, the date and time information in the hmt is in epoch format. What I loosely called a 'BST flag' is an hour offset in seconds; this is in the hmt format document in the wiki. Thanks for spending time improving the script.
 
You must log in or register to reply here.
Back
Top