Streaming to TV

[Bradley Joy]

Hi

Firstly I wanted to say hi to everyone. Over the last couple of weeks, I’ve enjoyed scouring through the forum whilst setting up my HDR T2 box – it’s been very helpful.

I changed from a Panasonic PVR as I found the media list very bulky looking, the interface clumsy and the lack of control limiting (I owned a Topfield before). I was hoping the Hummy, with custom firmware would be the answer.

Anyhow – I have installed the latest firmware for it, added packages like Sweeper etc. but still find the media list very big looking – I normally have to scroll through lots of pages to find what I am looking for. I have tried putting recordings into folders, but then the newer episodes still go at the top level unless I set Sweeper up (which I haven’t yet).

I got VERY excited when my Panasonic TV picked up the Hummy content via DLNA as I use the TV to stream from the WD My Book hard drive and the interface is clean. However I soon realised the TV doesn’t play the Hummy .ts files, even after setting up auto-decrypt.

This is very frustrating and I have spent hours scouring the internet to find an answer with no joy. I thought I’d found the answer with the Convert Files plug in but it only works for the Freesat box L

I would like to do it all on the box if possible (although I did play around with the All Case app last night to avoid the Hummy media list).

Has anyone else had any luck with this – or is it possible to change the listing format of the media list? Or is there an alternative Humax machine that will stream to a TV? Apologies for the new thread on it.

Apart from that, I have been very impressed with the machine, the custom firmware, remote scheduling (although it ignores BBC1 for some reason) etc.

Its just this one thing which is driving me mad so any help would be very much appreciated.

All the best

 

[raydon]

I got VERY excited when my Panasonic TV picked up the Hummy content via DLNA as I use the TV to stream from the WD My Book hard drive and the interface is clean. However I soon realised the TV doesn’t play the Hummy .ts files, even after setting up auto-decrypt.

This is very frustrating and I have spent hours scouring the internet to find an answer with no joy. I thought I’d found the answer with the Convert Files plug in but it only works for the Freesat box L

I would like to do it all on the box if possible (although I did play around with the All Case app last night to avoid the Hummy media list).

Has anyone else had any luck with this – or is it possible to change the listing format of the media list? Or is there an alternative Humax machine that will stream to a TV?

After responding to your question about the convertfiles plug-in for the Foxsat HDR over on AVForums, I had another think about it and remembered that the stripts utility used by the "Shrink" option in the web interface can also fix the PAT (Program Association Table) packets in the transport stream (which is one of the things that convertfiles does). However, you need to use the -f switch to enable it.

HDRFOXT2 ~ # stripts
Humax TS Stripper Tool v1.2.5, by af123, 2012-13.
 
Syntax: stripts [options] <input> [output]
    -a          Analyse an input file.
    -A          Quickly analyse an input file.
    -c          Check if there are any EIT packets.
    -C          Show address of first EIT packet.
    -D          Dump NTS file.
    -E          Check if file is encrypted.
    -f          Also fix PAT packets.
    -F          Only fix PAT packets.
    -T          Dump TS file.
    -v          Verbose.
    -X          Add bookmarks at programme start/end.
    -z          Analyse entire TS file.
    -d [level]  Increase debug level or set debug level.

At present there is no settings option to enable/disable this feature, but you can turn it on yourself by editing one of the webif tcl scripts. From the "Diagnostics"page select the "File Editor" button. Click on "Open" and dig down to /mod/webif/html/browse/strip/execute.jim and look for this line near the bottom:

