Accessing 0.ts Remotely

Black Hole said:
Aha! I have at least scored one small dividend out of this:

Code: 
ln -s /mnt/hd3/Streamer_down_file /media/"My Video"/Streamer.mp4

..makes the iPlayer stream play directly from the normal Samba mount, with full transport control (FF/REW is a bit dodgy), while it's still downloading. The timeline knows how long the programme should be, but scrolling past the current end of the download results in a "cannot support this format" message.
Click to expand...

This also makes the size of the current download inspectable from the WebIF media browser, when it stops increasing it is safe to save off.
 
I can't see the o.ts file of the HDR Fox T2 but I can see and play the 0.ts direct stream from the Foxsat HDR in windows media center.
 
Adrian Web said:
I can't see the o.ts file of the HDR Fox T2
Click to expand...
How are you looking for it? 0.ts will not show up in any of the "normal" ways, but by Telnet it will be found:

ls -l /mnt/hd2/Tsr

or by FTP you will need to disable the native FTP server and install the beta-ftp package (which provides unlocked access to the file system).
 
I only want to access it in the "normal" way as sometimes I stream live TV to my laptop. I'll just use the Foxsat instead.
 
One thing I'd love the HDR T2 to do is stream live TV, however, this doesn't look possible. I came across this thread which has the interesting idea if moving the timeshift TSR files to the "My Video" directory so they could be accessed.

I had a look at this and it seems possible to do this. You can create hard or symbolic links for the .ts and .nts files, but the .hmt file is always overwritten. Therefore you'd have to write a script that constantly checks and compares the hmt files in "My Video" and "Tsr" directories to see if they differ - they're only going to differ if someone changed channels and the 0.ts stream starts again.

Something like this would do it (it checks the inode of the hmt files to see if they are the same and if not, create a hard link between the two). A hard link means the two files share the same inode. There's no real point in doing this except that I don't have to track the inode in another file:

Code: 
#!/bin/sh
 
tsr_old="/mnt/hd2/Tsr"
tsr_new="/mnt/hd2/My Video/0"
 
# check hmt file
while true ; do
  hmt_old_inode=`ls -i "$tsr_old/0.hmt" | awk '{print $1}'`
  hmt_new_inode=`ls -i "$tsr_new/0.hmt" | awk '{print $1}'`
  if [ "$hmt_old_inode" != "$hmt_new_inode" ]; then
    cp -p "$tsr_old/0.hmt" "$tsr_new/0.hmt"
    rm -f "$tsr_old/0.hmt"
    ln "$tsr_new/0.hmt" "$tsr_old/0.hmt"
    hmt -protect "$tsr_new/0"
  else
    sleep 5
  fi
done

But the I came across this problem:
Black Hole said:
Trying to play it results in a message "Recording (less than 30 secs) may not be stored.", though interestingly it had the "new" flag to start with and that went away.
Click to expand...
Looking at the file format, it looks like the two bytes after the start and end times cause this, i.e. bytes 0x288 and 0x289:

Code: 
00000280  BA 5A 29 51 4C 79 29 51 8B 1E 00 00 02 08 03 00 .Z)QLy)Q........

In this example, the two bytes have the values 8B and 1E and they're from a real hmt file (not TSR). For a TSR these bytes seem to be 00 00. If I change these to 8B 1E the file no longer gives the 30 second error - so this looks like the duration of the video. However, this differs from the duration the hmt binary returns. If you calculate 8B 1E (swap them to 1E 8B) it's 7819 seconds - hmt binary returns 7826 seconds for this file. This value seems 7 or 8 seconds lower than that returned by hmt (maybe it uses scheduled time rather than actual duration?)

Not sure if this will get the video playing - I'll keep looking at it.
 
dma said:
This value seems 7 or 8 seconds lower than that returned by hmt (maybe it uses scheduled time rather than actual duration?)
Click to expand...
The hmt utility subtracts the scheduled start time from the scheduled end time to display scheduled duration, and similarly the actual start from the actual end to show duration. In Raydon's analysis of the file format, bytes 288 & 289 are unknown - some kind of duration makes sense given the location in the file.

