How bad is the BBC3/4 recording problem?

[mightyoakbob]

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]

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

 

[mightyoakbob]

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.

 

[Black Hole]

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]

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]

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]

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

 

[Trev]

You've sent me your database before...

So I forgot

It's just video howlround. I could tell you where that used to get used on-air intentionally in a limited sort of way!

70s TOTP springs to mind. Howlround with a delay?

 

[Black Hole]

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?

       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]

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.

 

[Ezra Pound]

It wasn't the one I first thought of, but you are also correct.

Doctor Who maybe?

 

[Black Hole]

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

 

[Trev]

Doctor Who maybe?

That also occurred to me.

 

[EEPhil]

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.