DLNA to Smart TVs

[Mad Ian]

Newly signed up member who’s been lurking for many months reading the various threads and innovations.

Got to say a massive well done to all that have contributed to making my combination of HDR and HD so much more than what they were straight from their boxes - most of you seem to be active on this thread, so thank you!

I’ve been running my unencrypted recordings through ffmpeg using an adapted version of Drutt’s monitoring script to check a *demux folder that I created in the *edit folder.

This doesn’t do anything particularly clever - it simply uses ffmpeg to copy the video and audio streams and create a new .ts file that has a lot of superfluous data removed, such as the information about the other channels on the same mux as the recording. I guess the EPG data goes too - I’ve not looked.

The resulting .ts files only have one video and one audio stream and these files can be played by the embedded DLNA client on my Panasonic TV as well as on my D-Link media player which had become redundant once I started using the HDR to play the home videos housed on the PC but which I’ve now pressed back into use.

The main issue with this approach is that I lose the use of the control features such as skip forward/backward and resume play when using the HDR or HD which are still the main playback devices. I’ve not been able to edit the sidecar files to correctly work with the modified .ts files.

I’ve looked at the output of stripts and whilst it creates the full set of files for the HDR and HD, the .ts files can’t be played by the DLNA client on the Panny.

Is there any way that stripts can be adapted to perform both functions, i.e. functioning sidecar files and fully cleansed .ts files that can be played by fussy DLNA clients?

 

[af123]

Is there any way that stripts can be adapted to perform both functions, i.e. functioning sidecar files and fully cleansed .ts files that can be played by fussy DLNA clients?

Can you post the ffmpeg command line that you're using? It's possible that something could be done and it would be good to support native playback on smart TVs.

 

[Black Hole]

There's always AV2HDR of course.

 

[Drutt]

Newly signed up member who’s been lurking for many months reading the various threads and innovations.

Welcome - good to see someone else who is experimenting with this box of tricks

I’ve looked at the output of stripts and whilst it creates the full set of files for the HDR and HD, the .ts files can’t be played by the DLNA client on the Panny.

Presumably the unstripped file doesn't play either right?

Can you post the ffmpeg command line that you're using? It's possible that something could be done and it would be good to support native playback on smart TVs.

Is Raydon's AV2HDR-T2 able to rebuild the nts? I've not had a chance to play with it yet.

Otherwise I'm wondering if we could rebuild the .nts file by simply searching for matching data to that pointed to in the source file.

 

[af123]

Otherwise I'm wondering if we could rebuild the .nts file by simply searching for matching data to that pointed to in the source file.

That should be possible for an unencrypted .ts file.

 

[Mad Ian]

Can you post the ffmpeg command line that you're using? It's possible that something could be done and it would be good to support native playback on smart TVs.

The command line I used before adapting the script was "ffmpeg -i input.ts -vcodec copy -acodec copy -copyts output.ts"

Welcome - good to see someone else who is experimenting with this box of tricks

Presumably the unstripped file doesn't play either right?

Is Raydon's AV2HDR-T2 able to rebuild the nts? I've not had a chance to play with it yet.

Otherwise I'm wondering if we could rebuild the .nts file by simply searching for matching data to that pointed to in the source file.

That's right Drutt, unstripped files do not play on either device.

I'd not thought to use AV2HDR-T2 on any of the files I've created. However I can report that the files that I've previously created using AV2DR-T2 for some of the mpeg video files I've got on the PC do not work via DLNA directly on the Panasonic.

 

[xyz321]

On a very basic level the Humax packet size is 192 bytes but the output from ffmpeg using the command options above gives a 188 byte packet size. Try adding the option '-mpegts_m2ts_mode 1' - it should at least rule this out as a cause of the problem.

 

[Mad Ian]

On a very basic level the Humax packet size is 192 bytes but the output from ffmpeg using the command options above gives a 188 byte packet size. Try adding the option '-mpegts_m2ts_mode 1' - it should at least rule this out as a cause of the problem.

There's certainly something in this and using mode 1 gives working sidecars. But it's not the all-encompassing solution.

I've created test files using the different m2ts modes (-1, 0, 1) and tested them with and without an association to the original sidecar files.

The HDR does indeed play mode 1 files with sidecars. Unfortunately the Panasonic doesn't (with or without the sidecars). It did seem that there was some very slight picture noise compared to the original source - might this be a side-effect of changing the packet size?

With mode -1 and 0, the HDR attempts to play the file but the resulting picture is simply set of random pixels and no sound.

