• The forum software that supports hummy.tv has been upgraded to XenForo 2.3!

    Please bear with us as we continue to tweak things, and feel free to post any questions, issues or suggestions in the upgrade thread.

Force DLNA Index, Auto Decrypt, Auto Shrink

Then use your favourite method of forcing a DLNA rescan. The above files will become indexed (but they don't show up in the humax on-screen menu, which is good). I used the following jim tkl script to obtain the URL since the web interface doesn't like the empty files:s
Click to expand...
Isn't the flaw in this plan that we don't have a reliable way of triggering a DLNA rescan on demand from the custom firmware.
Possibly the helper files could be created in advance based on the recording schedule so they are indexed ready for use when Sweeper comes along to move/rename recordings
 
Black Hole said:
Does this trick make it possible to stream from a recording which is currently in progress?
Click to expand...

Yes.

MymsMan said:
Possibly the helper files could be created in advance based on the recording schedule so they are indexed ready for use
Click to expand...

Exactly.


I had a go at implementing this within the webif auto-decrypt. What I've done seems to work very well. It creates the helper link files within [Deleted Items] so that they don't distract the user too much and this also means that sweeper won't try to relocate the links themselves.

Before I release the code I'll see if I can rewrite it as a separate, optional, plugin - since the current version involves some changes to the core "auto" process.
 
Oatcake said:
I had a go at implementing this within the webif auto-decrypt. What I've done seems to work very well. It creates the helper link files within [Deleted Items] so that they don't distract the user too much and this also means that sweeper won't try to relocate the links themselves.
Click to expand...
That sounds excellent and I don't mind changes to the core code for an improvement like this - I'm always happy to accept patches! We'll have to accommodate users who have not installed undelete but that should be possible. I have something else that I haven't released yet which is using the new recmon framework to trigger an auto run as soon as a recording completes. The two changes would work very well together.
 
Could this modification be used to stream the time shift buffer? If so, you would be able to stream live TV on your network with live pause functionality.
 
Oatcake said:
I had a go at implementing this within the webif auto-decrypt. What I've done seems to work very well. It creates the helper link files within [Deleted Items] so that they don't distract the user too much and this also means that sweeper won't try to relocate the links themselves.
Click to expand...
If you keep the helper files in [Deleted Items] won't they get deleted eventually? You could create a folder called [Helper], for example. The brackets around the folder name should prevent unwanted custom firmware operations. Creating this folder could be part of the package functionality so the undelete package would not be a dependency.
 
MontysEvilTwin said:
If you keep the helper files in [Deleted Items] won't they get deleted eventually? You could create a folder called [Helper], for example. The brackets around the folder name should prevent unwanted custom firmware operations. Creating this folder could be part of the package functionality so the undelete package would not be a dependency.
Click to expand...
Does it matter if they are deleted after a few days - by then the actual recordings should have been indexed. The helper files are just to provide a valid index to the file before it would otherwise be available.

Is there any possibility that having the DLNA index early would allow decryption to start whilst the recording was still in progress reading the file in chase play mode and then piping the output into subsequent packages such as Detectads and Crop?
 
This sounds like the first major advance we've had for a while. :doublethumbsup:

There may be a problem initiating decrypt while the recording is in progress - there is nothing currently regulating the "playback speed" during decryption, so what will happen when the chase-play reaches the live point?
 
To update everyone - I have passed my code on to af123. No doubt it will be tested and probably improved (rewritten :-) before inclusion in the next release of webif so it may take some days for this to be done. But af123 does seem to be very speedy so who knows. FYI the code I wrote would have updated the time of the link files once a day to help prevent deletion but maybe a place other than deleted items would be better.

Regarding decrypting during recording, I think it would be possible. I know that the command "curl" can be used to fetch a pre-determined section of a file from the Humax media server. So a recording could probably be fetched piecemeal, in blocks, as the recorded size goes past configured thresholds. I think the first step though is to concentrate on getting sweeper, decrypt, etc running back-to-back, robustly, very soon after recording finishes.

I'll have a look, maybe tomorrow, to see if the time shift buffer can be viewed.
 
What is the difference (if any) between downloading by DLNA and DNLA streaming? File decryption on the HDR-FOX happens much more quickly than the recording would take to play, but I can stream a programme from the HDR-FOX to a smart TV by DLNA, for example. The TV has no hard drive attached so presumably it must limit the download speed to what it requires to play the recording in real time. So are any special measures needed (other than Oatcake's code) to play an ongoing recording?
 
There is no difference between downloading by DLNA and streaming other that the client end only requesting data at the rate that it needs it.

Regarding the TSR buffer, there are going to be problems. For one thing, it is a circular buffer so if the live channel has been running for more than two hours starting the play from the start of the file isn't going to get the right result. It's anybody's guess what the DLNA server will do with it - we have no control over that.

Another problem is going to be creating a .HMT file to persuade the Humax to decrypt it.
 
Last edited:
Black Hole said:
There may be a problem initiating decrypt while the recording is in progress - there is nothing currently regulating the "playback speed" during decryption, so what will happen when the chase-play reaches the live point?
Click to expand...

Speed mismatches are common in Pipelined processing systems, usually when a faster program run out of input data it just waits for more input to becomes available and if a fast program is feeding a slower program the output is buffered until it can be consumed

Pipelines usually work with Stdin/Stdout so some, possibly significant, changes would be needed to the webif programs to allow them to be be pipelined but there are already example of piping within the webif - for example in the detectads package the output of ffmpeg is piped into an analysis program the output of which is piped into the jim/tcl code of the webif
 
There is a fly in that ointment: the DLNA server is part of Humax's "black box" code, with no certainty that it will behave nicely if it comes to the current end of an in-progress recording file (or even that it will know it has come to the end). There is only one way to find out: suck it and see. It's worth trying, just don't be surprised if it doesn't work out.
 
This streaming of a live buffer or recording is appealing to me. I presume that once it is implemented it will be explained to us all how to do it.
 
I believe the decryption method uses "wget"! wget allows the bandwidth it uses to be limited to a specific rate (--limit-rate=RATE). Therefore the rate could be set to be "definiately slower" than the rate at which a recording will be written. That might be useful for some of the above? One would probably want a delayed start to such processing (for example: 5 minutes).

And/or the wget could also be spawned as a separate process and "suspended" if the output file is getting too large compared to the input file; then "resumed" once things look okay again (there might be some caveats; and of course it is more work to implement that as a strategy).
 
Last edited:
I've got live TV streaming working using Oatcake's method (post #38) which I have since tweaked a little.
First I created the folder '[Live]' under 'My Video'. Then I navigated to that folder in Telnet (cd command) and created the dummy helper files (ts, htm and nts). Once these files were indexed by the DLNA server I used Oatcake's method to create symbolic links to the 0.ts, 0.hmt and 0.nts files (in /mnt/hd2/Tsr/). I then accessed the helper.ts file on another HDR-FOX by DLNA (Media>Storage>Network). Success, it works!
The 0.ts file grows until it reaches 17.62GB and then it starts overwriting itself from the beginning. To completely clear the time shift buffer, delete the four files in the Tsr folder (FTP with root access) and change channels: new files are then created. You don't need to do this though and it is best if you don't (see below). If you start a recording on the channel you are viewing, the hmt file is deleted from the Tsr folder, and is recreated when it completes. I don't know what happens if you are viewing the live stream by DLNA when the hmt file is deleted but I have made some changes.
After you are set up, you can delete the symbolic link to the nts file from the [Live] folder: it is not needed. I also deleted the link to the hmt file. It needs a hmt file but it is not too fussy. Copy a hmt file from a recording into the [Live] folder. I used one without the 'Enc' flag set (this might not be necessary) but from a recording that had not been decrypted (no 'Dec' flag): this is essential. If you change channels on the remote HDR-FOX and then start DLNA streaming on the local one, the stream starts from when you changed channels. If you change channels on the remote HDR-FOX you may have to restart the stream on the local one when you get to the end: not fully tested yet. Also, the length of the 'programme' corresponds to the entire time shift buffer (2 hours*): if you clear the buffer this will be shorter and you will have to restart the stream when it hits the end.
Still some testing to do. It seems to work with both standard def. and high def. streams. I have also managed to stream (without any transport controls) to my android tablet (Skifta and MX Player), even in high def.

Edit. * With a full (17.62GB) 0.ts file the green time bar is 8-9 hours. You can't can skip past the end of the current stream into a previous stream in the time shift buffer, and you can skip within the active stream. If you go too far, you get a black screen and can skip in to a previous stream if you keep pressing the skip forward button, but you can get back to the active stream by pressing the skip back button a few times. The stream still works while recording the same channel as you are viewing. It actually works rather well. On the Android tablet, the rewind and and fast forward don't work but you can pause the stream.
 
Last edited:
Actually I won't bother posting my observations in the other thread, for they closely match those of MontysEvilTwin above!

Just an additional thought: A quick test like this doesn't take very long to set up, but I get a strong feeling that turning this into a slick & robust viewing experience would probably take quite a lot of work.

A feature I would like though (and I might have a go at developing it) after having missed the dreaded popup "TSR will stop and the recording will start from the current broadcasting point. Continue?" several times - if there was a webif button to dump the missed TSR contents into a standard recording.
 
You must log in or register to reply here.
Back
Top