Roon Nucleus One displaying incorrect playback timestamps (ref#YFEAJQ)

[John_Duane]

Select your Nucleus model from the list below

· Nucleus One

I'm having trouble with my Nucleus hardware

· Other

Select the option that fits best

· The Nucleus boots up and I can connect to it in the Roon app without issue, but I have a question about configuration/storage/attached devices

Describe the issue

I've had a Roon membership since 2019 and have run Roon core on a Mac mini up until now with no issues other than speed; the Mac mini was circa 2014. I purchased a Nucleus One this month and the speed issues have (mostly) disappeared. Yay! Unfortunately, I'm seeing a problem that did NOT occur when running RoonServer on the Mac mini.

The problem is best seen via a screenshot; I'll attach one from an iPad but I see the same thing on my MacBook. Songs played in the evening (likely after midnight GMT) show up as being listened to on the next day. Basically, I'm a time traveler. :smiley:

I know that all timestamps in Roon are stored using UTC so I assume the issue is that my Nucleus One believes it's in timezone GMT +00:00. Is there a way to set it to my local time zone (Mountain Time, U.S.) which is GMT -06:00 at the moment? If not, any other ideas on how to fix this?

In case it helps, I've ensured I'm running the latest firmware and have restarted the Nucleus One multiple times to see if it would self-correct. No luck there. I'll attach a screen shot if possible.

I love the data captured and reported by Roon so I really hope I can get it to be accurate again. Thanks for any help!

[John_Duane]

Here are my system status:

[BlackJack]

Hello @John_Duane and welcome to the forum.

Roon Labs so far refuses to fix that issue:

Recent listening is 7 hours ahead

Hi @AnimalOnDrums — I’ve passed this along to the QA team for investigation. Thanks for reporting this!

Rock thinks it is living in the UK

There is none. Roon uses the UTC timezone (tz) internally. This means that the software has to do tz conversions every time it stores/retrieves dates from to it’s database. Sadly there is something of a tradition for Roon Labs to not get this right for all platforms on the first release of a feature and it usually takes quite some time for them to correct such issues (not important enough). AFAIK you’re not the first one reporting this but I can’t remember that Roon Labs officially aknowledged…

Recent listening TOD is OFF

Nothing new but seems to be not important enough to fix yet:

Played Date incorrect

Which sounds like the opposite of what Danny Dulai posted in a much, much older thread: Anyway, I would totally expect the BIOS date/time being displayed in UTC. AFAIK are OSs from Microsoft the only ones (from the list of supported OSs for Roon Server) who set the RTC (BIOS date/time) to local time. If all works as expected, the RTC will even reset to UTC if a user changes it to something else. The only idea I can think of, where a user might be able to introduce date/time issues possibly, …

Recently Played Not Showing in the Evening

Known issue but likely not high on the list of priorities:

Setting time zone

The correct system timezone (BIOS) for UNIX and Linux based machines is UTC (mostly the same as GMT) since, I’m not sure, forever. It’s up to the applications/programs to translate time and date values into a users local timezone. So it’s up to Roon Labs to fix time/date handling/display for Roon in areas where it is currently wrong. Obviously does fixing the Recent listening (introduced with Roon 1.8) not have a high priority or it would have been fixed by now (currently at Roon 2.0).

Songs being allocated to incorrect days - timezone issue?

Hi @Jack_Flude, RoonOS operates in UTC, instead of defaulting to the timezone of the OS on the Remote. So, depending on your geographic location and whether your Core is in your timezone, tracks might not match your local date. This is an unfortunate situation for many of our users in Australia or New Zealand.

Roon Time Zone Issue on ROCK (ref#MHJAPR)

There is no solution. It seems that’s just how Roon works, that Roon Server uses UTC tz internally for all timestamps and is unable/unwilling to correctly translate them to a remotes local time for listening stats. I can’t see what this has to do with ROCK or that users can’t set a tz for ROCK. My Server (and other users Servers too I guess) is not ROCK and has correctly configured tz and the listening stats are wrong too. Note: Time zone is a OS and not a BIOS feature. Please leave the BIOS t…

[noris]

Hi @John_Duane , @BlackJack ,

Thanks for the reports. Nucleus does indeed run on UTC time, but I’ll bring this issue up with the dev team to see if there’s anything that can be done to make progress on this. We’ll let you know after discussing this with them.

[BlackJack]

Every modern OS, maybe with the exception of Microsoft Windows (but even they may have changed that meanwhile), “runs” on UTC (= system time) and local time is derived from that (where and when needed on the fly) with using time zone data. So users can’t set the tz for ROCK/Roon OS but the system could obtain that information automatically – but we don’t know for sure if it does because we don’t have access. Even if not, the Control could provide the tz or even potentially make the conversion (see also: Why UTC and not local time?[ticket in] - #2 by danny about backups).
No user, seeing terms like today, yesterday, … or a date, expects those to be expressed in UTC instead of local time. Please Roon Labs, fix that broken feature or remove it.

[John_Duane]

Thanks for all the awesome replies and for all the links to related issues in the past. It’s odd to me that I never saw the issue when running RoonServer on a Mac.

I’m tempted to return the Nucleus One and buy a new Mac mini. I assume a new mini will take care of the speed issues I was encountering just as well as the Nucleus and I will be back to having data presented in the right timezone. How to I go about returning it?

I wanted to support Roon by buying their hardware but this bug is getting in the way of that.

[benjamin]

Hey @BlackJack and @John_Duane,

We’ve got a fresh ticket submitted for developer review, and there aren’t any additional details needed at this time, but if f any other questions arise after the developers have reviewed the case, we will follow up.

Thanks again for your report, and thank you in advance for your patience as the ticket progresses through the development queue for review.

[John_Duane]

Hi @benjamin - Can you provide an update on the ticket you submitted? If it does not look like a fix is imminent, can someone DM me to set up an RMA?

Thank you!

[connor]

Hi @John_Duane,

Thanks for your patience. At this point, there’s no fix prepared for an #earlyaccess release, so you can’t realistically expect a solution to merge into the production build within the next release cycle. This inevitably means a wait of at least several weeks.

Please see your DMs for additional information. Thank you!

[connor]

Hi @John_Duane,

We’ve prepared a fix for the issue you originally reported on RoonOS machines. It should merge into the next Early Access release for testing, and from there to the upcoming Roon production release.

If you’d like to test the fix once it’s released, you can merge your RoonServer and Roon devices to the Early Acces branch by following this guide:

Roon Early Access Program

[John_Duane]

I love this. Thank you @connor and the rest of the Roon team. You are awesome. I’m looking forward to checking it out!!

[daniel]

Great! Let us know if the fix resolves your issue with timestamps.

[BlackJack]

I was looking into EA and it’s sad to see that it was not possible to fix the situation for all users. Nothing has changed for me running my server(s) on Linux (not ROCK) and the feature remains broken.

PS: So far I haven’t seen a report for ROCK stating if it got fixed or not.