The HDR will though happily play all three modes when no sidecars exist.

The Panasonic will play mode -1 and 0 (under both sidecar conditions), but with mode 1 the result is a frozen picture (under both conditions).

When the HDR is network mounted on the HD, the latter will only play the mode 1 files when the sidecars are present. No other combination works on the network mount (the HD reports that files are unplayable).

However the HD accepts all three m2ts modes, with and without sidecars, when used as a DLNA client.

There's clearly an interaction between the files which the HD/HDR both rely upon as part of native playback, but I'm afraid that's beyond my current understanding.

 

[Black Hole]

I don't think the sidecar files come into it when accessed via DLNA, nor that anything other than a Humax would know what to do with them. They certainly seem to confuse the Humax if they don't properly tie up with the .ts.

 

[Mad Ian]

I have now got a working improvement using ffmeg but it's not in a scripted form.

Having tested what the clients are capable of, I thought to turn attention to the server side of things.

I've found out that the D-link too wouldn't accept the output from the built in DLNA server in the HDR for mode 1 files. However my Lacie NAS which has a cut-down Twonky server did serve the D-link media player with the mode 1 files (but wouldn't serve the Panasonic).

So I installed Mediatomb on my HD box thinking that it might be necessary to tweak the configuration, but found that it served the mode 1 files to the Panasonic from a clean install.

Shrunk files using stripts are not served. This retains the information relating to the other services on the mux, so my conclusion is that the DLNA client in the Panasonic expects the first service it encounters to have a the data streams and locks up waiting for one rather than trying another service.

The command line I've used is:

ffmpeg -i <<input.ts>> -c copy -copyts -mpegts_m2ts_mode 1 -mpegts_service_id <<channel_id>> <<output.ts>>

For the command line to work within a script, it will need the service id to be passed to it. I've done this manually using hmt for the test file.

Is there a way of getting either hmt (or ffprobe for that matter) to pass the service id directly into ffmpeg in a script?

 

[sooty83]

Just to muddy the waters, my Toshiba TV will not play any of the recorded .ts files via the Humax's built-in DLNA server. However, the same .ts files, decrypted but otherwise unmodified, copied to my Mac and served over the net using MediaTomb will play perfectly fine on the TV. This suggests that, at least with some TVs, the incompatibility is with Humax's DLNA server and not with the content itself.

 

[Mad Ian]

Just to muddy the waters, my Toshiba TV will not play any of the recorded .ts files via the Humax's built-in DLNA server. However, the same .ts files, decrypted but otherwise unmodified, copied to my Mac and served over the net using MediaTomb will play perfectly fine on the TV. This suggests that, at least with some TVs, the incompatibility is with Humax's DLNA server and not with the content itself.

I would agree, the Humax DLNA server seems to be sending things that the clients in the TVs do not like. Is the MediaTomb you are using installed on the HDR or on the Mac? I wonder if there's anything in that. I tried a test using the conditions you described, using Mediatomb to reference my NAS but had no joy serving to the Panasonic.

However, having done some more Linux research I've now got a working script that's been busy these past couple of days processing the archive copies of the files I'd originally processed.

What's the normal form for sending this sort of thing so that others can take a look and try it out?

I've never coded Linux scripts before now - most of my experience is in VBS /VBA on Windows - so wouldn't want to just upload the script in clear text in case there's a bug or two.

Having said that so far I've re-processed 30-odd films/TV programmes and haven't found one yet that doesn't work on the HDR with full navigation control and via Mediatomb on the TV.

Many thanks xyz321, the addition of the mode 1 option made all the difference.

 

[damianiw]

Just an update. The latest version of stripts has been on the repository for a few days and it seems to work well with both standard and high definition recordings, including time-shifted-recordings (rewind then press record on the HDR) which are indexed in a slightly different way.
It should be good to use generally now although please exercise caution and don't delete any recordings until after you have tested it yourself.
I recommend installing undelete if you are going to enable automatic stripping (or any of the automatic functions) on any folders since that will automatically save the original version of each recording in the dustbin for a few days.

Note that you should not install undelete if you also have seriesfiler installed due to a known conflict between the two which can cause recordings to be lost.

Hi

Sorry I'm being a bit dumb trying to understand this as I'd like to be able to serve from the Humax HDR Fox T 2 to my DLNA enabled Sony tv, I'm reading 2 things bit a bit confused if I need one or both:

1) you installed mediatomb and found it served to your Panasonic tv
2) you've made a stripts package, does this automatically process when i shrink through webif ? do you still need mediatomb ?

 

