U4 server requires a USB reflash when not shut down cleanly.

[sub3R]

The following issue has frustrated me since first appearing some time in 2020. I was fairly certain it was a change in firmware that caused it but until now I wasn’t sure if my settings or configuration contributed to the problem.

LAN configuration:

A Telstra supplied Technicolor DJA0230TLS modem/router connected via an Ethernet patch lead to a TP-Link TP-SG108 V3 switch (No.1) in the study (the Win10 PC connects to this). Cat6 Ethernet from switch No.1 to a TP-Link TP-SG108 V1.3 switch (No.2) in the lounge room where one U4 (Wiz_U4_01) is connected to. Cat6 Ethernet from switch No.1 to a TP-Link TP-SG105 V1.3 switch (No.3) in the Living room where the second U4 (Wiz_U4_02) is connected to. Other devices are also connected to those 3 switches.

U4 configuration (both identical):

Internal HDDs with a Bluey external tuner. In the router/modem I use reserved IP addresses at the very top of the reserved address range based on MAC addresses. On the U4s; DHCP is disabled & CIFS AUTOFS selected. OverlayHD, adoxa’s AutoMute plug-in, adoxa’s epg-hide-hl plug-in, & /user/bin/ enigma2_pre_start.sh installed. Currently running f/w 19.3.20211010 (still has the same U4 server failure with that f/w after an unclean shutdown). But as shown in my testing below, the plug-ins & script are irrelevant.

The issue:

We regularly watch recordings on one U4’s HDD (the server) from the other U4 (the client) over the LAN. This works flawlessly without any obvious delay until one U4 doesn’t get shut down cleanly (usually after a 240V power outage). After one of these shutdowns the client U4 can no longer see the server U4’s recordings folder if the server was on or in standby at the time. Except for this everything else appears to still work fine, including still being able to access the shares on the PC from either U4.

For example if U4_01 was on or in standby at the time of the unclean shutdown, U4_02 (the client) will no longer be able to see U4_01’s (the server) recording folder, but U4_01 will still be able to see U4_02’s recording folder. The opposite is also true if U4_02 doesn’t get shut down cleanly. The ONLY way to rectify this issue is to do a USB firmware reflash on U4_01 (the server). This can be inconvenient at the time, is time consuming, & I’m the only one in this house that can do that.

Tests:

Knowing roughly what firmware version caused this issue I decided to find out exactly which one by trying a basic USB flash of the following firmware on U4_01 without restore settings as follows:

Flash the USB f/w without restore settings. Do a full service scan. Disable DHCP. Unmount & remove USB flash drive. Set network password. Change hostname to ‘Wiz_U4_01’. Disable timeshift & logging (to prevent possible corruption). Reboot. Network browse. Set the username & password for U4_01’s & U4_02’s movie folder. Reboot. Confirm that U4_01 can see U4_02’s recording folder & that U4_02 can see U4_01’s recording folder. Switch off at the rear power switch & switch back on again to simulate a 240V power outage. Confirm that U4_01 can still see U4_02’s recording folder & see if U4_02 can see U4_01’s recording folder. Carry out a HDD check. Default movie & timer recording location on both U4s; /media/hdd/movie. U4_02 was running f/w 19.3.20211010 for these tests.

Results:

f/w 19.3.20200328 – U4_02 could still see U4_01’s recording folder.
f/w 19.3.20200823 – U4_02 could still see U4_01’s recording folder.
f/w 19.3.20200901 – U4_02 could still see U4_01’s recording folder.
f/w 19.3.20200921 – U4_02 couldn’t see U4_01’s recording folder.
f/w 19.3.20201011 – U4_02 couldn’t see U4_01’s recording folder.
Without testing any further I knew from experience that with later firmware than 19.3.20201011, the client wouldn’t be able to see the server’s recording folder after an unclean shutdown. f/w 19.3.20200901 was again checked to make sure that it still worked as it should. I have two copies of f/w 19.3.20200901 – one marked “don’t use” & one good version – I used the good version.

So a change in f/w 19.3.20200921 (& subsequent f/w) appears to have caused the issue I am getting. Does anyone know what that was & if it can be rectified?

Error message on client U4 when trying to access recordings folder on server U4 after an unclean shutdown:

Wiz_U4_01-server-failure-error-message.jpg (59.31 KiB) Viewed 2080 times

[Gully]

You really need to test using the latest available firmware v19.3-20211010 to include all the latest updates and fixes.

Not saying it will resolve it but it isn't fair to ask without doing that at least.

[peteru]

change in f/w 19.3.20200921 (& subsequent f/w) appears to have caused the issue I am getting. Does anyone know what that was

Every firmware release has two log files, /etc/e2-git.log and /etc/oe-git.log that list most recent changes. You could start with that.

[sub3R]

You really need to test using the latest available firmware v19.3-20211010 to include all the latest updates and fixes.

I have & it still had the same server failure after an unclean shutdown.

I thought I covered that with my comments; “Currently running f/w 19.3.20211010”, & “Without testing any further I knew from experience that with later firmware than 19.3.20201011, the client wouldn’t be able to see the server’s recording folder after an unclean shutdown.”. But I’ll edit my post to make it clearer.

For reference, the last two U4 server failures with f/w 19.3.20211010 was after I reserved the IP addresses for both U4s at the two highest addresses in the router's DHCP address list, & also after I swapped the two TP-SG108 switches around so the latest version was at the router (v1.3 <-> v3). As mentioned in this topic.

[sub3R]

Every firmware release has two log files, /etc/e2-git.log and /etc/oe-git.log that list most recent changes. You could start with that.

Thanks. When I get the chance I’ll flash U4_01 with f/w 19.3.20200921 & see what those logs list.

[Gully]

You really need to test using the latest available firmware v19.3-20211010 to include all the latest updates and fixes.

I have & it still had the same server failure after an unclean shutdown.

I thought I covered that with my comments; “Currently running f/w 19.3.20211010”, & “Without testing any further I knew from experience that with later firmware than 19.3.20201011, the client wouldn’t be able to see the server’s recording folder after an unclean shutdown.”. But I’ll edit my post to make it clearer.

For reference, the last two U4 server failures with f/w 19.3.20211010 was after I reserved the IP addresses for both U4s at the two highest addresses in the router's DHCP address list, & also after I swapped the two TP-SG108 switches around so the latest version was at the router (v1.3 <-> v3). As mentioned in this topic.

Apologies then. It got a bit lost as you were highlighting results with a list of all the other firmwares.

[sub3R]

Apologies then. It got a bit lost as you were highlighting results with a list of all the other firmwares.

No need for the apologies. I should have made it clearer about the issue still persisting with f/w 19.3.20211010, or at least put a link to the topic where it still failed with that f/w. Proof reading my own posts doesn’t always pick that sort of thing up.

[Gully]

No need for the apologies. I should have made it clearer about the issue still persisting with f/w 19.3.20211010, or at least put a link to the topic where it still failed with that f/w. Proof reading my own posts doesn’t always pick that sort of thing up.

All good.

[sub3R]

Every firmware release has two log files, /etc/e2-git.log and /etc/oe-git.log that list most recent changes. You could start with that.

Thanks. When I get the chance I’ll flash U4_01 with f/w 19.3.20200921 & see what those logs list.

