• 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.

DLNA to Smart TVs

Mad Ian said:
Yes they work. The output is noticeably pixelated, but bearable. An enhancement to work on
once HiDef is sorted. The main issue I had with losing the sidecars was the loss the synopsis and file duration.
Click to expand...

That's an indication that the TS and NTS are out of sync. One of the hardest parts of getting shrink/stripts to work (and Drutt had similar problems with nicesplice) was to preserve FF/RW behaviour. Also you will find that your forward and backwards skips are no longer always the correct number of seconds after processing.

I will have a look at the files that ffmpeg creates. It may be possible to get stripts to create similar files while maintaining the NTS sync at which point it will produce streamable files as a side-effect!

There are also four types of recordings to consider with this - standard and high definition for each of a normal and time-shifted recording.. fun and games. Oh yes, radio recordings too : )

(Thanks for splitting Brian)
 
af123 said:
Also you will find that your forward and backwards skips are no longer always the correct number of seconds after processing.
Click to expand...

That might go someway to explain why after skipping through a film this afternoon, we ended up with the timebar showing 36 of the 139 minutes had elapsed even though we were more than half-way through.
 
Great News!

I amended your script slightly, I added a few echo lines to test for debug, and found only the issue with the speech marks around the mkdir commands, I amended in line with its antecestor to use the mkdir -p command.

I've just pushed through a few files, one which had been decrypted, shrunk and edited with editmonitor and 2 others which had just been decrypted - the result is they play on my Sony Bravia CX523 (Software Version pkg4.008EUA-0104) when streamed via mediatomb, fast forward worked too.

I've yet to try them through the standard DLNA server - waiting for it to reindex them!

I think you're really onto something if after further testing we can get it to autodecrypt and demux :-), it's shame we have to decrypt at all as it's not really necessary if inbuilt DLNA would work!
 
There might be another way to achieve this while retaining full Humax capabilities. adrianf26 (usually found over on AVForums) has been working on the same thing and has found out what it is about the Humax .ts files that upsets smart TVs.

It should be possible to update the stripts utility to 'fix' the Humax .ts files in-place. I'm going to work on that and if it's achievable then it can easily be set up to automatically fix all recordings in the background. The downside is that it does require the file to be decrypted first which increases the overhead.
 
@af123 @Mad Ian

This sounds really promising, please let me know if I can help even if it's just by being a tester with my hdr fox t2.

Mad Iain I did appear to lose subtitles in my recording but I don't know if that's the decrypt or the stripts, I'm not particularly bothered at the loss but just thought I should point it out :-)
 
damianiw said:
Mad Iain I did appear to lose subtitles in my recording but I don't know if that's the decrypt or the stripts, I'm not particularly bothered at the loss but just thought I should point it out :)
Click to expand...

That will be the ffmpeg conversion - the stripts method that I'm hoping to get working will preserve those (and audio description)
 
af123 said:
It should be possible to update the stripts utility to 'fix' the Humax .ts files in-place.
Click to expand...
That sounds good especially as I've got been able to find a way of getting ffmpeg to do anything with HiDef files.

I've starting looking at other packages such as mencoder and vlc but these are all new to me (as is linux) so it's a steep learning curve.
Another downside, possibly another side-effect of the out of sync .ts and .nts files is that bookmarks are very imprecise. Cutting after processing with ffmpeg is not viable for trimming recordings and cutting out ads.
 
I've just uploaded a new version of stripts which works for me. I'd appreciate any testing you can do before I work out how/if to integrate this into the web interface and automatic background processing.

You can run stripts with the -F option to fix the file like this (-v is for verbose):

Code: 
humax# stripts -Fv Couriers_Chuggington\:_Badge_Quest test

It automatically repairs the NTS file on the way, converts time-shift-recordings to normal ones and should deal with HiDef too! If you use -f (lower case) instead of -F then it will also remove redundant EIT packets from the recording saving up to 20% of space.

You still need to decrypt the file first.
You still need to use mediatomb to serve the patched file (the built-in Humax DLNA server doesn't work properly and I don't know why... yet).

(Thanks for adrianf26 for the technique that this utility uses to patch up the .ts files!)
 
Brilliant :) It Works!

Tested on my Sony Bravia CX523 Smart TV, decrypted first via WebIF a HD and SD recording and then ran the stripts function as per your post and then added the outputs into MediaTombs Library.

Sony TV does allow fast forward and it's not pixelated, doesnt allow me to select subtitles but I think thats a tv thing, it shows media info as .TS but not much else.

The files played subtitles on vlc player.
 
Have processed my SD test file and that too works on the Panasonic.
There was some pixelation using FF on the Humax - but much better than using ffmpeg.
Now to try on an HD file and let loose on a wider range of SD recordings.
 
A bit more testing...

I got a segmentation fault at 43% of an HD recording (5.5GB original) using both the HD and the HDR to process the file, and when saving the output both to the HDR itself and directly to a NAS.

The bookmarking problem that I'd encountered with the output from the ffmpeg script was evident when viewing a stripts-processed SD recording. I understand the positioning of the bookmark can be a bit imprecise, but the bookmark was placed several seconds before the position supposedly bookmarked.

Similar pixelation to that reported before when using FF/RW on the Humax; in fact the pixelation was more pronounced on this second SD file (live action film, first test was a kids cartoon).
 
Thanks for the testing. That segmentation fault is going to be interesting to find. I can provide a bigger debug version of the utility for you to try and run under gdb if you're up for it. That should narrow down where the problem is.

I'm surprised at the pixelation you're seeing, I thought I had got that sorted in the previous version. Are you just patching up for DLNA or are you also stripping redundant EIT frames (-F or -f)?

I'm similarly surprised at the bookmark problem and will do some more testing at my end. The bookmarks are defined as time offsets rather than byte positions so they should continue to work after stripping.
 
af123 said:
Are you just patching up for DLNA or are you also stripping redundant EIT frames (-F or -f)?
Click to expand...
I ran it with both -F and -f switches to create two output files, but hadn't run plain.

af123 said:
That segmentation fault is going to be interesting to find. I can provide a bigger debug version of the utility for you to try and run under gdb if you're up for it. That should narrow down where the problem is.
Click to expand...
I've just run the utility without any switches on the same HD file just to rule out anything with the file. There was no segmentation fault and the output file works on the Humax with smooth FF.

The output doesn't run on the TV from Mediatomb. Presumably the PAT packets contain data for the other channels in the same mux as the recording? I see this information is still present when a file is created without any switches, but is removed with -f and -F.

I'm afraid I haven't got any experience of using gdb; happy to see what I can do with it though.
 
Excellent thanks. So the problem is introduced solely when the PAT frames are patched up... I'll do some more digging and see if I can work out what is going on before we go down the gdb route.

Yes, the PAT contains PMT PID mappings for the other channels on the mux but the PMT frames themselves are not present. The NDT frames also contain information relating to the other services but I'm not currently altering that (it doesn't seem to be necessary).
 
1.1.2 just tidies up some command line options.

I haven't had a chance to look at the problem with PAT frames yet. Hopefully next week!
 
To resurrect this thread, we can manually demux an individual file by script to then view by DLNA on a Sony tv but it is not yet automated like HD decrypting with web-if? Is this still the situation?
 
You must log in or register to reply here.
Back
Top