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

How bad is the BBC3/4 recording problem?

As a UK DVB receiver would not expect to see a HiDef service on a DVB-T mux, maybe there is scope for some confusion somewhere?
 
prpr said:
Post a zipped copy of your tuning database and somebody may take a look. If you don't, then nobody can guess.
Click to expand...
As I expect you can guess I have not the slightest idea where to look for the the tuning database.

However, I have posted screen shots showing the manual tuning of the two T1 modulators. If that isn't enough proof for you then you are basically saying I'm lying.
prpr said:
What does CS stand for in your world anyway?
Click to expand...
Customer Services.
CF - sorry.
prpr said:
Why can't you quote actual version numbers of firnwares instead of meaningless terms like "the slow epg version".
Click to expand...

HDR_FOX_T2_1.03.12_mod_3.13.zip
I think it is latest one, with the distinguising feature of a slow epg according to the website.

I hope that answers all the questions. I'm happy to post the tuning database if someone will tell me where I find but that is to help with diagnosis not to prove I'm not lying.

I see no point in getting further embroiled in pointless arguments like I should have said T and not T1. T1 has no possiblity of ambiguity even if it is not 100% the norm.


Bob.
 

Attachments

  • WrongMuxInfo.jpg
    WrongMuxInfo.jpg
    361 KB · Views: 24
  • UHF-C22.JPG
    UHF-C22.JPG
    67.8 KB · Views: 23
  • UHF-C25.JPG
    UHF-C25.JPG
    66.9 KB · Views: 22
af123 said:
Well this seems to have wandered a bit!

I suspect that the OP was originally looking at

https://wiki.hummy.tv/wiki/Which_Version

which gives the pros and cons of the different available versions and still notes the BBC3/4 recording issue for the older underlying firmware versions.

I have no idea if this problem (zero-byte .nts files) still happens, does anyone else? There's no reason to think that it wouldn't since it required a firmware fix from Humax which is only in 1.03.xx. I run the latest version everywhere so wouldn't have seen this.


You can add a poll to this thread and let people vote, but of the devices that are registered with remote scheduling, 92.6% of them are using 1.03.xx, 6% are using 1.02.28+ and the remainder are on 1.02.20
Click to expand...
Your suspicion is correct and thank you for the rest of the info.

Bob.
 
@mightyoakbob - to get back on topic, I have no idea how prevalent the BBC3/4 HD recording issue is with older firmwares. Almost everyone here is using the 1.03.xx versions of the underlying Humax firmware.
However, at least the badnts package is available that can fix any such recordings automatically, and the sidecar package would allow you to reconstruct the sidecar files should you want trick play on them.
You might be able to live with the slower EPG by cleaning up the schedule/tuning database.
 
af123 said:
@mightyoakbob - to get back on topic, I have no idea how prevalent the BBC3/4 HD recording issue is with older firmwares. Almost everyone here is using the 1.03.xx versions of the underlying Humax firmware.
However, at least the badnts package is available that can fix any such recordings automatically, and the sidecar package would allow you to reconstruct the sidecar files should you want trick play on them.
You might be able to live with the slower EPG by cleaning up the schedule/tuning database.
Click to expand...
Thank you.
Bob.
 
Yep. Sure enough, my Technomate tunes as a T source (no sig str or Q when T2 tuning selected) but displays in the CF Tuned Multiplex Information as DVB-T2 (HD)
It did rather get its knickers in a knot over the fact that the video I/P to the mod was the T2 itself.
 
Thanks for the confirmation, two independent observations of the same unexplained effect puts a very different complexion on matters. So, exactly what does the Mux Info diagnostic use to (unsuccessfully) distinguish DVB-T from DVB-T2 if it's not the decoder setting? If it is the decoder setting as picked up from the tuning database (why would it be anything else?), why does that not agree with the actual decoder setting?