I decided to get the /etc/e2-git.log and /etc/oe-git.log for the following f/w versions; 19.3.20200901, 19.3.20200921, & 19.3.20201011. Contents posted below.

Contents of e2-git.log for 19.3.20200901 (no server/client issue with this version):

Code: Select all

[RecordTimer] Fuix bug #738: Unwanted shutdown when recording ends
Network: Prevent enigma2 crashes due to buggy plugins
epgcache: Use C++11 iterator API when calling map::erase

Contents of oe-git.log for 19.3.20200901 (no server/client issue with this version):

Code: Select all

Add x265 required by updated ffmpeg
Update ffmpeg to version 4.2.1
openwebif update version to 1.3.9
serviceapp: Force older git revision to prevent build breakage

Contents of e2-git.log for 19.3.20200921 (has server/client issue with this version):

Code: Select all

Prefer to report multi-standard capable tuners as DVB-T
Use standard config screen template for terrestrial location scan
Improve layout of terrestrial location scan
FrontendInfo: Prevent converter crash due to referencing a non-existent member
[InfoBarGenerics, ChannelSelection] Fix timeouts
[RecordTimer] Fuix bug #738: Unwanted shutdown when recording ends
Network: Prevent enigma2 crashes due to buggy plugins
epgcache: Use C++11 iterator API when calling map::erase

Contents of oe-git.log for 19.3.20200921 (has server/client issue with this version):

Code: Select all

Add x265 required by updated ffmpeg
Update ffmpeg to version 4.2.1
openwebif update version to 1.3.9
serviceapp: Force older git revision to prevent build breakage

Contents of e2-git.log for 19.3.20201011 (has server/client issue with this version):

Code: Select all

frontend: When tuner limites are not set, only ignore the unset limit.
frontend: ignore unset min/max frequency
frontend: convert decibel strength to relative
frontend: add signal quality for ATBM7821
frontend: incorporate upstream changes
frontend.cpp: Address compiler warnings
ChannelSelection: disable edit modes on exit
ChannelSelection: fix title during edit modes
Prefer to report multi-standard capable tuners as DVB-T
Use standard config screen template for terrestrial location scan
Improve layout of terrestrial location scan
FrontendInfo: Prevent converter crash due to referencing a non-existent member
[InfoBarGenerics, ChannelSelection] Fix timeouts
[RecordTimer] Fuix bug #738: Unwanted shutdown when recording ends
Network: Prevent enigma2 crashes due to buggy plugins
epgcache: Use C++11 iterator API when calling map::erase

Contents of oe-git.log for 19.3.20201011 (has server/client issue with this version):

Code: Select all

llmnrd: Update init script to create /run/llmnrd and log to syslog
x265 update
Add x265 required by updated ffmpeg
Update ffmpeg to version 4.2.1
openwebif update version to 1.3.9
serviceapp: Force older git revision to prevent build breakage

Reading through some topics in the Public Beta forum I noticed the beyonwiz-19.3 20200919 smb changes? topic had some interesting discussions, mainly on SMB not working but also on server/client not working.

Even though my tests results in my opening post shows that I have the server/client issue with 19.3.20200921 USB update but not with 19.3.20200901 USB update, it’s possible that 19.3.20200919 or 19.3.20200920 would give the same server/client issue (19.3.20200920 wasn’t run on either U4). Being only available as an on-line update, I have no way of testing now with 19.3.20200919 or 19.3.20200920.

[peteru]

I'm happy to see that you have been able to check for yourself the nature of the changes between the release versions that you suspected of causing the breakage. As you can probably see, there is nothing in those lists that looks even remotely responsible for causing the issues you describe.

The most likely explanation is that there may be a slight timing difference in the startup that triggers some race condition. Or, in other words the problem is always there, but sometimes you are more likely to run into it.

Investigating the issue with a configuration that always causes a failure is the preferable option since you can reproduce the problem and therefore have the ability to collect relevant data and perform root cause analysis.

[sub3R]

... there is nothing in those lists that looks even remotely responsible for causing the issues you describe.

Thanks for confirming.

The most likely explanation is that there may be a slight timing difference in the startup that triggers some race condition. Or, in other words the problem is always there, but sometimes you are more likely to run into it.

I was wondering about a timing difference causing a race condition, but I suspected if that was the case the same U4 would always server/client fail after an unclean shutdown. But in the case of a 240V power outage it can be either one, whichever one is on or in standby at the time. If both are on or in standby, both U4s require a USB reflash to fix whatever gets corrupted (assuming something is getting corrupted). If only one is on or in standby only that U4 requires a USB reflash.

My plan to further fault find is:

1. With Wiz_U4_02 running 19.3.202000901 f/w confirm that after an unclean shutdown of Wiz_U4_02, Wiz_U4_01 can still access Wiz_U4_02’s recording folder. And with Wiz_U4_02 running 19.3.202000921 f/w confirm that after an unclean shutdown of Wiz_U4_02, Wiz_U4_01 can’t access Wiz_U4_02’s recording folder.
   Results:
   Confirmed server failure with 19.3.202000921 f/w & no server failure with 19.3.202000901 f/w.
2. Test with both Bluey USB tuners removed. After confirming that the Blueys make no difference, reconnect them for further tests. Results:
   Confirmed server failure with 19.3.202000921 f/w & no server failure with 19.3.202000901 f/w.
3. Bypass the switches at each U4 & retest.
   Results:
   Confirmed server failure with 19.3.202000921 f/w & no server failure with 19.3.202000901 f/w.
4. Move one U4 beside the other U4 with both plugged into the same switch & retest. This will only check the LAN hardware, both U4s are currently on the same 240V power circuit.
   Results:
   Confirmed server failure of Wiz_U4_01 with 19.3.202000921 f/w. Tested with Wiz_U4_01 at Wiz_U4_02’s location, with both connected to Wiz_U4_02’s switch. This is the longest Ethernet run. Both running 19.3.202000921 f/w.
5. Test to see if the problem is unique to two U4s by connecting a T2 to the switch Wiz_U4_01 is connected to. No USB tuners connected to T2.
   Results:
   Wiz_T2_01 running 19.3.202000921 f/w server failed after an unclean shutdown (checked from Wiz_U4_01 & Wiz_U4_02 both running 19.3.20211010 f/w). Also tested & confirmed Wiz_T2_01 running 19.3.20200823 f/w (don’t have a good T2 19.3.20200901 f/w version) didn’t server fail after an unclean shutdown (checked from Wiz_U4_01 & Wiz_U4_02 both running 19.3.20211010 f/w).