puts [exec /mod/bin/stripts \

and change it to include the -f option.

puts [exec /mod/bin/stripts -f \

(ensure you include the space before and after the -f you add in) then click n the "Save" button. After doing that, running "Shrink" on a recording will also fix the PAT packets. This could well fix your streaming problem to your Panny, I know it does for my Samsung TV (sadly SD only). Unfortunately, there is no guarantee, so just you'll just have to try it and see.

 

[Bradley Joy]

Thanks so much for all your replies regarding this - appreciate it. Will give this a try tonight and let you know how it goes. Should I still keep auto-decrypt on and add auto-shrink once i've made -f option change?

Thanks again

 

[raydon]

Thanks so much for all your replies regarding this - appreciate it. Will give this a try tonight and let you know how it goes. Should I still keep auto-decrypt on and add auto-shrink once i've made -f option change?

Thanks again

You need auto-decrypt for recordings to be playable on other devices. No need to add auto-shrink until you have first established that streaming works. You can "Shrink" on a per recording basis in order to test it out first. Try it for both SD and HD recordings, and remember that shrinking creates backups of the originals so it will eat up your disk space without regular housekeeping.
N.B. had to reboot to get DLNA server to reindex the recording after shrinking. Anyone know if this because of the epoch timestamp that shrink appends to the filename ? When is the DLNA database updated normally ?

 

[Black Hole]

You need auto-decrypt for recordings to be playable on other devices.

Irrelevant for DLNA streaming, but probably essential for stripts.

 

[Black Hole]

When is the DLNA database updated normally ?

The Humax standard is that the DLNA sweep occurs at the end of a recording and at boot time. If any processes occur the modify the recording after indexing, or if the recording is moved, the index entry becomes out of date. However, af123 has a way of poking the index - as used for the new 'instant' decrypt functionality.

 

[raydon]

You need auto-decrypt for recordings to be playable on other devices.

Irrelevant for DLNA streaming, but probably essential for stripts.

True, but I said playable on, not streamable to. As for stripts, it is essential that you decrypt first in order to fix the PAT packets, since you need to be able to rewrite the table. Otherwise no need, as you are simply stripping out EIT packets without having to read what's in them. This is probably why the stripts -f option is not made available in the web interface, because you need to guarantee that the file was decrypted first. In any case I believe the -f switch is just ignored if the file is encrypted. Strangely, the -f option also strips out the SDT (Service Descriptor Table) packets, which I thought would have been removed along with the EIT packets in the standard shrink operation, but aren't.

 

[raydon]

The Humax standard is that the DLNA sweep occurs at the end of a recording and at boot time. If any processes occur the modify the recording after indexing, or if the recording is moved, the index entry becomes out of date. However, af123 has a way of poking the index - as used for the new 'instant' decrypt functionality.

Thanks for the info, have not been following the recent developments in that area. If the stripts utility (or rather the execute.jim script which calls stripts) didn't append the epoch timestamp (much maligned by trev) to the filename there would be no need for the re-index. Not sure if this is really necessary since a 'shrunk' flag is also written to the hmt file anyway.

 

[prpr]

Why and how are the PAT packets broken in the first place?
(I don't like the epoch timestamp being appended either.)

 

[raydon]

Why and how are the PAT packets broken in the first place?

The broadcast PAT contains the full list of all program streams on the MUX (could be up to 10 or more in the list). The Humax only saves the stream of the program you have chosen, but does not attempt to rewrite the PAT list with this single program ID. Some DLNA clients will only work if the PAT contains only the ID of the program that's in the stream. The -f option in stripts addresses this by rewriting all PAT packets with this single program ID.

(I don't like the epoch timestamp being appended either.)

Easily removed by a small edit to execute.jim

- set newname "$shname-[clock seconds]"
- puts "Renaming file group to $newname"
- ts renamegroup "$dir/$shname.ts" $newname
- exec /mod/bin/hmt "+setfilename=$newname" "$dir/$newname.hmt"
 
+ set newname "$shname"
+ # puts "Renaming file group to $newname"
+ #  ts renamegroup "$dir/$shname.ts" $newname
+ # exec /mod/bin/hmt "+setfilename=$newname" "$dir/$newname.hmt"

 

[MymsMan]

Thanks so much for all your replies regarding this - appreciate it. Will give this a try tonight and let you know how it goes. Should I still keep auto-decrypt on and add auto-shrink once i've made -f option change?

Thanks again

The change that Raydon suggests would only affect Shrink via the webif options panels - it would not affect the auto-shrink option which uses a different code path.

To affect auto processing you would need to edit the Auto file /mod/webif/lib/bin/auto

This is a large file with several references to Stripts I think the section you need to update looks like

        if {[catch {
                foreach line [split \
                    [exec nice -n 19 /mod/bin/stripts -q $file $tmp/shrunk] \
                    "\n"] {
                        log $line 0
                }
            } msg]} {
                log "Error during shrink: $msg" 0
                system notify "$file - auto-shrink - error $msg."
                endop
                return
        }

add the f after -q e.g. -qf on the line that starts [exec nice

The problem is package updates could wipe out your updates

My, possibly flawed, understanding is that decryption is not required if you accessing the file via URL eg DLNA URL http://192.168.1.3:9000/web/media/26061.TS but decryption is required if accessing via file sharing eg "W:\The Game_20150528_2100.ts"

 

[raydon]

The change that Raydon suggests would only affect Shrink via the webif options panels - it would not affect the auto-shrink option which uses a different code path.
To affect auto processing you would need to edit the Auto file /mod/webif/lib/bin/auto

Let's not get ahead of ourselves. The aim in the first instance is purely to establish if fixing the PAT packets enables streaming to OP's Panasonic TV. Before going down the road of full automation, the prerequisite of decryption before shrinking would need to be considered, and how auto-decrypt and auto-shrink are prioritized in order to achieve this. Something like this would definitely need input from af123 who has the big picture..

 

[MymsMan]

Let's not get ahead of ourselves. The aim in the first instance is purely to establish if fixing the PAT packets enables streaming to OP's Panasonic TV. Before going down the road of full automation, the prerequisite of decryption before shrinking would need to be considered, and how auto-decrypt and auto-shrink are prioritized in order to achieve this. Something like this would definitely need input from af123 who has the big picture..

Agreed, but the OP was asking if they should turn on auto-shrink which would not achieve the desired result since it wouldn't invoke your code change

Decrypt is not required to Shrink - the option is not greyed out on the options pull down and the two auto_ options can be specified independently

 

[raydon]

Decrypt is not required to Shrink - the option is not greyed out on the options pull down and the two auto_ options can be specified independently

No, but a decrypt is required before shrinking, for the PAT packets to be fixed. All we are trying to do just now is manually process a couple of test files. I have already advised him to forget about auto-shrink until he proves that streaming actually works after fixing PAT packets, before proceeding any further.

 

[Bradley Joy]

Hi

Wow - thanks for all the replies - really appreciate it.

I edited the scripts file as helpfully suggested and have since tried to shrink 2 separate files - neither of them play on the Panasonic TV. They show up but still stay at the Please Wait screen.

Is there anything else I can try?

Thanks so much for the help.

 

[Bradley Joy]

Should I just try shrinking on its own without decrypting first perhaps? Thanks

 

[raydon]

Should I just try shrinking on its own without decrypting first perhaps? Thanks

No, the files must be decrypted first for stripts to fix the PAT packets. Were the files you shrunk flagged as decrypted before you shrunk them and did you reboot afterwards to reindex the DLNA database ? If the answer to both of these questions is yes then that's it. Nothing else can be done.

 

[Bradley Joy]

Yes to both

 

[af123]

This is probably why the stripts -f option is not made available in the web interface, because you need to guarantee that the file was decrypted first.

My original plan was to automatically fix the PAT at the same time as shrinking but some users experienced problems using trick play with files in which the PAT had been fixed. It could be a bug in the strip code around the NTS pruning of course.

(I don't like the epoch timestamp being appended either.)

If I remember correctly this was added to support certain splicing workflows - in particular where a section is cut out to keep and the the original recording moved back in order to cut out a second portion. Without modifying the filename the cropped section has the same name as the original.
Let me see if I can find a reference... - here http://hummy.tv/forum/threads/nices...ers-on-box-video-editing.709/page-2#post-9310
It may not be generally useful to be able to put both original and modified recordings into the same folder but then again...

 

[raydon]

My original plan was to automatically fix the PAT at the same time as shrinking but some users experienced problems using trick play with files in which the PAT had been fixed. It could be a bug in the strip code around the NTS pruning of course.

So what what the reason for not stripping the SDT along with the EIT ?

If I remember correctly this was added to support certain splicing workflows - in particular where a section is cut out to keep and the the original recording moved back in order to cut out a second portion. Without modifying the filename the cropped section has the same name as the original.
Let me see if I can find a reference... - here http://hummy.tv/forum/threads/nices...ers-on-box-video-editing.709/page-2#post-9310
It may not be generally useful to be able to put both original and modified recordings into the same folder but then again...

Sorry but I don't follow your reasoning here. Why should this affect a shrink operation ?. The original goes into sub folder "_original", the shrunk file stays where it is. Are you saying that any sub folder under the original one, which contains the same filenames can cause conflicts in "nicesplice" ?