Accessing 0.ts Remotely

Black Hole

Black Hole

May contain traces of nut
On the HDR-FOX, there is a file /mnt/hd2/Tsr/0.ts which I understand is the live TSR buffer. The question is: is there a way to make this file playable across the network?

What I have tried so far:
  • Create a symbolic link in My Video:
    .
    cd /media/"My Video"
    ln -s /mnt/hd2/Tsr/0.ts 0.ts
    .
    The result of this is a "0.ts" entry listed in the WebIF media browser in My Video, with a size of about 6GB. It is also listed in the Samba mount on the HD-FOX, but when I try to play it I get "cannot support this file format".
    .
  • According to the WebIF media browser, the 0.ts symbolic link has not been indexed for DLNA, and it is not listed on the HDR-FOX media browser. Could this be due to the missing sidecar files?
    .
  • Create a new Samba mount at the HD-FOX (using network shares automount) that mounts /mnt/hd2/Tsr. The 0.ts is not listed.
    .
  • Install MediaTomb, and configure it to serve from /mnt/hd2/Tsr. On the HD-FOX, Media >> Storage (blue) >> Network shows up the MediaTomb server (in addition to the HDR-FOX native server), and 0.ts is listed. Play, and I get "cannot support this file format".
Short of adding symbolic links to the .htm and .nts files, I'm out of ideas. I don't think it is that the 0.ts is encrypted, because encrypted files are usually reported as "scrambled" (it is only the video data that gets encrypted, not the container format).

Anybody?
 
I had a few goes at this last night too. I tried VLC and XBMC on a Mac accessing the file via Mediatomb and via an NFS mount and neither of them can play it. Thing is, I'm sure I've done this in the past although it would have been with an older software version.

However, certainly on mine, the .hmt file flags indicate that it is encrypted.

Code: 
humax# hmt /mnt/hd2/Tsr/0 | grep enc
Raw file is encrypted on disk.
 
Okay, so if I cp 0.* /media/"My Video", the copy might play natively. If I select LCN 105 first it should stop write activity.

If that works I will have to put more thought into making 0.* available by DLNA.
 
Aarrggghhhh!!! Stop the TSR by detuning and the .htm file vanishes! If I copy the .ts is there a way to mark it as encrypted?
 
Having an option in Webif that regenerates the sidecar files would be useful. It could be put in the OPT+ menu and be enabled when a TS file is selected that has sidecar files missing. It would allow TS files that have been copied off of the HDR without the sidecar files to be played correctly when copied back. Also recreate them when other routines have corrupt them.
 
I think AV2HDR does that doesn't it? But it would be useful to have a similar utility running locally.
 
I copied the 0.ts into My Video and it shows up in the WebIF... but in the native media browser as a broken AVI. Play results in "cannot support this file format" (again).
 
On an earlier version of the firmware I tried playing this file by copying it to the main folder - renaming it and then using the remote
to move it to the virtual disc (which should have decoded it?)
But I was not able to play it on or off the box so I gave up presuming the encryption is different
 
It would only be decrypted on USB/virtual copy if there was an hmt file to say it was encrypted in the first place. I'm going to try adding a symbolic link to the hmt, but I don't know what happens when the actual hmt keeps getting deleted and created again.
 
Well, adding the link to 0.hmt changed the results a little: still not listed natively (the media browser must be able to tell it's a link not a file), but via the network mount it shows up as an unnamed file of 0 minutes duration, with a lightning icon. 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.

The next idea is to create a fake 0.hmt file to go with the 0.ts symbolic link - advice appreciated.

Hard links rather than symbolic links are another possibility - comments? I don't know very much about this stuff.

Edit: I just realised it must be picking up a display name from the .hmt, so the 0.hmt file presumably contains no name to display. I must have a dig!
 
you could try a mount --bind rather than an ln -s but whether that will be enough to persude it to work is another matter
 
Black Hole said:
Hard links rather than symbolic links are another possibility - comments? I don't know very much about this stuff.
Click to expand...
It might be an option. A hard link is just another directory entry pointing to the same area on disk. The app will almost certainly see it as a normal file. Unlike symbolic links, if you delete the original directory entry after creating a hard link, the file can still be accessed - the end result is the equivalent of a rename (mv) operation. Hard links can only be created on the same partition as the original directory entry.
 
I've just taken a step back to see where this is going.

It's interesting to see if the 0.ts can be played locally for the insight how things work, but not needed in any practical sense.

Creating access via network mount is pointless, because the suspicion now is that the file is encrypted (might be interesting to step back a few firmwares and see when this happened).

The only way we know to get an encrypted file out to the network is by DLNA, so the real thrust has to be to create the conditions that will fool the indexer into accepting the 0.ts as a legitimate target. It might be possible to do this with an engineered .htm file and a hard link to the 0.ts - at least both Tsr and My Video are on /mnt/hd2 (I think).

If this can be done there will be a way to view live TV from a networked HD-FOX without an aerial feed.
 
I have to admire the perseverence ;-)

Stepping back once more isn't it interesting how the paranoic protectionism in the various media industries
gets in the way of users comfort even when there is no advantage or value to be gained by their doing so?
 
I experimented with the 0.ts a while back as it would be particularly useful on the HD, as there is no"retrospective" time shift recording. My plan was to use nicesplice to append the 0.ts to the recording to recover missed beginnings. Also useful on the HD for 2 channel recording, as though you can watch, and time shift, another channel (on the same MUX), you can only record channel.

I could get a 0.ts playable, but only if it had one channels recordings in it. To do this you have to delete 0.* in .tsr, and switch channel (or reboot - can't quite remember) to get it created from scratch again. I think its basically a circular buffer, and if there are multiple channels in there, when you try and play it as a normal recording it gets upset due to the program / channel IDs not matching what is in the hmt. The trick would be to locate the current start position in the buffer and extract the current portion (and the matching portion of the nts). Another approach would be to force all the PIDs etc to match thoughout the buffer so it thought the entire buffer was from one channel. Could still get messy if there is a mix of SD / HD recordings in there.

Could be worth trying to copy it to a usb to decrypt it and maybe PC players wouldn't be so fussed about the mix of PIDs in there. I think it was encrypted in the normal way, but maybe not - be good if it wasn't as is opens up the slim possibility of streaming live TV to a PC...
 
Food for thought.

Manipulating the 0.ts is not an option for my application, though if one is desperate to retrieve something from it as a one-off it might be a possibility.
 
Just did a few quick experiments - it is encrypted (on the HD at least), but can be decrypted with a copy to external drive via remote (in HDR mode etc). It's not simple to play it on the box without a bit of effort to construct a normal hmt file, but it does play in VLC and quicktime.
 
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.
 
Oh dear, my symbolic link to the currently nonexistent 0.hmt crashes the WebIF media browser:

Code: 
Runtime Error: browse.jim:114: could not read "/media/My Video/0.hmt": No such file or directory in procedure 'entry' called at file "browse.jim", line 319 at file "browse.jim", line 114
 
You must log in or register to reply here.
Back
Top