6. By-pass the switches at Wiz_U4_01’s location & at the router’s location (already have a spare Ethernet cable run from near the router to Wiz_U4_01’s switch location). Connect Wiz_U4_01 to one Ethernet cable & Wiz_T2_01 to the other Ethernet cable beside Wiz_U4_01’s location. Connect patch leads from the other end of these Ethernet cables direct to the router. Wiz_U4_02 still at its original location. No USB tuners connected to Wiz_T2_01.
   Results:
   Wiz_T2_01 running 19.3.20200921 f/w server failed after an unclean shutdown (checked from Wiz_U4_01 & Wiz_U4_02 both running 19.3.20211010 f/w.
7. Change all references of Wiz_U4_01 to WIZU401, Wiz_U4_02 to WIZU402 & Wiz_T2_01 to WIZT2, at the router, both U4s & the T2. Delete all Beyonwiz shares on WIZU401, WIZU402 & WIZT2. On each Wiz search network with browser & save new CIFS AUTOFS mounts from the Beyonwiz network shares found (e.g. on WIZU401 give username & password to WIZU402 host then expand & activate only /hdd/movie. Do the same for WIZT2 host). Retest.
   Results:
   With the network back to its normal configuration using three switches & with WIZT2 connected to the same switch as WIZU401. Ping results from Laptop connected to switch near router to WIZU401, WIZU402 & WIZT2: <1ms, 0% loss, Minimum 0ms, Maximum 0ms, Average 0ms for all. Ping results between Wizzes: 0.396ms worse & 0% loss.
   
   (7.1 ) Tested with WIZU401 running 19.3.20211010 f/w (tested with normal username & password I use & again with guest username & no password for the same results); WIZU401 server failed after an unclean shutdown (checked from WIZT2 & WIZU402 both running 19.3.20211010 f/w).
   
   (7.2 ) Tested with WIZT2 running 19.3.20211010 f/w (tested with normal username & password I use & again with guest username & no password for the same results); WIZT2 server failed after an unclean shutdown (checked from WIZU401 & WIZU402 both running 19.3.20211010 f/w).
   
   (7.3 ) A newly created symlink on WIZU402 to see WIZU401’s movie list disappeared from WIZU402’s movie list & didn’t reappear after WIZU401 was uncleanly shut down & turned back on. It wasn’t until after WIZU401 was f/w reflashed that the symlink reappeared & worked.
   
   (7.4 ) After WIZT2 server failed due to an unclean shut down as in (7.2) above, I created a WIZT2_Movie share from network browser on WIZT2; WIZT2 can’t access this share & FileZilla can’t find it under /media/autofs/ folder on WIZT2.
   
   (7.5 ) My Samsung Tab S4 tablet connected to my LAN via WiFi & using the Beyonwiz WIZOS App could still successfully access & play movies from a Wiz that had been uncleanly shutdown & couldn’t be accessed from any other Wiz.
   
   (7.6 ) Shares on the Win10 laptop could be accessed from all wizzes prior to & after an unclean shutdown.
   
   (7.7 ) After the server failure of WIZU401 in (7.1) above due to an unclean shutdown of WIZU401, the following was observed (note that prior to the unclean shutdown all the following could be opened):
   • From FileZilla viewing WIZU401 (likewise for OWIF): /media/hdd/movie/ folder can be opened. /media/autofs/ folder can be opened. /media/autofs/WIZT2_Movie folder can be opened.
   • From FileZilla viewing WIZT2 (likewise for OWIF): /media/hdd/movie/ folder can be opened. /media/autofs/ folder can be opened. /media/autofs/WIZU401_Movie folder can’t be opened. (error message in FileZilla was ‘550 failed to change directory. Failed to retrieve directory listing’, & all options for that folder are greyed out).
   • From File Commander in WIZU401: U4 (Internal HDD) > movie (/media/hdd/movie/) can be opened. WIZT2_Movie can be opened. Internal Flash > media > hdd > movie (/media/hdd/movie/) can be opened. Internal Flash > media > autofs > WIZT2_Movie (/media/autofs/WIZT2_Movie) can be opened.
   • From File Commander in WIZT2: T2 (Internal HDD) > movie (/media/hdd/movie/) can be opened. WIZU401_Movie can't be opened. Internal Flash > media > hdd > movie (/media/hdd/movie/) can be opened. Internal Flash > media > autofs > WIZU401_Movie (/media/autofs/WIZU401_Movie) can’t be opened.
   
   (7.8 ) After the server failure of WIZT2 in (7.2) above due to an unclean shutdown of WIZT2, the following was observed (note that prior to the unclean shutdown all the following could be opened):
   • From FileZilla viewing WIZU401 (likewise for OWIF): /media/hdd/movie/ folder can be opened. /media/autofs/ folder can be opened. /media/autofs/WIZT2_Movie folder can’t be opened. (error message in FileZilla was ‘550 failed to change directory. Failed to retrieve directory listing’, & all options for that folder are greyed out).
   • From FileZilla viewing WIZT2 (likewise for OWIF): /media/hdd/movie/ folder can be opened. /media/autofs/ folder can be opened. /media/autofs/WIZU401_Movie folder can be opened.
   • From File Commander in WIZU401: U4 (Internal HDD) > movie (/media/hdd/movie/) can be opened. WIZT2_Movie can't be opened. Internal Flash > media > hdd > movie (/media/hdd/movie/) can be opened. Internal Flash > media > autofs > WIZT2_Movie (/media/autofs/WIZT2_Movie) can’t be opened.
   • From File Commander in WIZT2: T2 (Internal HDD) > movie (/media/hdd/movie/) can be opened. WIZU401_Movie can be opened. Internal Flash > media > hdd > movie (/media/hdd/movie/) can be opened. Internal Flash > media > autofs > WIZU401_Movie (/media/autofs/WIZU401_Movie) can be opened.
8. Check to see if a wiz that has server failed can be pinged from another wiz.
   Results:
   (8.1 ) Running 19.3.20211010 f/w, prior to a server failure, all wizzes can be successfully pinged to each other with PuTTY using the Wiz name (e.g. ping WIZU401) or the IP address (e.g. ping 192.168.0.254). But after a server failure, when trying to ping to a wiz that has server failed (e.g. WIZU401) using the wiz name ping WIZU401 returns bad address 'WIZU401' & doesn’t ping, however ping 192.168.0.254 works.
   
   (8.2 ) Pinging from either U4 to WIZT2 with WIZT2 running 19.3.20200823 f/w after WIZT2 was uncleanly shut down worked using ping WIZT2 & ping 192.168.0.252
   
   (8.3 ) Running 19.3.20211010 f/w, pinging to a wiz that has server failed (e.g. WIZU402) using cmd prompt on the Windows Laptop connected to the switch near the router with ping WIZU402 works as does ping 192.168.0.253.
9. See if a wiz client can access a wiz server’s recording folder if the server’s HDD is unmounted then an unclean shut down occurs.
   Results:
   With WIZU401 running 19.3.20211010 f/w verified that WIZU402 could access WIZU401’s recording folder. Unmounted WIZU401’s internal HDD with PuTTY root@WizU401:~# umount /dev/sda1& confirmed it was unmounted. Uncleanly shut down WIZU401 & switched back on. The HDD mounted as it booted up & WIZU402 couldn't access WIZU401’s recording folder. A clean shutdown of a U4 with the HDD unmounted takes 21 seconds.
10. From the network browser create a new mount for media on WIZU402 for WIZU401 (WIZU401/AllMedia) & see if this can be accessed from WIZU402 after an unclean shutdown of WIZU401.
    Results:
    (10.1 ) With WIZU401 & WIZU402 running 19.3.20211010 f/w, verified that WIZU402 could access WIZU401’s media folder before uncleanly shutting down WIZU401. After WIZU401 was uncleanly shut down, WIZU402 couldn’t access WIZU401’s media folder.
    
    (10.2 ) From the network browser created new mounts on each wiz (all running 19.3.20211010 f/w) for their own movie & media shares & also for the other wizzes media shares. Uncleanly shut down WIZU401, & WIZU402 & WIZT2 couldn’t access WIZU401’s movie & media folders. After this, deleted all media mounts & each wizzes own movie mounts.
11. Compare the config files from f/w that allows the server failure issue to the f/w that doesn’t.
    Results:
    Compared about 20 files between WIZT2 running 19.3.2020083 f/w (this f/w doesn’t allow a server failure after an unclean shutdown) & WIZT2 running 19.3.20200921 f/w (this f/w allows a server failure after an unclean shutdown). WIZT2 wasn’t uncleanly shutdown before comparing the files. All files compared were identical, including the file attributes.
12. Get the usual log files from WIZU401 & WIZT2 before & after I initiate an unclean shutdown, especially when trying to access the server’s recording folder. Repeat without doing an unclean shutdown (i.e. a successful access to the server’s recording folder). Test with a f/w version that causes the server/client issue & also with an older f/w version that doesn’t.
    Results:
    This post is now too large, so the log files will be posted in a later post.

Apart from the crash log, Enigma2-xxx.log, Enigma2_execution.log, messages, & dmesg, are there any specific log files that would help?

Can anyone think of anything else?

Does anyone have the contents of /etc/e2-git.log and /etc/oe-git.log or the change log for 19.3.20200919 & 19.3.20200920 f/w for U4 (both were on-line f/w updates)?

[sub3R]

In my last post I have updated my test results (in dark red text). It is what I expected but needed to be confirmed. With any of the U4s or T2 wizzes being used as a server or client, the tests results are the same & are 100% repeatable.

All tests were carried out with USB f/w installs without restore settings. The CIFS server failure issue after an unclean shutdown is on f/w 19.3.20200921 & all later f/w, it doesn’t appear on f/w 19.3.20200901, & my records indicate there wasn’t any CIFS server failures after an unclean shutdown with f/w prior to 19.3.20200901. See below for f/w details of f/w tested:

U4: (fails) f/w 19.3.20211010 Kernel: 4.9.51 Drivers: 180411-16.4
U4: (fails between these ↕).
U4: (fails) f/w 19.3.20200921 Kernel: 4.9.51 Drivers: 180411-16.4
U4: (unknown between these ↕). I don’t have USB f/w versions to test.
U4: (no failures) f/w 19.3.20200901 Kernel: 4.9.51 Drivers: 180411-16.4
(no failures prior to this version).

T2: (fails) f/w 19.3.20211010 Kernel: 3.14.2 Drivers: 20180416
T2: (fails between these ↕).
T2: (fails) f/w 19.3.202000921 Kernel: 3.14.2 Drivers: 20180416
T2: (unknown between these ↕). I don’t have USB f/w versions to test.
T2: (no failures) f/w 19.3.20200823 Kernel: 3.14.2 Drivers: 20180416
(no failures prior to this version).

WIZU401 share on WIZT2 with both on 19.3.20211010 f/w.

WIZT2-directory-layout-in-FileZilla.jpg (52.66 KiB) Viewed 1875 times

WIZT2 partial directory layout in FileZilla.

Logs & f/w install procedure for tests to obtain log files to follow at a later date.

[peteru]

After all of that, the most likely root cause appears to be that you don't have proper name resolution working on your network. This is evidenced by your inability to ping a machine, due to name lookup failure, in test 8.1.

Some suggestions:

• Don't use NetBIOS, WINS or other Windows name resolution.
• Don't use Bonjour / Avahi or other Apple name resolution.
• Don't use IPv6.
• Ensure that you have a good old IPv4 DNS server that properly integrates with the DHCP server. (dnsmasq is the gold standard)
• Ensure that there is only one such server on your network.
• Use a DHCP lease time of around 30 minutes.

[sub3R]

After all of that, the most likely root cause appears to be that you don't have proper name resolution working on your network. This is evidenced by your inability to ping a machine, due to name lookup failure, in test 8.1.
...

Many thanks for that observation & suggestions.

I originally suspected a name resolution issue which is why I changed all the wiz names from Wiz_U4_01, Wiz_U4_02 & Wiz_T2_01 to WIZU401, WIZU402 & WIZT2 at the router & all wizzes, & then deleted all the old shares before creating new ones. I was concerned about the underscore used in the original names. However I noticed that it didn’t make any difference.

It looks like I need to read up on, fault find & experiment with name resolutions. But I’m still at a loss as to why this issue doesn’t occur with f/w 19.3.20200901 & prior f/w after an unclean shutdown.

Before I make any changes I’ll still carry out tests for log files & post those logs, even if just for my own reference.

Your suggestion; “Use a DHCP lease time of around 30 minutes.” is interesting. I have DHCP lease time set to 21 days, which is the maximum.

[MrQuade]

Your suggestion; “Use a DHCP lease time of around 30 minutes.” is interesting. I have DHCP lease time set to 21 days, which is the maximum.

Yea, don't do that.

With that setting at 21 days, if your router (with DNS and DHCP server running) reboots, then it could be up to 10 days before one or more of your network devices asks for an address refresh, and in that time, the router's DNS server will not be able to resolve your network devices names to their IP address. (as-per PeterU's 4th point).