[sooty83]

I would agree, the Humax DLNA server seems to be sending things that the clients in the TVs do not like. Is the MediaTomb you are using installed on the HDR or on the Mac? I wonder if there's anything in that. I tried a test using the conditions you described, using Mediatomb to reference my NAS but had no joy serving to the Panasonic.

I have MediaTomb from the MacPorts distribution running on the Mac. Some TVs, notably Samsungs, require extra DLNA headers from the server. Google transfermode.dlna.org and contentfeatures.dlna.org. Don't know what Panasonic TVs require. There is one type of file that my Toshiba TV will play directly off the Humax built-in server and that is mp4s captured from iplayer.

 

[Mad Ian]

Hi

Sorry I'm being a bit dumb trying to understand this as I'd like to be able to serve from the Humax HDR Fox T 2 to my DLNA enabled Sony tv, I'm reading 2 things bit a bit confused if I need one or both:

1) you installed mediatomb and found it served to your Panasonic tv
2) you've made a stripts package, does this automatically process when i shrink through webif ? do you still need mediatomb ?

Hi; we probably need this thread split - sorry, too new to this game so don't know how to do that.

When I first read about stripts it seemed to offer similar functionality to something I'd been working on myself. My initial thought was that an adaptation of stripts could get us something that Smart TVs can use.

What I'd had originally done was to create a .ts files that the TV would happily pull from the HDR using the stock DLNA server. But I couldn't get the HDR to work natively with sidecars so I'd lost synopsis, navigation control etc. and the files said they we 32000+ minutes long. Not useful when using the HDR itself.

The script I'm now using hasn't been published or packaged yet. It's not really ready for beta release, more peer review, as it can only handle StdDef files. I've read that there is an incompatibility between ffmpeg and the Humax when it comes to HiDef which is why it falls over trying to do anything in HiDef.

If anyone can point me in a direction to be able to trap this then I'd be grateful. The only thing I've thought of which will be in my working knowledge of Linux would be to test against known HiDef channel numbers. But there will be a better way I am sure.

The files it creates work directly on the HDR in the normal way and with full functionality, and when served via Mediatomb can be pulled from the TV's DNLA client.

The files that the script creates are slightly bigger than those from stripts but smaller than the original. I've not looked into why; the motivation has been to be able to use the TV's DLNA client, rather than reduce file size.

As I say, the script hasn't been packaged up or integrated into WebIF, but I'm happy to post it to you privately if you wish. It would be good to know if the approach has success across the range of Smart TVs out there.

 

[damianiw]

Sent you a pm, agree apologies for muddying this post

 

[af123]

Yes, please can we have this thread split : )

Having said that, I'd be interested in what you have so far!

If anyone can point me in a direction to be able to trap this then I'd be grateful. The only thing I've thought of which will be in my working knowledge of Linux would be to test against known HiDef channel numbers. But there will be a better way I am sure.

You can use the hmt utility to find out information about the recording. You also have to be careful with time-shifted recordings (ones made by rewinding the live buffer the pressing record on the HDR model) as they're indexed differently in the NTS - you might find that they pose a problem for your script.

humax# if hmt /mnt/hd2/My\ Video/Diamond\ Jubilee/The\ Diamond\ Jubilee\ Carriage____20120605_1347-1339973232 | grep -q 'Format:HD'; then
    echo "This is HD"
else
    echo "This is SD"
fi

This is HD

 

[af123]

The files it creates work directly on the HDR in the normal way and with full functionality, and when served via Mediatomb can be pulled from the TV's DNLA client.

Have you tried high speed Fast Forward and Rewind with the final files?

 

[Brian]

Yes, please can we have this thread split : )

How would you like the thread splitting?

 

[Mad Ian]

You can use the hmt utility to find out information about the recording. You also have to be careful with time-shifted recordings (ones made by rewinding the live buffer the pressing record on the HDR model) as they're indexed differently in the NTS - you might find that they pose a problem for your script.

Thanks. I'll put this in and see what I can do with it. I've not tried anything with time-shifted recordings. I'll post the script privately for you to look at and try.

Have you tried high speed Fast Forward and Rewind with the final files?

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.

How would you like the thread splitting?

I guess my first post and the replies to it ought to be in something new like "DLNA to Smart TVs" and then the other postings relating directly to stripts can be left in this thread. Is anything like that possible? Alternatively we could start a new thread and point people back to this one if they're interested in the history?