I just tweaked hmt to dump out the calculated duration, 0x288/9 value and the difference and ran it against a set of recordings. The first number is the calculated duration, second is from 0x288 and the bracketed number is the difference. It seems that 0x288 does indeed store a duration.

Code: 
Duration debug: 3963 3959 (-4)
Duration debug: 3719 3719 (0)
Duration debug: 3655 3649 (-6)
Duration debug: 3758 3749 (-9)
Duration debug: 2141 2139 (-2)
Duration debug: 3755 3749 (-6)
Duration debug: 1984 1979 (-5)
Duration debug: 3680 3679 (-1)
Duration debug: 3629 3629 (0)
Duration debug: 3782 3779 (-3)
Duration debug: 3849 3849 (0)
Duration debug: 3760 3759 (-1)
Duration debug: 3756 3749 (-7)
Duration debug: 3532 3529 (-3)
Duration debug: 3685 3679 (-6)
Duration debug: 3750 3749 (-1)
Duration debug: 3490 3479 (-11)
Duration debug: 3452 3449 (-3)
Duration debug: 3748 3739 (-9)
Duration debug: 3797 3789 (-8)
Duration debug: 3655 3649 (-6)
Duration debug: 3805 3799 (-6)
Duration debug: 3761 3759 (-2)
Duration debug: 4032 4029 (-3)
Duration debug: 3968 3959 (-9)
Duration debug: 3759 3759 (0)
Duration debug: 2121 2119 (-2)
Duration debug: 3828 3819 (-9)
Duration debug: 3751 3749 (-2)
Duration debug: 3767 3759 (-8)
Duration debug: 3803 3789 (-14)
Duration debug: 3692 3689 (-3)
Duration debug: 3784 3779 (-5)
Duration debug: 3750 3749 (-1)
Duration debug: 3686 3679 (-7)
Duration debug: 3724 3719 (-5)
Duration debug: 3701 3699 (-2)
Duration debug: 3743 3739 (-4)
Duration debug: 3755 3749 (-6)
Duration debug: 3544 3539 (-5)
Duration debug: 3760 3759 (-1)
Duration debug: 3756 3749 (-7)
Duration debug: 3785 3779 (-6)
Duration debug: 3720 3719 (-1)
Duration debug: 3755 3749 (-6)
Duration debug: 3726 3719 (-7)
Duration debug: 3687 3679 (-8)
Duration debug: 3802 3769 (-33)
Duration debug: 3695 3689 (-6)
Duration debug: 3713 3709 (-4)
Duration debug: 3698 3689 (-9)
Duration debug: 3754 3749 (-5)
Duration debug: 3777 3769 (-8)
Duration debug: 3737 3729 (-8)
Duration debug: 3760 3759 (-1)
Duration debug: 2709 2709 (0)
Duration debug: 3770 3769 (-1)
Duration debug: 3974 3969 (-5)
Duration debug: 3753 3749 (-4)
Duration debug: 3817 3809 (-8)
Duration debug: 3699 3699 (0)
Duration debug: 3718 3709 (-9)
Duration debug: 3730 3729 (-1)
Duration debug: 3732 3729 (-3)
Duration debug: 3768 3759 (-9)
Duration debug: 3926 3919 (-7)
Duration debug: 3736 3729 (-7)
Duration debug: 3833 3829 (-4)
Duration debug: 3735 3719 (-16)
Duration debug: 3762 3759 (-3)
 
One thing I forgot to mention was, why was I looking at this section. With a TSR file, no end time is defined, output from hmt is as follows:

Code: 
Recording start:1384101537 (Sun Nov 10 16:38:57 2013)
Recording end:4294967295 (Wed Dec 31 23:59:59 1969)

That's one second less than epoch start time (1st Jan 1970). Therefore end time translates to FF FF FF FF:

Code: 
00000280  A1 B6 7F 52 FF FF FF FF 00 00 00 00 00 00 01 00

This makes sense since it's an open-ended stream, but it may explain why the duration is 0. If anything comes of this, at least we now know what 2 more bytes in the file format do! :)
 
You must log in or register to reply here.
Back
Top