Maybe (just maybe) there is no decoder setting in the database, and the decoder switches automatically (but if that were the case, I don't see why it would be necessary to select between DVB-T and DVB-T2 when tuning manually, or automatic tuning to go through a DVB-T cycle followed by a DVB-T2 cycle). The Mux Info would then be using other assumptions to decide, which produce an incorrect result for this modulator. But it seems unlikely the Mux Info diagnostic would bother to recreate information rather than simply provide a means to display the actual tuning database content (and nothing else). All this seems so unlikely I'm not even declaring it a hypothesis.

Anyone prepared (and able) to look into this in more depth is still hampered by lack of data! Despite prpr's request, so far nobody with a DVB modulator and able to demonstrate this effect has posted the necessary data.

This topic of discussion needs to be transferred to the CF section.

Trev said:
It did rather get its knickers in a knot over the fact that the video I/P to the mod was the T2 itself.
Click to expand...
In what way? Why? The modulator should be receiving HDMI input from the HDR-FOX regardless, and the HDR-FOX should be receiving UHF input from the modulator regardless, so what negative effect did you see?
 
Last edited:
The box automatically switched to the mod's LCN on completion of tuning it. The symptoms were 'chuntering/slow flickering' of the picture (best way I can explain it without a video), picture gradually acquiring a green hue, non/very slow response to remote control. Had to hold the power button for about 5 secs before it switched to S/B and then I quickly changed channels away from the mod LCN as it was booting.

The modulator should be receiving HDMI input from the HDR-FOX regardless, and the HDR-FOX should be receiving UHF input from the modulator regardless
Click to expand...
Thus creating a feedback loop?
prpr said:
Post a zipped copy of your tuning database and somebody may take a look. If you don't, then nobody can guess.
Click to expand...
Tell me how to do it then I will.
 
Black Hole said:
Thanks for the confirmation, two independent observations of the same unexplained effect puts a very different complexion on matters.
Click to expand...
I take it you now believe me, despite me posting 3 images yesterday showing this feature the doubt remained.
Black Hole said:
Despite prpr's request, so far nobody with a DVB modulator and able to demonstrate this effect has posted the necessary data.
Click to expand...
Why be helpful and tell people how to do what you want when it's much more fun to have another pop.
Okay.
Despite me saying I would post the data but I don't know where to get it from, nobody has told me how.

Tell me how or post a link to the instructions.

Bob.
 
Trev said:
Yep. Sure enough, my Technomate tunes as a T source (no sig str or Q when T2 tuning selected) but displays in the CF Tuned Multiplex Information as DVB-T2 (HD)
It did rather get its knickers in a knot over the fact that the video I/P to the mod was the T2 itself.
Click to expand...
Thanks Trev.

Bob.
 
Black Hole said:
So, exactly what does the Mux Info diagnostic use to (unsuccessfully) distinguish DVB-T from DVB-T2 if it's not the decoder setting?
Click to expand...
Speaking from total ignorance of the Mux Info diagnostic - I offer the following observation.
If I understand it correctly the devices are multiplexing mpeg4 type streams onto a DVB-T mux. Could it be that Mux info is determining the mux type from the type of stream contained (crudely, mpeg4 or mpeg2). Therefore, if it sees mpeg4 it's DVB-T2 - even though it isn't. If that makes sense.
 
Trev said:
Thus creating a feedback loop?
Click to expand...
Not while in the process of tuning, no. While you are tuning, there is no feed-through of the video or audio - the HDMI output is just the tuning menu.

Trev said:
The symptoms were 'chuntering/slow flickering' of the picture (best way I can explain it without a video), picture gradually acquiring a green hue, non/very slow response to remote control.
Click to expand...
Yeah, you would expect weird stuff if you encode the output of the video decoder and stick that into the decoder, but I thought you meant while you were tuning.

Trev said:
Tell me how to do it then I will.
Click to expand...
There may be a way to access the relevant file via FTP or the WebIF diagnostics file browser, but you can definitely save it to USB via the hidden menu.

EEPhil said:
If I understand it correctly the devices are multiplexing mpeg4 type streams onto a DVB-T mux. Could it be that Mux info is determining the mux type from the type of stream contained (crudely, mpeg4 or mpeg2). Therefore, if it sees mpeg4 it's DVB-T2 - even though it isn't.
Click to expand...
Quite, and this seems to be the only logical explanation... but as per my previous post: why would it? The nature of the encoding of an individual transport stream within the overall mux data stream is irrelevant to the demodulation of the overall data stream itself (which is where the distinction between DVB-T and DVB-T2 lies). Also, if the distinction is so crude and indefinitive as that, there is nothing to stop it getting the wrong answer for broadcast muxes.

The demodulator needs to know whether to demodulate as DVB-T or DVB-T2, so a flag needs to be in the tuning database, and if that's the case there is no reason for Mux Info to get it wrong! However, by the maxim "whatever remains must be the truth", there has to be something wrong with this chain of deduction.

Although this issue affects very few people, and has no significant consequences other than that it is an incorrect representation, it is a very big puzzle - and the reason I was so sceptical of the first vague report (with no supporting evidence presented).
 
Last edited:
I shall take af123's reply as an indication that I'm talking rubbish! :D
(Although I'll have a good look through the information at the end of that link to see...)
 
EEPhil said:
Speaking from total ignorance of the Mux Info diagnostic - I offer the following observation.
If I understand it correctly the devices are multiplexing mpeg4 type streams onto a DVB-T mux. Could it be that Mux info is determining the mux type from the type of stream contained (crudely, mpeg4 or mpeg2). Therefore, if it sees mpeg4 it's DVB-T2 - even though it isn't. If that makes sense.
Click to expand...
Sounds a perfectly reasonable hypothesis to me.
But it would be better if the algorithm used a more accurate criteria.
Bob.
 
Bingo!
eTransMode in the table is showing 2 for real DVB-T and 6 for DVB-T2. The two debatable muxes are showing 1 in the database.
Looks like the Humax is recognising the muxes as different and in its own software correctly interpreting this as DVB-T.
I wouldn't normally quote this source, but I can't find any other explanation quickly:
https://ukfree.tv/article/1107051920/Freeview_modes_a_simplified_explanation_ said:
There are 10 modes defined for use in the UK, these are:
  • Mode 1: DVB-T 1705 (2K) carriers, 64QAM mode, FEC=2/3, 1/32 guard = 24.13Mbps
  • Mode 2: DVB-T 1705 (2K) carriers, 16QAM mode, FEC=3/4, 1/32 guard = 18.1Mbps
  • ...
  • Mode 6: DVB-T2 27841 (32KE) carriers, 256QAM mode, FEC=2/3, 1/128 guard = 40.2Mbps
  • ...
Click to expand...
 
Last edited:
You must log in or register to reply here.
Back
Top