[sub3R]

With that setting at 21 days, if your router (with DNS and DHCP server running) reboots, then it could be up to 10 days before one or more of your network devices asks for an address refresh, and in that time, the router's DNS server will not be able to resolve your network devices names to their IP address. (as-per PeterU's 4th point).

That makes sense. I remember originally setting the lease time to the maximum so that two other Win10 laptops & the Android tablet, which connect to the router via WiFi, keep their IP addresses before I added them to the reserved IP address list using their MAC address.
I’ll change the lease time back to the default which I think was about 30 seconds or 1 hour (I think it was 1 hour because both guests are 1 hour & I didn’t change them).

Looking at the IP6 settings; I have always had IP6 disabled in my router, but netsh interface ipv6 show prefixpolicies via the cmd prompt shows that my Win10 Laptop has IP6 priority over IP4. I don’t know if that is causing problems under certain conditions.

From what I can tell I appear to be getting both IP6 & IP4 results when I ping from the Laptop to each wiz with IP6 having priority, & when I disable IP6 on the Laptop I get consistent IP4 results. Except for testing I’m not keen on leaving IP6 disabled (Microsoft states it isn’t a good idea), but I can easily change it so that so that IP4 has priority.

I like the idea of the peteru’s suggested dnsmasq IP4 DNS server, but a quick look at that indicates the Laptop, where it would be installed, would have to remain on which isn’t always the case.

[MrQuade]

All my devices have globally unique ipv6 addresses issued from my ISP, and I have not had any trouble with it. YMMV with various routers and end devices though.

[sub3R]

That’s good to know. I was trying to eliminate different things by going through peteru’s list. Just to clarify; in my router’s Broadband settings I do have IP6 available & connected. It is in the router’s Local Network settings that I don’t have IP6 enabled.

To see if IP6 having priority over IP4 on the Win10 Laptop is causing any issues, I’ll retest later with the Laptop removed from the LAN.

