New Firmware for (T2/T3/T4/U4/V2) 06/11/2019

[MrQuade]

I wasn't sure about the button to push and I just did that the up button and it's currently displaying FlashrootFS just scrolling by

So not "Nada" then? You works have seen a message on the front panel prompting you to press the button.


Anyway, if you are getting the flashrootfs message now, then it is currently upgrading.

[netmask]

All done - the problem was my knees.... a granite floor and the T3 sitting on it. I really must elevate. Parallax error from me.... read a post that it was ok to restore from 17.3 so took a punt and did it. Seems OK

[sonicblue]

Download the Upgrade files here, please make sure you choose the correct model number:
T2 - https://beyonwiz.com.au/firmware/t2/bey ... 06_usb.zip

Finally got a USB stick that the T2 can detect at boot time for this upgrade (coming from 16.1).

Appears to have a bug where if DHCP is not enabled on the T2, the T2 disables its ethernet port entirely.

To reproduce:

1. In the T2's network adapter settings, disable DHCP.
2. Save
3. OK on the dialogues
4. Select network settings/info
5. Notice the "enable ethernet network interface" is disabled and the green/orange lights on the physical ethernet port are off

Can't find any way around this so far.

[Grumpy_Geoff]

Appears to have a bug where if DHCP is not enabled on the T2, the T2 disables its ethernet port entirely.

I followed your steps.
Our T2 is still on 19.3 series "stable beta" 20190818 - it doesn't have that issue. Neither does our U4 on 20191106.

Can't find any way around this so far.

Try running the 'Network wizard'.

[sonicblue]

I followed your steps.
Our T2 is still on 19.3 series "stable beta" 20190818 - it doesn't have that issue.

I'll give that version a try and report back tomorrow.

Unrelated question: does 19.3 now not let you remove the EPG detailed info text at the top quarter of the screen when in the full screen EPG view (i.e pressing EPG on remote)? Because I can't seem to find a way to remove it, and on the previous version 16.3 I definitely had it removed.

[sonicblue]

False alarm.

The issue was that T2 sets the subnet mask to 0.0.0.0 by default, which I guess is interpreted as "all traffic is local" and therefore disables the network adapter altogether.

I either didn't notice it or forgot that it was the wrong subnet mask for my network (255.255.255.0).

Sorry!

[MrQuade]

Unrelated question: does 19.3 now not let you remove the EPG detailed info text at the top quarter of the screen when in the full screen EPG view (i.e pressing EPG on remote)? Because I can't seem to find a way to remove it, and on the previous version 16.3 I definitely had it removed.

It was changed to always be visible a while back.

See this thread for more info.

The issue was that T2 sets the subnet mask to 0.0.0.0 by default, which I guess is interpreted as "all traffic is local" and therefore disables the network adapter altogether.

I either didn't notice it or forgot that it was the wrong subnet mask for my network (255.255.255.0).

Just on this one too, I would advise you to use a fixed DHCP assignment for the T2 instead of using a static address in the T2.
If the address is assigned by your router, then your router's internal DNS database will be updated with the "beyonwizt2" name and properly associate it with the IP address. If you set the address as static in the T2, then the DNS association is never made.

[prl]

The issue was that T2 sets the subnet mask to 0.0.0.0 by default, which I guess is interpreted as "all traffic is local" and therefore disables the network adapter altogether.

More likely it was that the IP configuration of the adapter was left in an unusable state.

Any manual adapter configurations on the router's network must use the router's netmask unless the user's network has been specifically set up to do sub-networking. If the netmasks aren't set up the right way, IP traffic routing can fail, even if the netmasks are otherwise valid.

Few home users would need to do subnetting.

If your home IP addresses are in the form 192.x.x.x, then the netmask must be at least 255.255.255.0. If your home IP addresses are in the form 10.x.x.x, the netmask must be at least 255.0.0.0. ISPs typically configure their modems to use a netmask of at least 255.255.255.0, no matter which private network range they use.

