• The forum software that supports hummy.tv has been upgraded to XenForo 2.1!

    This upgrade brings a number of improvements including the ability to bookmark posts to come back to later. Please bear with us as we continue to tweak things and open a new thread for any questions, issues or suggestions in Site/Forum Issues.

How bad is the BBC3/4 recording problem?

OP
M

mightyoakbob

Member
I think af123 is saying the change is in webif 1.4.4-8, as this is a beta package you must allow access to beta packages if you haven't already done this by installing opkg-beta package
View attachment 4057
Thanks for the help.
Unfortunately that package isn't offered to me. I've never seen a beta package before so I suspect it needs to be switched on somewhere but having just spent a half hour looking I've no idea where.
Thanks anyway.

Bob.
 

peterworks

Ye Olde Bowler
installing opkg-beta package
Edit: Sorry a bit vague.

Try:
Go to Settings>Advanced Settings and set 'Show development and advanced packages?' to Yes
Go to Package Management and set 'Advanced packages are being shown' to Show
Then, under 'Available', add opkg-beta
You should then see all the available beta packages
 
Last edited:
OP
M

mightyoakbob

Member
Edit: Sorry a bit vague.

Try:
Go to Settings>Advanced Settings and set 'Show development and advanced packages?' to Yes
Go to Package Management and set 'Advanced packages are being shown' to Show
Then, under 'Available', add opkg-beta
You should then see all the available beta packages
Thanks.
Got there eventually.
Looks good to me. Impressed.

Thanks.
Bob.
 

Attachments

Black Hole

May contain traces of nut
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:
I am mystified why the HDR-FOX demodulator needs to be told to look for a DVB-T or DVB-T2 signal, but can auto-detect the various modes within the general classification "DVB-T" (and presumably "DVB-T2" also). Neither can I see any fundamental difference between the modulation schemes that come under "DVB-T" and "DVB-T2", other than the arbitrary reason that the DVB-T2 modulation schemes came along after DVB-T was commercialised. Could it be as trivial as a requirement imposed on the industry: "Thou shalt scan for DVB-T and DVB-T2 separately", for no technical reason at all?
 

prpr

Well-Known Member
It appears the information is contained in the DTG D-Book
Having done a bit more research...
Modes 3, 7 and 8 are only in use for broadcast DVB-T now, modes 1 and 2 having been obsoleted since 2k/8k switchover.
Modes 6 and 11 are apparently in use for DVB-T2 (the latter only in NI, presumably for NI-Mux) and mode 10 is currently unused.
It would be nice to see someone's up to date database from the province.

The Humax database fields cannot be a direct copy of these modes, as it uses 2 for SD.
 

prpr

Well-Known Member
I am mystified why the HDR-FOX demodulator needs to be told to look for a DVB-T or DVB-T2 signal, but can auto-detect the various modes within the general classification "DVB-T" (and presumably "DVB-T2" also). Neither can I see any fundamental difference between the modulation schemes that come under "DVB-T" and "DVB-T2"
Presumably because the modulation and error correction is completely different.
DVB-T uses Reed Solomon/Viterbi and DVB-T2 uses BCH/LDPC.
 

Black Hole

May contain traces of nut
Either I'm blind, or that particular nugget was not in the information previously posted. (I'm not sure that counts as "modulation" - ie 16Q/64Q/256Q - but we'll let that pass.)
 

Black Hole

May contain traces of nut
Seems like this is the obvious fix then:
I'm not pretending any significant knowledge of Jim, but isn't this a case for a case statement, structured to include all possibilities?
Code:
       puts "<td>$mux</td>"
       case $eTransMode in {
               {4 5 6 9 10 11}     {puts "<td class=blood>DVB-T2 (HD)</td>"}
               default             {puts "<td>DVB-T (SD)</td>"}
       }
 

prpr

Well-Known Member
I'm not pretending any significant knowledge of Jim, but isn't this a case for a case statement, structured to include all possibilities?
Quite possibly, but we don't know what the values might be until we see them, as mentioned previously.
In any case, eSystem seems a better indicator (until something else turns up to disprove it), so it is moot.
70s TOTP springs to mind.
It wasn't the one I first thought of, but you are also correct.
 

Black Hole

May contain traces of nut
Video howl-around (as you put it) for DrWho/TOTP effects requires a geometry transformation per pass, as well as the brightness/contrast/saturation alterations. Feeding the output of a decoder back to the input of the encoder produces no geometry transformation - except perhaps a small linear shift (any shift should manifest as movement across the screen).
 

EEPhil

Number 28
Having done a bit more research...
...The Humax database fields cannot be a direct copy of these modes, as it uses 2 for SD.
Have you had access to the most recent version of the D-Book? I haven't. I don't know whether they've updated that information or not. The table in version I've got and that is on ukfree.tv is a bit old. At present, it looks like these modes are a "best guess". Unless someone knows (for certain) better.

Edit: There is something odd. I hope I haven't been misleading people with this information. Following these modes, the local mux shouldn't be listed at all as it doesn't fall into any category. :frantic:
 
Last edited:
Top