Hdmi issue with Bravia

[ejstubbs]

Fair enough, but 4k runs on HDMI and it does say 1080 in the description.

Makes me wonder if this 4k-HD distinction is akin to 'digital' vs 'analogue' aerials. Though 4k needs higher bandwidth, so maybe a 4k device needs a more capable chipset.

In simple terms* "4K" - which usually means 3840x2160@60Hz - requires HDMI 2.0, especially if HDR is involved. Earlier versions of HDMI did support 4K resolutions, but at lower frame rates. HDMI 2.0 was released in 2013 so significantly post the release of the HDR FOX-T2. I suspect that the HDR FOX-T2's HDMI port is version 1.3, or possibly 1.4.

In simple terms (again): given the HDR FOX-T2's known 'fussiness' about its HDMI connectivity, it would not seem unreasonable to expect/hope that connecting it to a device which uses the same or a similar HDMI version might at least eliminate one way for it to decide not to play ball.

I've now ordered both of the devices available from Amazon that I mentioned previously (the audio extractor and the HDMI splitter - the latter having a 50% discount offer until 7th December, woo hoo) to try. I'll give the splitter a go first and if that does the trick then the audio extractor can go back unopened. If neither of them work then I think I will almost certainly give it up as a bad job.

(I know I said I wasn't going to get sucked in to this but the urge to try to get things working can be difficult to control...)

* Because, like almost any 'standard', especially ones which allow selective implementation, it turns out to be not very simple at all: https://en.wikipedia.org/wiki/HDMI

 

[ejstubbs]

So perhaps if you try renaming the humax .ts file to .mts or .m2ts it may be able to play it, creating an alias may also work

Interesting idea. The Humax might not be too keen, though: the .ts file is part of a four-file 'package' that makes up the actual recording as it appears in the Humax' media list. Changing the filename suffix of the video might confuse the Humax. Alternatively, I could try copying the .ts file and renaming the copy - though it would remain to be seen whether the Humax would then offer a .mts or .mt2s file via its DLNA service. All things that could be tried, anyway. Unfortunately, though, the content on the USB disc would still be inaccessible through DLNA.

 

[Black Hole]

Changing the filename suffix of the video might confuse the Humax.

ln -s <target_recording>.ts <target_recording>.m2ts
...but I don't know whether the DNLA server will index and offer the .m2ts version for streaming.

Unfortunately, though, the content on the USB disc would still be inaccessible through DLNA.

You could use SMB or NFS to set up a network share including any USB drives. A smart TV is almost certainly able to access a NAS. Any recordings would need to be decrypted of course (unlike native DLNA streaming). Another possibility is to install the mediatomb DLNA server, which you can configure how you like.

 

[MymsMan]

Interesting idea. The Humax might not be too keen, though: the .ts file is part of a four-file 'package' that makes up the actual recording as it appears in the Humax' media list. Changing the filename suffix of the video might confuse the Humax. Alternatively, I could try copying the .ts file and renaming the copy - though it would remain to be seen whether the Humax would then offer a .mts or .mt2s file via its DLNA service. All things that could be tried, anyway. Unfortunately, though, the content on the USB disc would still be inaccessible through DLNA.

If you can't persuade the native DLNA server to serve .mts files you could try installing the Mediatomb package and see if that can be configured to serve them and might also be able to serve those on your USB disk.

 

[Black Hole]

If you can't persuade the native DLNA server to serve .mts files you could try installing the Mediatomb package and see if that can be configured to serve them and might also be able to serve those on your USB disk.

Oops! I was editing that into my post when you posted.

 

[ejstubbs]

If you can't persuade the native DLNA server to serve .mts files you could try installing the Mediatomb package and see if that can be configured to serve them and might also be able to serve those on your USB disk.

Thanks for the suggestion. Mediatomb will serve the content on the USB disc, but it doesn't list the test files renamed from .ts to .m2ts that I put in My Video on the box itself. Roku Media Player refuses to play the .ts files, but at least it says so rather than just sitting there saying "Please wait" for ever like the TV does.

As I suspected might be the case, the Humax throws an error if I just rename the .ts file within a four file content 'package'.

I'll give it another try just now with .mts rather than .m2ts. as the video file suffix.

UPDATE: Hmm. Well, .mts worked no better than .m2ts, so that seems to be a bust. I've no idea how to 'persuade' Mediatomb to serve anything other than .ts files. Oddly, though a few of the .ts files on the USB disc did actually play fine on both the TV and the Roku Media Player. I may investigate what's different about those files, if I can be bothered - though this whole exercise with using the Humax as a media server will be moot if either of the HMDI devices I have on order will allow the Humax to talk directly to the TV in HD.

 

[/df]

I'd try replicating the first XML line in /mod/mediatomb/config/config.xml in one of the two following ways (the first is right, but maybe mediatomb doesn't understand the video/mp2t MIME type):

        <map from="ts" to="video/mpeg"/>
        <map from="m2ts" to="video/mp2t"/>
        <map from="m2ts" to="video/mpeg"/>