[prl]

Unrelated question: does 19.3 now not let you remove the EPG detailed info text at the top quarter of the screen when in the full screen EPG view (i.e pressing EPG on remote)? Because I can't seem to find a way to remove it, and on the previous version 16.3 I definitely had it removed.

It was changed to always be visible a while back.

See this thread for more info.

Previously it was never shown, now it's always shown. There isn't enough flexibility in the EPG code to make it a user choice (and it would be moderately complicated to implement).

[prl]

Just on this one too, I would advise you to use a fixed DHCP assignment for the T2 instead of using a static address in the T2.

I completely agree, but some routers (like the VDSL2 one I got from iiNet, but don't use) don't allow you to set fixed Ethernet address/IP address mappings.

[sonicblue]

I'm having a separate issue where some EPG events keep randomly disappearing from the EPG. Every now and then a few events will randomly become blank in both the graphical EPG and single EPG views. The start and end times are still there, but their titles are blank.

I have to keep manually tuning back and forth to different channels to refresh that channel's EPG, and sometimes this does not solve the issue either.

This has happened about a dozen times in the last few days, so its kind of a dealbreaker, and I can't glean any logic to it. In EPG settings I've tried adding 120 minutes to keep guide data in the EPG, and renaming the epg file (which is stored in onboard flash memory since I don't have any other storage connected - could it be related to this? Ideally should the epg file be stored in external storage?).

The event data still appears to be present the inside the flash memory's EPG file, because in single EPG view, I can move the cursor to the blank event, click on it, and its details appear on screen. The event info also displays correctly on the info banner (ok button) but not in the graphical EPG and single EPG.

I never experienced this on 16.1, so appears to be related to 19.3. The only difference is that on 16.1 I had external storage connected, so maybe it was storing the EPG file on the external storage instead of onboard flash memory.

[MrQuade]

No, the EPG world have been kept in flash in both cases unless you manually changed something yourself.

I see these random missing events happening occasionally, but as far as I recall, I've always seen that when using three FTA guide.

I always just put it down to weird updates coming from the broadcasters, bit perhaps there is a bug there.

[prl]

I'm having a separate issue where some EPG events keep randomly disappearing from the EPG. Every now and then a few events will randomly become blank in both the graphical EPG and single EPG views. The start and end times are still there, but their titles are blank.

FTA or IceTV EPG?

I never experienced this on 16.1, so appears to be related to 19.3. The only difference is that on 16.1 I had external storage connected, so maybe it was storing the EPG file on the external storage instead of onboard flash memory.

The EPG is stored in flash by default. You can change this in MENU>Setup>TV>EPG Settings>EPG cache location, but the system won't change it behind your back. You may want to check the setting, but I doubt that that's the issue.

Have you accidentally enabled MENU>Setup>TV>EPG Settings>EPG cache reload? That's also a long shot, though.

[sonicblue]

FTA or IceTV EPG?

FTA.

Have you accidentally enabled MENU>Setup>TV>EPG Settings>EPG cache reload?

No, because I saw that it only lets you reload it once per hour at most, and the problem occurs multiple times within an hour.

The fact that moving the cursor to the blank event on the single EPG view, and clicking on it, shows the full event detail, would seem to indicate a possible bug with reading or refreshing the data from the EPG file when in single EPG view or graphical EPG view.

[MrQuade]

BTW. When I see the EPG gaps appearing, it usually happens on ABC. The extent of the missing events seems to chance depending on which service I zapped to.

For example, I switch to ANC news, and I lose the now and next events for every ABC service, but I'll switch to ABC kids and only lose the now info for the current event on that service.

It only ever send to lose the now and next event, but the issue doesn't appear to be perfectly repeatable.

[Grumpy_Geoff]

BTW. When I see the EPG gaps appearing, it usually happens on ABC.

That's where I normally see it too.
I had similar just now, in the Channel list both ABC HD and ABCComedy/Kids had no "now" (the box was on live TV on 10 HD).

I scrolled to ABC "for squids" and must've hit an EIT Now/Next change -

I zapped to it and the Channel list now shows an entry for the previously missing ABC HD event -

I looked earlier in the graphical EPG and all ABC events were present for the next 40-odd hours.

[prl]

My guess that the ABC is sending EPG items with small overlaps. The code that takes the EPG source (FTA or IceTV) and inserts it into the EPG cache removes overlaps by removing one of the two overlapping entries.

I have a speedup waiting for acceptance that takes advantage of the non-overlap condition. It reduces the time to insert a single EPG event from O(N) to O(log N) (where N is the number of events in the channel's EPG). It makes most obvious difference to the initial full IceTV EPG load when you restart the GUI. A full IceTV EPG load goes from O(N^2) to O(N log N).

[Grumpy_Geoff]

Here's another example on ABCComedy/Kids, where the current event was empty in the EPG and Channel list, but the "Now" info is present in live TV.

[sonicblue]

Same here - affects ABC almost exclusively. I say almost, because if I scroll into the future a bit I can find some empty events for other channels too. But it's mostly ABC.

[billyblue]

Kinda glad others have been having this issue as well!

I've been trying to nail down details for a bug report, but it's hard/impossible to reliably replicate.

What I've found:

Occurs on both my U4 & V2

Goes back to previous firmwares, though I can't say which one(s) - at least 12 months? Both machines are now on the current official release.

Usually ABC1 HD. Very occasionally other ABCs - 2 & News. (Don't have SD or 3 in my favourites) Don't recall seeing it on any other channel - though I'm assuming the frequent problems with C31 Melb are their prob!

Scrolling to the future and back can fix, but not always

If the now description is blank after a channel change, waiting a few seconds will populate it, but not always the guide.

[MrQuade]

Usually ABC1 HD. Very occasionally other ABCs - 2 & News. (Don't have SD or 3 in my favourites) Don't recall seeing it on any other channel - though I'm assuming the frequent problems with C31 Melb are their prob!

Yea, the community channels are a nightmare. guide will be fine one minute, though only 24 hours in advance, then completely blank an hour later. The intern probably takes care of it .

[Grumpy_Geoff]

Right now I've got the blank EPG entries on 9Gem/9Gem HD Perth for today, Tuesday, Wednesday for the same slot - 15:30/15:35-17:30 (between Antiques Roadshow and As Time Goes By).
I was using OWIF to view the Single and Graphical EPGs. At one point, the OWIF screenshot image of the Graphical EPG showed a program (movie, The Pure Hell Of ST. Trinians), but it was transient.
I think that may add to the "overlapping events" theory.

[billyblue]

Missed the post about over lapping events: hadn't noticed an occurance until late last night...

Now and next on ABC news had the times 11:31 to 12:01, while the EPG had the previous show finishing at 11:30 and the next one starting at 12:00 with a blank in between.

- The actual times may have been different: as I said, late last night

[sonicblue]

My guess that the ABC is sending EPG items with small overlaps. The code that takes the EPG source (FTA or IceTV) and inserts it into the EPG cache removes overlaps by removing one of the two overlapping entries.

I have a speedup waiting for acceptance that takes advantage of the non-overlap condition. It reduces the time to insert a single EPG event from O(N) to O(log N) (where N is the number of events in the channel's EPG). It makes most obvious difference to the initial full IceTV EPG load when you restart the GUI. A full IceTV EPG load goes from O(N^2) to O(N log N).

Does this mean a fix is forthcoming?

What about a bodge like just setting the end time of each event to the start time of the next event - would that be too slow to parse? Would it cause other bugs?

[MrQuade]

Does this mean a fix is forthcoming?

What about a bodge like just setting the end time of each event to the start time of the next event - would that be too slow to parse? Would it cause other bugs?

It's already in the latest beta firmware.

[IanSav]

Hi,

The entire Enigma2 EPG system is currently being rewritten. I will see if Simon is looking at the handling of slightly overlapping events.

Regards,
Ian.

[prl]

Does this mean a fix is forthcoming?

What about a bodge like just setting the end time of each event to the start time of the next event - would that be too slow to parse? Would it cause other bugs?

It's already in the latest beta firmware.

Overlaps between incoming new EPG data and the existing EPG happen in the normal course of program changes, and at the point where a decision is made about an overlap, the full set of updates hasn't happened yet, so it's not known whether the overlap will actually exist when the whole EPG has been processed.

What happens is that as each new EPG event is added, any overlapping events in the existing EPG are removed, and then the new event is added. Inserting the EPG data into the EPG is done one event at a time. Remember that a program change might be someting like a 150min movie replacing two 60-minute shows and a 30-minute show.

So say the existing EPG is:
09:00-10:00 ProgA
10:00-11:00 ProgB
11:00-12:00 ProgC

Say, for example, that ProgA is extended by 5 min, ProgB is shortened by 10 min and ProgC is extended by 5 min and starts 5 min earlier. The process runs like this:

New event 09:00-10:05 ProgA is processed. This overlaps the old ProgA and ProgB, and the new EPG becomes:
09:00-10:05 ProgA
11:00-12:00 ProgC

New event 10:05-10:55 ProgB is processed:
09:00-10:05 ProgA
10:05-10:55 ProgB
11:00-12:00 ProgC

New event 10:55-12:00 ProgC is processed:
09:00-10:05 ProgA
10:00-10:55 ProgB
10:55-12:00 ProgC

The non-overlap rule in the EPG means that if the broadcaster data has overlaps (which it shouldn't, since they can't broadcast two different programs at the same time), then the EPG loaded into the Beyonwiz will have gaps.

What I posted about in the post sonicblue quoted doesn't change any functionality: it's just a speedup. However, the speedup does require that there are no overlaps in the EPG for a channel at any time. That was in fact how the code operated before (apart from when the EPG is initially loaded from file at startup), so the new code introduced (as far as I know) no changes in the EPG behaviour. The same changes ran in OpenViX for a couple of months before they made it into the Beyonwiz distribution.*

The speedup was added largely because ViX processes up to a 14-day EPG. The speedup changes mean that the load time for a full EPG take O(N log N) time instead of O(N^2) so that instead of the 14-day EPG taking 4 times as long to load as a 7-day EPG, the 14-day EPG only takes a bit over 2 times the time to load.

I'd be disinclined to put any sort of "bodge" into the EPG code. It's complicated enough already. Of course, anyone who thinks that doing it is a good idea is welcome to code it and submit it for acceptance into the code repository. That part of the code doesn't require much knowledge of the rest of the workings on enigma2.

* for the technically inclined: if there are no overlaps in the EPG, the location of which events might overlap a new event to be inserted can be found in O(log N) time by various sorts of binary search. The time-ordered list of events for a channel in the EPG was already stored in a C++ map<> template, ordered by time and a lookup (map::find()) is guaranteed to be O(log N) in time.

If there are overlaps in the EPG, a linear search of the EPG has to be done in order to locate any overlaps with a new event to inserted, so finding the overlaps is O(N). That was how the old code worked, even though it wasn't necessary because non-overlap was already enforced. Actually, it's a bit more complicated than that, but this post is already too long.

[sonicblue]

I just got the V2 (19.3.20191106) and have found a couple of issues.

1. When using auto res, there are unnecessary video mode reinitialisations. The T2 does not have this behaviour. I tried adjusting [skip EDID check] and [delay time] to no effect.

edit: the root cause appears to be the V2 setting the global fixed resolution on every channel change, before autores then sets it back to the user specified resolution after its delay time. This can be observed by setting the autores delay time to a long value (eg. 8 seconds).

2. I find the V2's image sharpening algorithm to be decent (a bit of HQx flavour to it) and in my view can improve the upscaling of SD channels considerably. However the setting is bugged with what looks like an integer overflow. Steps to reproduce:

1. Set video mode to 1080i or 1080p fixed (it may occur for 2160p too but I don't have a 4k screen to test).
2. Set the tuner to an SD channel
3. Clear the bug in case it's currently in effect, by either:
    a) rebooting
    b) changing the video mode
    c) opening and then closing the graphical EPG with preview window enabled
4. Pause on a scene with suitable imagery for assessing sharpness, eg. advertisement with small text, or watermark against dark background.
5. Alternate sharpness between 171 and 172 and notice there is no perceptible effect
6. Change to a different SD channel, and then back to the previous SD channel (but not using the graphical EPG)
7. Alternate between 171 and 172 and notice 172 now appears to cause sharpness to drop back to 0

This only seems to affect SD channels.
The behaviour is inconsistent and sometimes requires more than one channel change to trigger it.


3. This is a minor issue, but it seems the V2 outputs in RGB colour space unless manually setting it to YCrCb (444) in both global video settings and enhancement settings. In my experience RGB colour space can cause issues with TV's, such as their processors thinking RGB implies "full range" levels, or they apply different processing intended for PC's. imo it makes more sense to default to YCrCb as this is what most TV's seem to be comfortable with and is the format used by most video content. My TV just happens to have a bug where its red luminance is much higher in RGB space causing skin tones to appear overly reddish, so I noticed it immediately. Another example is the Wii U which only outputs RGB and this caused many users TV's to default to the wrong black level and people were playing games on it for years believing the poor dynamic range was the artistic intent.

[MrQuade]

1. When using auto res, every channel change forces a video mode reinitialisation. The T2 does not have this behaviour so I was surprised to find it on V2. Is this intentional? I tried adjusting [skip EDID check] and [delay time] to no effect.

It depends on your settings. Mine doesn't.
The V2 does handle resolution changes a bit differently, but not in the way you are describing. I think we covered this somewhat previously.

The HD 1080i channels are not actually detected properly by autoresolution on any of the T/U/V series boxes. When a 1080i50 channel is encountered, the Wiz will fall back to whatever you set your fixed resolution setting to. This can throw you off if you actually wanted 576i50 and 1080i50 channels to output at the same resolution and setting, since the "fixed" resolution setting is no longer visible to the user once autoresolution is enabled you can end up with unwanted resolution changes any time you switch between HD and SD.

You'd be better off discussing these more esoteric picture quality items in a separate thread rather than in the firmware one.

[sonicblue]

The HD 1080i channels are not actually detected properly by autoresolution on any of the T/U/V series boxes.

But if I turn the autores info banner on, it correctly reports the source is 1080i50 for all 1080i50 channels (edit: but only when fixed res is set to 1080p. Also, the EPG info banner correctly reports the resolution of all channels, so it's still a bug that could be fixed imo).

After some further testing, it seems the root cause of the unnecessary video mode reinitialisations on the V2, is that on channel change it insists on first setting the display mode to the global (fixed) resolution, even when autores is enabled, before autores finally sets it to the specified resolution. The T2 does not have this behaviour, which allows it to sidestep the issue altogether.

Steps to reproduce:

1. Set fixed resolution to 1080p50
2. Turn on autores, and set 576i50hz to output as 576i
3. Set autores info banner to 15 seconds (for debugging purposes)
4. Set the autores delay time to a value longer than your TV takes to initialise a display mode (eg. 8 seconds)
5. Turn your TV's info banner on so you can see what resolution the V2 is outputting at all times
6. Zap between 576i channels and notice how it first changes to 1080p50 before autores changes it back to 576i after 8 seconds

I also suspect the colorimetry may be wrong when outputting 576i, possibly using Rec 709 instead of Rec 601.

[MrQuade]

After some further testing, it seems the root cause of the unnecessary video mode reinitialisations on the V2, is that on channel change it insists on first setting the display mode to the global (fixed) resolution, even when autores is enabled, before autores finally sets it to the specified resolution. The T2 does not have this behaviour, which allows it to sidestep the issue altogether.

Ahh yep, good spot. My settings have all SD/HD and default resolutions set to the same 2160p50, so I didn't see the intermediate switch to the default rate.

Now hopefully these are some things that can be fixed given that the availability of driver source code for the V2's chipset sounds like it is a bit patchy.

If you find more video mode type issues, I really think the topic could do with its own thread, so it can be collected in one focused spot.

[sonicblue]

Found a way to reset the V2's sharpness bug: open and close the graphical EPG with preview window enabled. My theory is that when the scaler downscales the raster to the small preview window and then back to full screen, it re-initialises all the video enhancement settings, which in turn clears the bug.

[sonicblue]

Also seeing a new random bug where if global fixed mode is set to 1080 multi, zapping will occasionally cause the video mode to change to 1080 60hz. I guess it's either incorrectly detecting the channel as 60hz, or failure to detect and then defaulting to 60hz.

[MrQuade]

Yea, I haven't had much luck with multi on the V2.

The OpenATV firmware has a bunch more options for video modes.
I haven't looked at that recently though as the latest firmware images from them don't work on the V2 any more.
Still trying to work out the best way to sort that out.

[prl]

I haven't looked at that recently though as the latest firmware images from them don't work on the V2 any more.
Still trying to work out the best way to sort that out.

Are you using ATV in the on-board flash or in the SD card?

[MrQuade]

Are you using ATV in the on-board flash or in the SD card?

Just trying to write the recovery image to internal flash.

I did notice that there was a new 18/5/2020 image, and all the previous ones were taken down, so not sure if they have noticed the non-working builds, or if that is just a matter of course (normally there is the current build and 2 prior builds posted).

I have attempted to flash the non-recovery image using the online flash tool, which works for the production hardware, but not my pre-release box unfortunately.

[prl]

Are you using ATV in the on-board flash or in the SD card?

Just trying to write the recovery image to internal flash.

I think that running either new-multiboot ViX or ATV from the eMMC onboard flash doesn't work at the moment on the SF8008/V2 platform.

Try flashing an old ATV to eMMC, then use that to flash a new ATV to an SD slot. If it boots, but goes into an enigma2 restart loop, you need to add the following to these files in /boot (on any running system). The new parameter can go anywhere between the single quotes:
in STARTUP_ 2: kernel=/dev/sda1
in STARTUP_3: kernel=/dev/sda3
the sda numbers should be 1 less than the corresponding root= number in those files.

Don't modify STARTUP_1.

Then shut down and use the multiboot selector on restart to boot the new-multiboot ATV.

I think that running the SD partitioner in the new-multiboot boottime management screen will also fix the kernel= problem, but you'll need to re-install new-multiboot ATV onto the SD card after repartitioning. I haven't tried this, but I may try it in the next few days. I'm not sure whether doing that will affect boot from eMMC, but it shouldn't need to change STARTUP_1, so it's likely that that will be OK.

Adding the kernel= line may not be necessary to run new-multiboot ATV, but it is definitely necessary to run new-multiboot ViX. And for ViX, it needs to be done for all STARTUP_* files other than STARTUP_1, even for SD partitions that don't contain a ViX image (don't ask).

I spent a good bit of yesterday being helped by Tony Whalley (ViX/multiboot developer) to try to sort this out.

The failure to boot new-multiboot ViX and ATV on the SF8008/V2 platform is a known issue. I'm not sure about when there might be a fix.

I've given Tony a serial log of a failed ATV boot from eMMC.

[tb123]

After a little bit of help.

I’ve just tried to upgrade my T4 from 17.5 to 19.3 via USB. I did a backup first.

After running the update, I get a message to remove the USB and press the power button. When I press the power button the T4 just goes blank, no reboot, no lights, nothig.

If I press the power button on the front panel or on the remote, the red light flashes, but nothing happens.

If I switch the power off at the rear and turn it on again I see Booting T4 2015-06-15 and the splash screen, but it just sits there.

Any suggestions?

[MrQuade]

If I switch the power off at the rear and turn it on again I see Booting T4 2015-06-15 and the splash screen, but it just sits there.

Have you tried a second power cycle? Leave it off for about 20 seconds just in case.

If that's not working, just try flashing from USB again.

[tb123]

If I switch the power off at the rear and turn it on again I see Booting T4 2015-06-15 and the splash screen, but it just sits there.

Have you tried a second power cycle? Leave it off for about 20 seconds just in case.

If that's not working, just try flashing from USB again.

Yep, done both of those things

Just trying to flash it back to 17.5 at the moment

Edit: looks like I got it back to 17.5 at least - restored settings and everything looks to be ok

[MrQuade]

Yep, done both of those things

Just trying to flash it back to 17.5 at the moment

Edit: looks like I got it back to 17.5 at least - restored settings and everything looks to be ok

Strange, maybe your download or extraction went wrong. Maybe download a fresh 19.3. Definitely not normal to have it fail like that.

[peteru]

Sounds like the flash process went wrong.

Try not using the Beyonwiz supplied USB flash drive for the upgrade. One of the batches of USB drives that Beyonwiz bought appears to have had some fake USB drives thrown in by the Chinese manufacturer. The USB drives were written in such a way that as supplied the firmware on the USB drive was perfectly fine. However, writing new files to the same USB drive could result in corrupted files which, when flashed, can result in unbootable firmware. The bigger the firmware, the more risk of this happening. The bigger 19.3 firmware file is more susceptible to this problem than the smaller files in previous firmware images.

If you are interested in testing your USB drive, f3fix works.

https://fight-flash-fraud.readthedocs.io/en/latest/

Once you have used that tool to limit the USB drive capacity to what it can actually do, it's OK to use those USB drives for the firmware upgrades.

[peteru]

Here are the hashes of the files if you want to verify the integrity of the downloads:

Code: Select all

md5sum
0512a1a0957829ae57ceddf512d2545b *beyonwiz-19.3-beyonwizt2-20191106_usb.zip
5ee30038ca19335b18a1afb426278909 *beyonwiz-19.3-beyonwizt3-20191106_usb.zip
305903af8871d5bc8b5c1084791a9745 *beyonwiz-19.3-beyonwizt4-20191106_usb.zip
9bb0b5c81e30e7eebc6eff2a5b253de3 *beyonwiz-19.3-beyonwizu4-20191106_usb.zip
5844f60f974e694f89629b8ec4bf3cf7 *beyonwiz-19.3-beyonwizv2-20191106_usb.zip

sha1sum
3fca47d9631a2de90770e14d6b51731e09491eea *beyonwiz-19.3-beyonwizt2-20191106_usb.zip
7c88e7dbb956c63ed451830c1bb4c482f0c82787 *beyonwiz-19.3-beyonwizt3-20191106_usb.zip
3e69e24fc6cf901ea92819b50d31ff19d5e26556 *beyonwiz-19.3-beyonwizt4-20191106_usb.zip
dcf1f55aaa30eec2765c3b3fe72df553c1b4abde *beyonwiz-19.3-beyonwizu4-20191106_usb.zip
ed8ad1351ec611d949694a63b26a5794eed27ff9 *beyonwiz-19.3-beyonwizv2-20191106_usb.zip

sha256sum
cdfdb838844323159dd78623ff5972cd34d0cf1ea50353519a8ecc9df492ed38 *beyonwiz-19.3-beyonwizt2-20191106_usb.zip
9662f655e130e28be7d5f76501ca813de0c076d1431b1a31661f6740b105c5b6 *beyonwiz-19.3-beyonwizt3-20191106_usb.zip
cd85bdafa8b8d12a26df85e6051adaffd4399710f7a3f3b73775451cb509bad2 *beyonwiz-19.3-beyonwizt4-20191106_usb.zip
50aee35f0410ca35be9d708299953f09ecf4152e2365dd339e2798fc1710a2f1 *beyonwiz-19.3-beyonwizu4-20191106_usb.zip
3d6f3a013f39c8a5edb363bf54071f8ed1c05b2f6ea9100cd99de85058763813 *beyonwiz-19.3-beyonwizv2-20191106_usb.zip

[tb123]

Sounds like the flash process went wrong.

Try not using the Beyonwiz supplied USB flash drive for the upgrade. One of the batches of USB drives that Beyonwiz bought appears to have had some fake USB drives thrown in by the Chinese manufacturer. The USB drives were written in such a way that as supplied the firmware on the USB drive was perfectly fine. However, writing new files to the same USB drive could result in corrupted files which, when flashed, can result in unbootable firmware. The bigger the firmware, the more risk of this happening. The bigger 19.3 firmware file is more susceptible to this problem than the smaller files in previous firmware images.

If you are interested in testing your USB drive, f3fix works.

https://fight-flash-fraud.readthedocs.io/en/latest/

Once you have used that tool to limit the USB drive capacity to what it can actually do, it's OK to use those USB drives for the firmware upgrades.

I was just using an off the shelf 32GB Sandisk USB3.
I might find another (older) one to try.

[tb123]

Tried it again - different computer, different download, different USB, mainly the same result.

After removing the USB and pressing the Power button the T4 just went blank again. Had to power reset it with the rear switch.
Can't remember now if I needed to do that once or twice but eventually got it to load and advise that I could restore from a backup, selected ok there and it went off and stayed off.

Power cycle again and it got stuck at booting, another power cycle got it up and running. all settings appeared to be intact, I checked and confirmed the unit was at v19.3

Put the T4 into Standby and got it back on again ok, tried a long press of the remote power button and selected reboot and the T4 got stuck at booting again, left it like that for 15 minutes,

Hopefully I can get it back to 17.5 again

edit: managed to restore it to 17.5, think I'll put the white flag up and leave it there for a while

[vader1111]

I was just using an off the shelf 32GB Sandisk USB3.
I might find another (older) one to try.

That might be your problem. Wizzes can be very picky about which USB sticks they will recognise when flashing firmware. Anything that's USB3 is probably waay too new to work with the Wiz.

The Lexar S50, available from Woolworths, is one which is known to work reliably:
https://www.woolworths.com.au/shop/sear ... 0usb%20s50

[tb123]

I was just using an off the shelf 32GB Sandisk USB3.
I might find another (older) one to try.

That might be your problem. Wizzes can be very picky about which USB sticks they will recognise when flashing firmware. Anything that's USB3 is probably waay too new to work with the Wiz.

The Lexar S50, available from Woolworths, is one which is known to work reliably:
https://www.woolworths.com.au/shop/sear ... 0usb%20s50

Perhaps, but that doesn't really explain why either of the USB's I tried, (one new, one old) allowed 17.5 to be flashed back successfully does it?
Also, the fact that I did manage to get it to boot once with 19.3 installed (by flicking the power off and on) but not again would suggest something more intermittent or flaky, wouldn't it?

I'm not having any issues with 17.5, so am in no hurry to upgrade it other than "just because" so not about to start buying USB's in the hope they might work at this stage - thanks for the tip though

[MrQuade]

Usually the USB pickiness results in an inability to recognise the USB stick at all. That doesn't sound like its the case here, and as long as it is a retail branded USB stick, it is unlikely to be one of those bodgy imports that incorrectly report capacity.

[Grumpy_Geoff]

Perhaps, but that doesn't really explain why either of the USB's I tried, (one new, one old) allowed 17.5 to be flashed back successfully does it?
Also, the fact that I did manage to get it to boot once with 19.3 installed (by flicking the power off and on) but not again would suggest something more intermittent or flaky, wouldn't it?

I'd be a bit suspicious of the tuner power regulators if you haven't had them attended too already. Doc warkus mentioned to me that flash memory issues can result from the bum regulators.
I'd suggest disconnect the power, wait 30 minutes, take off the cover and take a gander.