Emby Server small visual bug: If you start and then cancel a scheduled task

[Aevaris 8]

Found a small visual bug that I did not see a bug report for:

If you start and then cancel a scheduled task, the status will initially say "Last ran in 2 seconds, taking 1 seconds." which will then increment to "Last ran 1 second ago, taking 0 seconds". I suspect this should say "Last ran 0 seconds ago, taking 1 seconds" instead of "Last ran in 2 seconds". Interestingly, the string "in 2 seconds" seems consistent regardless of how long I let it run before cancelling.

[Carlo 4561]

Hi,

The first number will keep increasing because that's how long ago the task was ran.  The second number is how long the process took to run and shouldn't change.

Edited November 30, 2020 by cayars

[Aevaris 8]

10 hours ago, cayars said:

Hi,

The first number will keep increasing because that's how long ago the task was ran.  The second number is how long the process took to run and shouldn't change.

Sure, but shouldn't it say "Last ran X seconds ago for Y seconds"? What I'm seeing is it first says "Last ran in 2 seconds ago" and then it switches to "last ran 1 seconds ago" and then counts up from there.

[Carlo 4561]

I'm wouldn't think so no, because it's normally going to look more like this:

[Luke 42083]

No he's right, last ran in 2 seconds doesn't make sense. i'm just having a hard time getting that to happen.

[GrimReaper 4746]

If your server time is not same as device time from where you're accessing it, it is easily recreated. 

 

[Luke 42083]

Got it, thanks.

[roaku 842]

I had it on my Synology just now viewing through the web UI.

Refreshing the page got it looking normal again.

[Luke 42083]

Ok the problem is we're using a native function to get that relative time string, which is great because the system (or browser), gives it to us already translated. I'd rather not have to give this up and build this text ourselves, so we're just going to have to hack it.

If your device time is wrong and ahead of the server, then we'll just have to hack it and hard-code it to something like 1 second offset.

[Carlo 4561]

1 hour ago, Luke said:

No he's right, last ran in 2 seconds doesn't make sense. i'm just having a hard time getting that to happen.

Isn't the two seconds just the amount of time since you ran/ended the job.  If you wait 5 seconds and refresh the page it should then say 7 seconds in that same spot.

The timezone thing is a different issue altogether isn't it?

[GrimReaper 4746]

1 minute ago, cayars said:

Isn't the two seconds just the amount of time since you ran/ended the job.  If you wait 5 seconds and refresh the page it should then say 7 seconds in that same spot. 

No, actually, it would say "3 seconds ago".

Edited December 1, 2020 by GrimReaper76

[Luke 42083]

1 minute ago, cayars said:

Isn't the two seconds just the amount of time since you ran/ended the job.  If you wait 5 seconds and refresh the page it should then say 7 seconds in that same spot.

The timezone thing is a different issue altogether isn't it?

Yes it should say that. Being in a different timezone from the server is ok. The issue is mainly about being in the same timezone and having devices whose clock times are slightly off from the server.

[Carlo 4561]

I guess I'm not sure what the device has to do with duration or how long ago a process ran.  Those aren't timezone dependent.  5 min ago is still 5 minutes ago regardless of when it ran.

Is the Server not generating the strings sent to the clients?

[GrimReaper 4746]

Which then gets translated to client machine time and that value presented? This is net result of client time being 10 minutes BEHIND server time:

 

[Luke 42083]

That's right, yes.

[GrimReaper 4746]

12 minutes ago, Luke said:

That's right, yes.

Maybe it would be better to present absolute time server-wise then, regardless of actual time on any machine? Just how much time elapsed on SERVER since last occurence?