Looking at name resolutions, one share name that has worried me somewhat has been a wizzes local share name containing an underscore (e.g. WIZU401_Movie). The Network browser finds 192.168.0.254 (WIZU401) which expands to an option of Movie /hdd/movie which displays the local share name of WIZU401_Movie.

[sub3R]

Well none of those changes made any improvement (30 second lease time in router, IP6 disabled on the Win10 Laptop, & deleted WIZU401_Movie share & created new WIZU4Movie share).

Snipped ping results using host name from cmd prompt on Win10 laptop to WIZU401 running 19.3.20211010 f/w after an unclean shutdown of WIZU401 (server fails with this f/w):

Code: Select all

C:\>ping WIZU401
Ping request could not find host WIZU401. Please check the name and try again.

C:\>ping 192.168.0.254

Pinging 192.168.0.254 with 32 bytes of data:
Reply from 192.168.0.254: bytes=32 time<1ms TTL=64
…
Reply from 192.168.0.254: bytes=32 time<1ms TTL=64

Ping statistics for 192.168.0.254:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Snipped ping results using host name from cmd prompt on Win10 laptop to WIZU401 running 19.3.20200901 f/w after an unclean shutdown of WIZU401 (server doesn't fail with this f/w):

Code: Select all

C:\>ping WIZU401

Pinging WIZU401.modem [192.168.0.254] with 32 bytes of data:
Reply from 192.168.0.254: bytes=32 time<1ms TTL=64
…
Reply from 192.168.0.254: bytes=32 time<1ms TTL=64

Ping statistics for 192.168.0.254:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

C:\>ping 192.168.0.254

Pinging 192.168.0.254 with 32 bytes of data:
Reply from 192.168.0.254: bytes=32 time<1ms TTL=64
…
Reply from 192.168.0.254: bytes=32 time<1ms TTL=64

Ping statistics for 192.168.0.254:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

[Grumpy_Geoff]

Snipped ping results using host name from cmd prompt on Win10 laptop to WIZU401 running 19.3.20211010 f/w after an unclean shutdown of WIZU401 (server fails with this f/w):

After the ping to WIZU401 fails via name resolution and you can successfully ping via IP address, does the next name resolution ping succeed or fail?

[sub3R]

After the ping to WIZU401 fails via name resolution and you can successfully ping via IP address, does the next name resolution ping succeed or fail?

Yes & no – the results aren’t consistent as can be seen below retested & posted in the order of testing (IP6 was disabled & enabled as per the sequence in my last post):

Snipped ping results from cmd prompt on Win10 Laptop with IP6 disabled to WIZU401 running
19.3.20211010 f/w before an unclean shutdown.

Code: Select all

C:\>ping WIZU401

Pinging WIZU401 [192.168.0.254] with 32 bytes of data:
Reply from 192.168.0.254: bytes=32 time<1ms TTL=64
…
Ping statistics for 192.168.0.254:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

C:\>ping 192.168.0.254

Pinging 192.168.0.254 with 32 bytes of data:
Reply from 192.168.0.254: bytes=32 time<1ms TTL=64
…
Ping statistics for 192.168.0.254:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Snipped ping results from cmd prompt on Win10 Laptop with IP6 enabled to WIZU401 running 19.3.20211010 f/w before an unclean shutdown. Does [fe80::216:b4ff:fe06:c837%18] mean this is using IP6?

Code: Select all

C:\>ping WIZU401

Pinging WIZU401 [fe80::216:b4ff:fe06:c837%18] with 32 bytes of data:
Reply from fe80::216:b4ff:fe06:c837%18: time<1ms
…
Ping statistics for fe80::216:b4ff:fe06:c837%18:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

C:\>ping 192.168.0.254

Pinging 192.168.0.254 with 32 bytes of data:
Reply from 192.168.0.254: bytes=32 time<1ms TTL=64
…
Ping statistics for 192.168.0.254:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Snipped ping results from cmd prompt on Win10 Laptop with IP6 disabled to WIZU401 running 19.3.20211010 f/w after an unclean shutdown. Retried ping WIZU401 after a successful ping 192.168.0.254.

Code: Select all

C:\>ping WIZU401
Ping request could not find host WIZU401. Please check the name and try again.

C:\>ping 192.168.0.254

Pinging 192.168.0.254 with 32 bytes of data:
Reply from 192.168.0.254: bytes=32 time<1ms TTL=64
…
Ping statistics for 192.168.0.254:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

C:\>ping WIZU401
Ping request could not find host WIZU401. Please check the name and try again.

Snipped ping results from cmd prompt on Win10 Laptop with IP6 disabled to WIZU401 running 19.3.20211010 f/w after an unclean shutdown. Note the varied results.

Code: Select all

C:\>ping WIZU401
Ping request could not find host WIZU401. Please check the name and try again.

C:\>ping 192.168.0.254

Pinging 192.168.0.254 with 32 bytes of data:
Reply from 192.168.0.254: bytes=32 time<1ms TTL=64
…
Ping statistics for 192.168.0.254:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

C:\>ping WIZU401

Pinging WIZU401.local [192.168.0.254] with 32 bytes of data:
Reply from 192.168.0.254: bytes=32 time<1ms TTL=64
…
Ping statistics for 192.168.0.254:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

C:\>ping WIZU401
Ping request could not find host WIZU401. Please check the name and try again.

C:\>ping WIZU401
Ping request could not find host WIZU401. Please check the name and try again.

C:\>ping 192.168.0.254

Pinging 192.168.0.254 with 32 bytes of data:
Reply from 192.168.0.254: bytes=32 time<1ms TTL=64
…
Ping statistics for 192.168.0.254:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

C:\>ping WIZU401

Pinging WIZU401.local [192.168.0.254] with 32 bytes of data:
Reply from 192.168.0.254: bytes=32 time<1ms TTL=64
…
Ping statistics for 192.168.0.254:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

After an unclean shutdown of WIZU401 running 19.3.20211010 f/w, ping WIZU401 from WIZT2 via PuTTY returns ping: bad address ‘WIZU401' with IP6 either enabled or disabled on the Win10 Laptop. ping 192.168.0.254 works fine.

[MrQuade]

Well none of those changes made any improvement (30 second lease time in router, IP6 disabled on the Win10 Laptop, & deleted WIZU401_Movie share & created new WIZU4Movie share).

Did you reboot all your STBs and PCs after making the DHCP lease time change?
You'd need to do that to ensure they were all now set to the new least time. Otherwise, they would have still been waiting for that (up to) 10 day timer.

[sub3R]

Did you reboot all your STBs and PCs after making the DHCP lease time change?
You'd need to do that to ensure they were all now set to the new least time. Otherwise, they would have still been waiting for that (up to) 10 day timer.

I rebooted the router, WIZU401 & WIZT2, but didn't reboot WIZU402 or the Laptop. I'll do that.

[Grumpy_Geoff]

After the ping to WIZU401 fails via name resolution and you can successfully ping via IP address, does the next name resolution ping succeed or fail?

Yes & no – the results aren’t consistent as can be seen below retested & posted in the order of testing (IP6 was disabled & enabled as per the sequence in my last post):

I infrequently have the same issue on my Windows 10 PC to my Wizzes - unrelated to "unclean" shutdown.

I see the ping to WIZU401 sometimes resolves as name WIZU401.local (a DNS suffix?) -

Code: Select all

C:\>ping WIZU401

Pinging WIZU401.local [192.168.0.254] with 32 bytes of data:
Reply from 192.168.0.254: bytes=32 time<1ms TTL=64

Plus that IPv6 resolution -

Code: Select all

C:\>ping WIZU401

Pinging WIZU401 [fe80::216:b4ff:fe06:c837%18] with 32 bytes of data:
Reply from fe80::216:b4ff:fe06:c837%18: time<1ms

I don't know what either means, sorry

[sub3R]

Thanks for the feedback Geoff.

Early days yet, but I may have solved my server access issue after an unclean shutdown. Following what peteru & MrQuade suggested, & thinking about something that prl mentioned a long time ago about using DHCP, I did the following.

Some background first. I have always had my wizzes set up with fixed IP addresses on each wiz which meant DHCP was disabled in the Network setup. My Belkin N1 ADSL router/modem was replaced in May-2018 with a Telstra Technicolor DJA0230TLS NBN router/modem to work with the NBN. I reserved these IP addresses in this router using the MAC address of each wiz. I found this setup worked perfectly every time up to 19.3.20200901 f/w (always had access to the Laptop's shares & to each of the wiz shares, never "lost" a wiz IP address, & no issues after a power outage). But from 19.3.20200921 f/w onwards every time I had a power outage or had to shut a wiz down due to a hang, that wiz (the server) required a USB f/w install to get the server/client working again.

Today I re-enabled IP6 (the default) on the Win10 Laptop via Control Panel > Network & Sharing Centre > Change Adapter Settings > (my Ethernet LAN) > Change settings of this connection > Networking > Internet Protocol Version 6 TCP/IPv6, booted the Win10 Laptop & WIZU402 after changing the DHCP lease time in the router from 21 days to 30 minutes (WIZU401 & WIZT2 & the router had been booted just after the change), enabled IP6 in the router & enabled DHCP in the Network LAN setup in WIZU401. The router, Win10 Laptop & WIZU401 was then rebooted.

Prior to this I had WIZU401 running 19.3.20211010 f/w powered up after I had uncleanly shut it down (it was in that condition while I was carrying out the posted ping results). WIZU402 couldn’t access WIZU401 prior to doing the above today yet WIZU402 could access WIZU401 after the above changes. I did another unclean shutdown of WIZU401 & WIZU402 could still access WIZU401.

I then clean installed 19.3.20211010 f/w on WIZU401, enabled DHCP, & confirmed that after a clean & an unclean shutdown of WIZU401, WIZU402 could still access WIZU401.

Whether this will cause different reliability issues I don’t know, especially when the Win10 Laptop is shutdown or when the router restarts after a power outage.

Thanks to everyone who helped.

More testing to do.

[sub3R]

Well that was one step forward & two steps back, or maybe just two steps back.

This morning nothing worked correctly after initiating an unclean shutdown. Last night the Win10 Laptop was shutdown as it does every night & at various stages through the night & morning all three wizzes got cleanly shut down. The only wiz that worked ok this morning was WIZU402 because I didn’t initiate an unclean shutdown on it – but this arvo we had a power outage for about 1 1/2hrs & now I can’t access it from any other wiz even though I deleted & created new DHCP CIFS shares before the outage.

When everything failed I rebooted the router, Laptop & three wizzes but that didn’t improve anything. I then switched off IP6 in the router & rebooted everything again, but still no improvement. I lost count of the number of times I deleted all the CIFS shares & created new ones.

Prior to all this, with DHCP disabled it was easy & straightforward to create new shares, but now it seems to be hit & miss. Sometimes it gives an option of setting a password & other times it doesn’t. Sometimes it fills in the guest password & other times it doesn’t. Sometimes it creates the new share straight away & other times the spinner runs for a considerable length of time before creating the share. Sometimes when the client can’t connect to the server the error message appears straight away & at other times the spinner runs for a while.

The only thing that looks right is a ping to each wiz that has server failed via the Win10 Laptop’s cmd prompt using the wiz hostname (e.g. ping WIZT2) it successfully pings & reports correctly every time. Pinging to a wiz that has server failed from another wiz using the hostname does fail though.

Next I’ll try increasing the HDCP lease time in the router to see if that makes any improvement.

If that doesn’t work, I will probably flash all three wizzes with 19.3.20200901 f/w & leave it at that. At least I know that CIFS networking with that version is 100% reliable & survives an unclean shutdown. I’ve been told in no uncertain terms that spending over five weeks on & off on this is enough.

[peteru]

Seems to me like you are attacking this from the wrong end. There are strong indicators that your network/infrastructure is not functioning properly. You need to fix that first.

It's a bit like complaining about your car constantly needing to be washed. The problem isn't the car, the problem is the unsealed road full of potholes and muddy puddles.

[sub3R]

Even though I had confidence in the way my LAN was working I decided to put in some more time concentrating on the LAN configuration on the wizzes, the Laptop & the router.

It’s been a while, so just to recap; I have never had an issue accessing any of the Laptop shares from any wiz running any f/w version. I’ve never had an issue creating shares on any wiz to another wiz. Everything has worked perfectly except when a wiz has an unclean shutdown when on f/w later than about 19.3.20200901 (definitely 19.3.20200921 & later), in this case a client wiz can no longer access the recordings on the wiz that had an unclean shutdown (a USB f/w re-install on the server wiz repairs this). The wiz that had an unclean shutdown still works fine & can still access shares on the Laptop & shares on other wizzes.

For reference; since the beginning of these tests on 20-Jan-23 I have changed the Hostname for all wizzes a couple of times. Wiz_U4_01 was previously changed to WIZU401 & is now beyonwizu4a. Wiz_U4_02 was previously changed to WIZU402 & is now beyonwizu4b. Wiz_T2_01 was previously changed to WIZT2 & is now beyonwizt2.

As for testing various settings, there wasn’t much I could change in the Telstra Technicolor DJA0230TLS NBN Router/Modem from what I had previously tried except to reduce the firewall level.

In the Laptop running Windows 10 Home version 22H2 I experimented with quite a few settings. Just a few of the many changes made were; gave IPv4 a higher precedence to IPv6 (default was IPv6 higher than IPv4), I have left it at this. Various settings in the firewall were also changed. Password protected sharing had previously been turned off. SMB 1.0 had previously been disabled & remains disabled. Changed the Laptop Windows logon password. In Computer management > Services changed or confirmed various options as per on-line recommendations. None of these made any improvement to the wiz server unclean shutdown issue, & I have never had an issue accessing any of the Laptop shares from any wiz running any f/w anyway.

Just in case the firewall or something else on the Laptop was creating issues, the Laptop was shut down & various tests carried out without the Laptop in the picture. This only left the wizzes, the switches & router on the LAN. This didn’t make any improvement to the wiz server unclean shutdown issue.

Wondering if the issue was to do with Samba changes, I created a new share on beyonwizu4b (u4b) for beyonwizu4a (u4a) with the Samba protocol version set to 1.0. Both u4a & u4b were running 19.3.20211010 f/w. With u4a in the unclean shutdown condition I found that u4b could access u4a’s recordings (via MEDIA > YELLOW), which it hadn’t been able to do prior to this with u4a in the unclean shutdown condition running 19.3.20211010 f/w with Samba protocol version at default or 2.1. To confirm that it wasn’t a fluke I changed from u4b’s recordings to u4a’s recordings a few times successfully. But when left for about 10 minutes I found u4b could no longer access u4a’s recording folder. After deleting this share & creating a new one I redid this test but kept successfully changing from u4b’s to u4a’s recording folder about every 30 seconds for a period of 6 minutes. When I stopped making these changes for about 2 minutes I found u4b could no longer access u4a’s recording folder. Lanscan showed the Laptop as the master browser during this test period. SMB 1.0 was disabled on the Laptop.

In the next post I’ll post log results for tests with 19.3.20211010 f/w taken on 16-Mar-23 followed by log results for tests with 19.3.20200901 f/w taken on 17-Mar-23 in another post.

[sub3R]

Details of U4’s & T2 setup for tests to obtain the following log files:

• beyonwizu4a (IP address: 192.168.0.254) was connected to its usual switch, had a Bluey USB tuner & the main aerial connected. HDMI cable to TV via RX-V3900 receiver was swapped back & forth between beyonwizu4a & beyonwizt2 at the receiver for testing. Log files copied with FileZilla to Win10 Laptop. This was tested with 19.3.20211010 & 19.3.20200901 f/w clean installed & tested as a server (with unclean & clean shutdown for both versions).
• beyonwizt2 (IP address: 192.168.0.252) was connected to the same switch as beyonwizu4a. Didn’t have any USB tuners or main aerial connected. HDMI cable to TV via RX-V3900 receiver was swapped back & forth between beyonwizt2 & beyonwizu4a at the receiver for testing. Log files copied with FileZilla to Win10 Laptop. This had 19.3.20211010 f/w clean installed & was used as the client.
• beyonwizu4b (IP address: 192.168.0.253) had 19.3.20211010 f/w installed with restore settings, was connected to its usual switch, but wasn’t used in these tests. It could have been either on, in standby or shut down to deep standby.

Firmware clean install procedure for all prior & below tests (below example is for u4a):

1. Clean install f/w via USB on beyonwizu4a (don’t restore settings).
2. Carry out ‘Australia > NSW > Newcastle’ service scan (this won’t pick up any services).
3. In Network configuration set network to Ethernet LAN, disable DHCP to see if settings are correct & then enable. Then activate.
4. If given the option - don’t accept on-line update.
5. If given the option - select Favourites bouquet.
6. Unmount & remove USB flash drive (for beyonwizu4 only, beyonwizt2 is done at end of f/w install).
7. Disable background on-line update.
8. Disable Timeshift.
9. Stop DLNA server & disable auto-start.
10. Set Network password with Virtual keyboard.
11. Change Hostname from beyonwizu4 to beyonwizu4a via Mount Manager with Virtual keyboard.
12. Enable logging. (MENU > Setup > System > Log settings > Log location > /media/hdd & then Enable). With File Commander copy modified smb-user.conf containing [Global] log level = 2 to /etc/samba to replace the default version.
13. Reboot via MENU > Power > Reboot.
14. Network browse & from the results log into the 192.168.0.252 (beyonwizt2) share, confirm there isn’t a username or password set, & then activate it (after a reboot the username will change to guest). From the browser expand this share which expands to Movie /hdd/movie & displays the local share name of beyonwizt2_Movie, verify the settings & then activate.
15. Reboot via‘MENU > Power > Reboot.
16. Check network settings & confirm that Samba is running.

16-Mar-23 test procedure & times to obtain log files for beyonwizu4a (server) running 19.3.20211010 f/w & beyonwizt2 (client) running 19.3.20211010 f/w. The times I listed are AEDT which is UTC +11. Note: I deleted the contents of /var/log/samba/log.smbd & /var/log/samba/ log.nmbd prior to installing the f/w.

1. On beyonwizt2 clean install f/w 19.3.20211010 via USB (don’t restore settings - similar procedure to firmware clean install procedure listed above). On beyonwizt2 the share found by network browser for beyonwizu4a was 192.168.0.254 (beyonwizu4a) which expands to Movie /hdd/movie & displays the local share name of beyonwizu4a_Movie.
   Finished at 10:06am. Switched to deep standby & back on ready for testing at 10:34am.
2. On beyonwizu4a clean install f/w 19.3.20211010 via USB (don’t restore settings) (same procedure as firmware clean install procedure listed above).
   Finished at 10:28am. Switched to deep standby & back on ready for testing at 10:30am.
3. On beyonwizu4a initiate a clean shutdown from Live TV via MENU > Power > Shutdown. When shutdown completes, switch off at the rear power switch, switch back on & allow to boot back up. At 10:34am.
4. On beyonwizt2 test for beyonwizu4a server access from the beyonwizt2 client via MEDIA > YELLOW (Location) & confirm that beyonwizt2 could successfully access beyonwizu4a. At 10:37am.
5. On beyonwizu4a initiate an unclean shutdown from Live TV by switching off at the rear power switch. Switch back on & allow to boot back up. At 10:52am.
6. On beyonwizt2 test for beyonwizu4a server access from the beyonwizt2 client via MEDIA > YELLOW (Location). On beyonwizt2 confirm the following error message appears when it fails to access the Server: Directory ‘/media/autofs/beyonwizu4a_Movie/’ does not exist.. At 10:53am.

Log files from t2 after item 4 above (after t2 successfully accessed u4a at 10:37am after u4a clean shutdown):

1_enigma2_execution.log

(444 Bytes) Downloaded 23 times

1_Enigma2-2023-03-16_10-04-32.log

(33.51 KiB) Downloaded 22 times

1_Enigma2-2023-03-16_10-32-30.log

(28.15 KiB) Downloaded 20 times

1_messages.txt

(92.13 KiB) Downloaded 21 times

1_log.smbd.txt

(1.58 KiB) Downloaded 22 times

1_log.nmbd.txt

(1.02 KiB) Downloaded 20 times

Log files from u4a after item 4 above (after t2 successfully accessed u4a at 10:37am after u4a clean shutdown):

2_enigma2_execution.log

(444 Bytes) Downloaded 23 times

2_Enigma2-2023-03-16_10-29-39.log

(29.68 KiB) Downloaded 23 times

2_Enigma2-2023-03-16_10-36-13.log

(24.16 KiB) Downloaded 22 times

2_messages.txt

(49.15 KiB) Downloaded 22 times

2_log.smbd.txt

(88.18 KiB) Downloaded 24 times

2_log.nmbd.txt

(1.02 KiB) Downloaded 23 times

More log files in the next post, it won't accept any more in this post.

[sub3R]

Continued from the last post.

Log files from t2 after item 6 in the last post (after t2 unsuccessfully accessed u4a at 10:53am after U4a unclean shutdown):

3_enigma2_execution.log

(444 Bytes) Downloaded 22 times

3_Enigma2-2023-03-16_10-04-32.log

(33.51 KiB) Downloaded 22 times

3_Enigma2-2023-03-16_10-32-30.log

(29.63 KiB) Downloaded 21 times

3_messages.txt

(93.94 KiB) Downloaded 24 times

3_log.smbd.txt

(2.37 KiB) Downloaded 24 times

3_log.nmbd.txt

(1.87 KiB) Downloaded 23 times

Log files from u4a after item 6 in the above post (after t2 unsuccessfully accessed u4a at 10:53am after U4a unclean shutdown):

4_enigma2_execution.log

(493 Bytes) Downloaded 17 times

4_Enigma2-2023-03-16_10-36-13.log

(24.16 KiB) Downloaded 16 times

4_Enigma2-2023-03-16_10-51-37.log

(23.87 KiB) Downloaded 17 times

4_messages.txt

(49.02 KiB) Downloaded 20 times

4_log.smbd.txt

(921 Bytes) Downloaded 19 times

4_log.nmbd.txt

(1.02 KiB) Downloaded 17 times

In the next post I’ll post log results for tests with 19.3.20200901 f/w taken on 17-Mar-23.

[sub3R]

Log files for tests with 19.3.20200901 f/w on u4a taken on 17-Mar-23.

The wiz configuration & firmware clean install procedure was the same as for the previous tests posted here.

17-Mar-23 test procedure & times to obtain log files for beyonwizu4a (server) running 19.3.20200901 f/w & beyonwizt2 (client) running 19.3.20211010 f/w. The times I listed are AEDT which is UTC +11. Note: I deleted the contents of /var/log/samba/log.smbd & /var/log/samba/ log.nmbd prior to installing the f/w.

1. On beyonwizt2 clean install f/w 19.3.20211010 via USB (don’t restore settings - similar procedure to firmware clean install procedure listed here.). On beyonwizt2 the share found by network browser for beyonwizu4a was 192.168.0.254 (beyonwizu4a) which expands to Movie /hdd/movie & displays the local share name of beyonwizu4a_Movie.
   Finished at 11:04am. Switched to deep standby, [edit] rear power switch off [/edit] & back on ready for testing at 11:30am.
2. On beyonwizu4a clean install f/w 19.3.20200901 via USB (don’t restore settings) (same procedure as firmware clean install procedure listed here.).
   Finished at 11:23am. Switched to deep standby & back on ready for testing at 11:26am.
3. On beyonwizu4a initiate a clean shutdown from Live TV via MENU > Power > Shutdown. When shutdown completes, switch off at the rear power switch, switch back on & allow to boot back up. At 11:33am.
4. On beyonwizt2 test for beyonwizu4a server access from the beyonwizt2 client via MEDIA > YELLOW (Location) & confirm that beyonwizt2 could successfully access beyonwizu4a. At 11:34am.
5. On beyonwizu4a initiate an unclean shutdown from Live TV by switching off at the rear power switch. Switch back on & allow to boot back up. At 11:48am.
6. On beyonwizt2 test for beyonwizu4a server access from the beyonwizt2 client via MEDIA > YELLOW (Location) & confirm that beyonwizt2 could successfully access beyonwizu4a. At 11:49am.

Immediately after above tests, confirmed that u4b could also access u4a, & U4a could be pinged from u4b (ping beyonwizu4a) using PuTTY.

Log files from t2 after item 4 above (after t2 successfully accessed u4a at 11:34am after u4a clean shutdown):

5_enigma2_execution.log

(333 Bytes) Downloaded 24 times

5_Enigma2-2023-03-17_11-02-43.log

(44.53 KiB) Downloaded 19 times

5_Enigma2-2023-03-17_11-29-09.log

(33.22 KiB) Downloaded 20 times

5_messages.txt

(92.65 KiB) Downloaded 20 times

5_log.smbd.txt

(1.58 KiB) Downloaded 19 times

5_log.nmbd.txt

(1.02 KiB) Downloaded 20 times

Log files from u4a after item 4 above (after t2 successfully accessed u4a at 11:34am after u4a clean shutdown):

6_enigma2_execution.log

(444 Bytes) Downloaded 18 times

6_Enigma2-2023-03-17_11-25-57.log

(30.2 KiB) Downloaded 21 times

6_Enigma2-2023-03-17_11-32-48.log

(24.05 KiB) Downloaded 18 times

6_messages.txt

(48.74 KiB) Downloaded 24 times

6_log.smbd.txt

(88.12 KiB) Downloaded 20 times

6_log.nmbd.txt

(1.02 KiB) Downloaded 21 times

More log files in the next post, it won't accept any more in this post.

Note: Edit to Item 1 above between [edit] & [/edit].

[sub3R]

Continued from the last post.

Log files from t2 after item 6 in the last post (after t2 successfully accessed u4a at 11:49am after U4a unclean shutdown):

7_enigma2_execution.log

(333 Bytes) Downloaded 19 times

7_Enigma2-2023-03-17_11-02-43.log

(44.53 KiB) Downloaded 17 times

7_Enigma2-2023-03-17_11-29-09.log

(35.09 KiB) Downloaded 19 times

7_messages.txt

(160.38 KiB) Downloaded 18 times

7_log.smbd.txt

(2.37 KiB) Downloaded 20 times

7_log.nmbd.txt

(1.58 KiB) Downloaded 21 times

Log files from u4a after item 6 in the above post (after t2 successfully accessed u4a at 11:49am after U4a unclean shutdown):

8_enigma2_execution.log

(493 Bytes) Downloaded 21 times

8_Enigma2-2023-03-17_11-32-48.log

(24.05 KiB) Downloaded 20 times

8_Enigma2-2023-03-17_11-46-53.log

(23.76 KiB) Downloaded 19 times

8_messages.txt

(48.72 KiB) Downloaded 20 times

8_log.smbd.txt

(86.56 KiB) Downloaded 19 times

8_log.nmbd.txt

(1.02 KiB) Downloaded 20 times

[sub3R]

After the last lot of tests with u4a running 19.3.20200901 f/w & uncleanly shutdown I restored settings on u4a without re-loading the f/w. These are the results.

After restoring the settings I noticed that the u4b share still had the username & password for the Laptop (At one stage I had all shares set up with a username & password). Deleted this share & rebooted. Rescanned but the u4b share in the browser still showed the username & password for the Laptop. The only way I could get rid of this was to change it using the Logitech keyboard (couldn’t arrow down from the user to the password on the u4). After doing this I could create a new share without a username & password which worked fine.

I found the 3 Laptop shares wouldn’t work even though they looked to be correct, so I had to delete these & create new ones to get them to work. Installed OverlayHD (Ian’s latest version, not adoxa’s modified version). Installed adoxa’s Automute plug-in. Didn’t try installing adoxa’s epg-hide-hl plug-in (I tried previously & found it unfortunately won’t install on this version, the error message indicates the f/w must be 19.3.20210801 or later – anyway 2 or my 3 favourite plug-ins work). Copied the unmodified etc/samba/smb-user.conf & user/bin/enigma2_prestart.sh to the u4a.

Initiated an un-clean shutdown & verified that u4a could be accessed from u4b & that all the shares on the u4a still worked (I have done an unclean shutdown of u4a with successful results a number of times since). U4a could still be pinged from u4b with ping beyonwizu4a using PuTTY, & u4a could be accessed from the Laptop with Windows File Explorer.

Update: Both U4s have been left reliably running 19.3.20200901 f/w & have survived a few 240V power outages without any issues. The spare T2 has been left reliably running 19.3.20200823 f/w. While the T2 hasn’t survived a 240V power outage due to it being taken out of service & kept as a spare, tests show that it would have.