Obviously these are going to be decrypted files since only the HDR's built-in DLNA server can decrypt on the fly (well, maybe another server could proxy it).

I got a version of MiniDLNA running on one of my HD Fox-T2s as a simpler solution than MT, but haven't had the inclination to package it.

 

[Black Hole]

As I suspected might be the case, the Humax throws an error if I just rename the .ts file within a four file content 'package'.

That's why you were offered the soft-link command to create an alias rather than a renaming.

 

[ejstubbs]

I'd try replicating the first XML line in /mod/mediatomb/config/config.xml in one of the two following ways

I'd happily try that, but the file editor in the custom firmware (on the "Diagnostics" page) doesn't want to play with xml for some reason (fundamentally, it's just text, right?)

That's why you were offered the soft-link command to create an alias rather than a renaming.

Ah, OK, I didn't realise that's what it was (Unix command line stuff is far from my forte). Renaming is fine, though, in that I can just rename the file back to the .ts suffix and it works again (tested and proven to work).

 

[Black Hole]

I'd happily try that, but the file editor in the custom firmware (on the "Diagnostics" page) doesn't want to play with xml for some reason (fundamentally, it's just text, right?)

I just installed mediatomb to try it out, and you're right. It's not a question of the file extension either, Linux recognises file contents somehow (not sure whether there's a property, an identification string, or it does pattern recognition), and basically the WebIF Diagnostics file editor has too limited a range of declared compatible file types. (Yes, I even tried renaming the file to config.txt and it still failed.)

What I would do in this situation is FTP the file out, edit it externally, and FTP the modified file back in. What also works is to install nano and then (in Webshell):

cd mod/mediatomb/config
nano config.xml

 

[MymsMan]

I'd happily try that, but the file editor in the custom firmware (on the "Diagnostics" page) doesn't want to play with xml for some reason (fundamentally, it's just text, right?)

Yes it is just text so unsure why it wouldn't work.

If you have Samba or NTS shares set up you could edit the file on your PC (Make sure the editor preserves unix style LF line break rather than windows CR/LF) I normally use Atom

Or there are text editor packages that can run on the Humax - Joe and nano are it the advanced section of the Package catalogue. (don't bother with vim unless into masochism)

How were you renaming the files - If using the webif it will rename the entire set of files and you would end up with something like recording.m2ts.ts which is not what is needed

(@Black Hole posted faster so some duplication of advice)

 

[ejstubbs]

What I would do in this situation is FTP the file out

The FTP server on the Humax doesn't seem to give access to anything other than the My Music, My Photos and My Video folders on the box itself, and the USB drives connected to it (some of which are actually SMB shares on the NAS).

How were you renaming the files

I used FTP to rename the .ts file specifically.

I have tried copying one of the .ts files that won't play on the TV when served by MediaTomb on to the NAS. I also created a copy with the .mts suffix and another with the .m2ts suffix. With those files served from the NAS, the Humax can play all three, the TV and the Roku can't play any of them. Based on that result, I don't think there's much value in trying to persuade Mediatomb to serve the files.

In other news: neither of the two HDMI devices that I got from Amazon (the audio extractor and the HDMI splitter) solved the green screen problem. Well, actually - and frustratingly - I did get clear 1080p from the Humax on the new TV for a few minutes using the audio extractor. But then I changed something (can't remember what, might just have been changing the vformat on the Humax) and it's not worked since, whatever I try in terms of startup order and twiddling with possible settings The HDMI splitter which one reviewer on Amazon said did work, simply didn't. My next test, out of pure interest/inquisitiveness as much as anything, will be to see if the Humax can connect to the old TV - which it did very happily via a direct HDMI connection - through either of those devices. Then I'll probably be taking advantage of Amazon's free returns policy on both devices.

I've actually just watched a bit of Countryfile that the Humax recorded from BBC One Scotland HD last night. Via my jury-rigged AV connection (that I mentioned here) it actually looked OK. Not 4K quality, obviously, but for video that will have been delivered to the TV as SD, it seemed to upscale on to a 55" screen pretty well. I'm now just waiting for the "proper" AV to 3.5mm adaptor to arrive and I may actually decide just to live with that.

 

[prpr]

Yes it is just text so unsure why it wouldn't work.

No it isn't "just" text. It's a special sort of text.
It fails because there's a Mime test for "text/*" and the XML file returns as "application/xml".
It would help if people said what the error message was rather than "doesn't work" or similar.
I've fixed it in my working copy, so there'll be a webif update at some point.

(This thread seems well into customised territory now, so it appears to be in the wrong forum section.)

 

[Black Hole]

The FTP server on the Humax doesn't seem to give access to anything other than the My Music, My Photos and My Video

That's because you should be using the betaftpd package, with the native FTP server turned off. This is basic.

As noted above, beware Linux vs. Windows line endings (Notepad++ is my tool of choice on WIndows, and it preserves the current line end style).

However, this now seems to be a moot point...

I have tried copying one of the .ts files that won't play on the TV when served by MediaTomb on to the NAS. I also created a copy with the .mts suffix and another with the .m2ts suffix. With those files served from the NAS, the Humax can play all three, the TV and the Roku can't play any of them. Based on that result, I don't think there's much value in trying to persuade Mediatomb to serve the files.

Fair enough, good test.

I did get clear 1080p from the Humax on the new TV for a few minutes using the audio extractor. But then I changed something (can't remember what, might just have been changing the vformat on the Humax) and it's not worked since

So you just change settings with gay abandon and no real idea what you've done? There's no helping you.

I've actually just watched a bit of Countryfile that the Humax recorded from BBC One Scotland HD last night. Via my jury-rigged AV connection (that I mentioned here) it actually looked OK. Not 4K quality, obviously, but for video that will have been delivered to the TV as SD, it seemed to upscale on to a 55" screen pretty well. I'm now just waiting for the "proper" AV to 3.5mm adaptor to arrive and I may actually decide just to live with that.

There's nothing wrong with an analogue connection for StDef quality, the TV will do the heavy lifting of upscaling to its native resolution regardless of the source. I recommend Menu >> Settings >> Preferences >> Video >> TV SCART = RGB (rather than CVBS), and then you can use SCART to SCART or SCART to RGBLR.

 

[bottletop]

...... I recommend Menu >> Settings >> Preferences >> Video >> TV SCART = RGB (rather than CVBS), and then you can use SCART to SCART or SCART to RGBLR.

That won't work.
You'll need to leave it on CVBS rather than RGB if you're using the Humax to output a standard AV (i.e. composite) signal. (SCART composite video or RGB video uses different pins.)
The other reason is that @ejstubbs mentioned new TV doesn't have SCART! Presumably it only has multiple HDMI and that 3.5mm AV socket.

 

[bottletop]

..... I did actually take the Humax to the shop I bought the TV from and they tried it in all the other TVs in the showroom. It only worked on one of them, a 50" Panasonic from a few technological generations back - and that was out of stock until the end of December. Other solutions are being considered. Push comes to shove we'll get a new PVR and relegate the Humax to recording stuff for ripping on to the NAS. I can't keep faffing around forever trying to get the Humax to work properly: SWMBO needs a TV & PVR or my life won't be worth living...

You tested the Humax against, roughly, how many TVs?
Also of the ones that failed, were they different makes or all Panasonic?
Did the ones that failed all produce the same (lime) green screen - did any of them produce a different screen with 'Unsupported Resolution' type message.
Not sure if you've seen this already
https://hummy.tv/forum/threads/inve...een-screen-after-a-few-seconds-problem.10218/

 

[ejstubbs]

That's because you should be using the betaftpd package, with the native FTP server turned off. This is basic.

That is precisely how I have it set up. However, what I now realise I've been doing is logging in as "humaxftp" rather than "root". (Note to self: RTFW.)

So you just change settings with gay abandon and no real idea what you've done? There's no helping you.

Er, not exactly. I know what the setting was when it worked: bog standard out-of-the-box HDMI settings on the TV, vformat set to 1080p on the Humax. Basically, I connected it all up via the audio extractor box, turned everything on and it worked. What I can't remember is what I did that stopped it working, but certainly going back to those original settings and powering up from scratch again didn't start it working again. After that I went through every combination of potentially relevant settings, including different power-on sequences, and different HDMI cables & ports on the TV, but it never worked again.

I've just realised that I didnt try any of the later versions of the bootloader on the Humax. That might possibly be worth a go...

I recommend Menu >> Settings >> Preferences >> Video >> TV SCART = RGB (rather than CVBS), and then you can use SCART to SCART or SCART to RGBLR.

As bottletop pointed out, the new TV doesn't have any SCART sockets (thank goodness) and its AV socket uses composite video not RGB. It's working surprisingly well with the composite video in terms of picture quality, though the standard tip-ring-sleeve 3.5mm stereo audio plug that I'm currently using only provides one audio channel. Provided I connect the AV wires the right way that puts one audio channel on the tip, composite video on the ring and ground on the sleeve. Having ground on the sleeve actually puts it where the socket on the TV expects it to be, and grounding the contact for the other video channel doesn't seen to upset it. But it would be nice to have stereo sound and I'm hoping that the adaptor I've ordered, which purports to have the correct pinouts on a plug of the right length, will deliver that.

 

[ejstubbs]

You tested the Humax against, roughly, how many TVs?
Also of the ones that failed, were they different makes or all Panasonic?
Did the ones that failed all produce the same (lime) green screen - did any of them produce a different screen with 'Unsupported Resolution' type message.

Let me think...there were two Panasonics, one Samsung, one Sony and another one I can't recall the make of, but it was not any of the aforementioned. LG maybe? All, except one of the Panasonics, produced the green screen.

Not sure if you've seen this already
https://hummy.tv/forum/threads/inve...een-screen-after-a-few-seconds-problem.10218/

Yes. My symptoms are exactly as described in there. The link to the howtogeek article is I think the same one that Black Hole linked earlier in this thread. It certainly recommends the same splitter box (which is too pricey for me to justify buying just to try - and in fact would be even if it does turn out to work).

 

[ejstubbs]

Update: the AV cable with the "mini" 3.5mm plug and ground on the second ring works just fine once you get the cables plugged together the right way round (which is definitely not 1:1 with the colour-coding of the sockets on the Humax: yellow, which is the composite video plug on the Humax, has to go to the first ring on the 3.5mm plug, which is connected to the white inline plug on the adaptor - once you have that sorted, it's simple to get the stereo audio the right way round). There seem to be innumerable sort-of standards for these things, so once again it's a question of buy one, try it, and if it doesn't work then return it and have another go. Such a waste of time and effort for something that should be trivially simple to standardise properly.

Given that I've now at least got the Humax connected to the new TV with both stereo sound, and vision - albeit SD, I'm going to give up trying to get it working with HDMI as a bad job, and return the two devices I bought from Amazon to try to fix the green screen issue (one of which was described in one review as definitely working - but didn't for me, so even reading the reviews can be misleading).

As for streaming recordings from the Humax, it seems that neither the TV nor the Roku can handle decrypted SD programmes, whatever suffix you give them, but some/most decrypted HD programmes stream OK to both. That's actually more or less fine, since I can watch SD recordings via the AV connection without feeling that I'm losing out on video quality, and some/most HD ones by decrypting them and streaming them as HD.

At this point the next hurdle is going to be explaining how to use all this to SWMBO....

(As an aside: I noticed the other day that the new TV is reporting the HD Freeview channels as being 1080i. ISTR that the BBC ones at least were 1080P back when I first got the Humax. Did they get 'downgraded' at some point - maybe to free up some bandwidth on the BBC B mux for another channel or two?)

 

[Luke]

I noticed the other day that the new TV is reporting the HD Freeview channels as being 1080i. ISTR that the BBC ones at least were 1080P back when I first got the Humax. Did they get 'downgraded' at some point - maybe to free up some bandwidth on the BBC B mux for another channel or two?

BBC - Research and Development: Software Upgrade for BBC HD on Freeview HD

R&D do much of the development for the television distribution systems of the BBC. For the BBC HD service as carried on Freeview HD there have been some recent changes-...

www.bbc.co.uk