How bad is the BBC3/4 recording problem?

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

  • new.jpg
    new.jpg
    358.6 KB · Views: 20
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?
 
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.
 
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.
 
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.)
 
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>"}
       }
 
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.
 
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).
 
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:
Back
Top