The timestamp is there at server startup, but drops off after the Difficulty level INFO message is written to the console. They were time-stamped up to and including Version 1.16.40.2, but not from 1.16.100.4 onwards (see below examples);
Is there a process for getting an update or assigning an issue? This bug remains unresolved and unassigned, and is preventing backup scripts from functioning correctly as they rely on timestamps to detect whether a player has connected/disconnected since the last backup. Without that, taking hourly backups is causing capacity issues.
I believe the following Microsoft UWP Develop articles relate to and address this issue, if this information could please be relayed to the developers:
Oh what horrible timing. I rebuilt my Hyper-V server and re-imported all my VMs, including a Bedrock Server I hadn't used for a couple of months. Fired it up to check it was working ok, but couldn't connect (the exact issue described in this ticket). Spent days on and off trying to figure out what I'd cocked up during the re-import, only to discover this bug completely unrelated to what I'd done - just poor timing.
Indeed, sudo ethtool -K eth0 tx off worked a treat for me too.
Edit: It looks like you need to do this after each fresh boot of the VM. Added the following line to root cron (sudo crontab -e) which seemed to do the trick:
This just happened to me also. Like
MCPE-38374I spawned at high altitude above the world spawn point, not my spawn point or bed.The timestamp is there at server startup, but drops off after the Difficulty level INFO message is written to the console. They were time-stamped up to and including Version 1.16.40.2, but not from 1.16.100.4 onwards (see below examples);
Before
After
Issue persists on 1.16.200.2
Is there a process for getting an update or assigning an issue? This bug remains unresolved and unassigned, and is preventing backup scripts from functioning correctly as they rely on timestamps to detect whether a player has connected/disconnected since the last backup. Without that, taking hourly backups is causing capacity issues.
I believe the following Microsoft UWP Develop articles relate to and address this issue, if this information could please be relayed to the developers:
Postpone app suspension with extended execution
Run in the background indefinitely
Oh what horrible timing. I rebuilt my Hyper-V server and re-imported all my VMs, including a Bedrock Server I hadn't used for a couple of months. Fired it up to check it was working ok, but couldn't connect (the exact issue described in this ticket). Spent days on and off trying to figure out what I'd cocked up during the re-import, only to discover this bug completely unrelated to what I'd done - just poor timing.
Indeed, sudo ethtool -K eth0 tx off worked a treat for me too.
Edit: It looks like you need to do this after each fresh boot of the VM. Added the following line to root cron (sudo crontab -e) which seemed to do the trick: