Premiered date is showing up wrong

[simonk83 7]

Alrighty.

I live in Australia. I download my stuff through Sonarr and that handles all renaming and moving. I don't use auto organise in Emby. My files are named as fairly standard "Show Name S03E11 Episode Name.mkv".

Emby scans these in and grabs the date aired from TheTVDB. For the sake of argument let's say Supernatural S12E10. Tvdb shows this as airing on 2017-02-02.




Today is actually the 3rd here, but Supernatural airs "today" here, as shown by Sonarr:



Those shows (airing on the 2nd in the US) would all download today here (the 3rd).

Emby however shows them as airing "Yesterday" as it's not taking the timezone into account:



From what others in this thread have said, anyone in a GMT negative timezone (the US for example) doesn't see this issue. Anyone in a GMT positive timezone does.

 

 

As softworkz posted above:

 

• Following example:

   

  An nfo file contains a PremiereDate value of 2016-12-01

•  

• ​(could also be a value returned by another metadata provider)
  ​
• Emby treats this as datetime: 2016-12-01, 0:00 am and assumes it to be relative to the local time zone (of Emby Server) and converts it from there to UTC
  ​
• Now there are actually two different cases to look at:
• Your timezone is UTC-X: e.g. if you live in New York, US, then your time zone is UTC-5
  ==> 2016-12-01, 0:00 am local gets converted to a UTC value of 2016-12-01, 5:00 am
  ​
• Your timezone is UTC+X: e.g. if you live in Berlin, Germany, then your time zone is UTC+1
  ==> 2016-12-01, 0:00 am local gets converted to a UTC value of 2016-11-30, 11:00 pm

​​Conclusion: Although this bug is of general nature, it noticeably only affects users in timezones with a positive UTC offset!
​In the UI, Emby does not display a time component for the PremiereDate, so for users like in the US, everything seems right.

​But for the world living to the East of Greenwich (UTC plus X), Emby is showing incorrect dates.

 

Edited February 3, 2017 by simonk83

[Luke 37086]

If you use the metadata editor function, what does that say?

[simonk83 7]

If you use the metadata editor function, what does that say?

 

For a show that's already downloaded, Vikings S04E20 for example, TVDB says aired 2017-02-01, Emby says 31/01/2017.

 

imgur.com/a/zcjI2

Edited February 3, 2017 by simonk83

[Luke 37086]

What is your system timezone setting set to?

[simonk83 7]

What is your system timezone setting set to?

 

I run Emby in a Docker on a Synology (along with Sonarr, Radarr and NzbGet).  They're all TZ=Australia/Melbourne

[haggis663 0]

I run the Emby Server on a Windows box, the client on Windows and Android with all of them having the same issue. My server and clients are set to TZ=Australia/Brisbane or AEST.

[softworkz 3338]

This is on our list, nothing is forgotten. This is just a hard one because it may require us to change our api with Emby apps, so that's why it keep getting pushed out. Also, to my understanding the last remaining issues are related to files that are named by date and not with episode numbers. I did some testing a few months back and could not reproduce any issues outside of that.

 

No, this is not caused by episodes with dates in their names. I've explained the problem pretty well before:

 

investigated this issue today and was able to reproduce.

 

The problem is also related to this issue: http://emby.media/co...izedaily-shows/

 

It happens like in this example:

• User's timezone is UTC+2
• In TvdbEpisodeProvider, DateTime.TryParse creates a date from the string in the provider's xml data, assuming this is a DateTime matching the local computers regional settings
• Thus, the next statement ".ToUniversalTime()" converts the datetime (assumed as local datetime) to a UTC date
• E.g., if the parsed date is "2016-03-30 00:00" the converted date would be "2016-03-29 22:00"
• This is happening in the provider. So if Auto-Organize or the library is looking for 29/03 it would find the episode for 30/03 instead

Timezone conversion of these dates does not make any sense:

• Imagine a US series, premiering on 2015-01-01, 2300h EDT (Eastern Daylight Time)
  • Converted to CEST (Central European Summer Time), this would be 2015-01-02 0050h CEST
  • But would a user be interested in such an adjusted date?
  • The premiere actually occured on 2015-01-01 and this value is what's actually recorded in all databases
  • As a result, this is the value, Emby should work with
• In case someone is still thinking that working with timezone-adjusted dates would be a better idea:
  • To do this, the metdata providers would need to indicate the time zones for the provided date values
  • Currently, our providers don't supply this information
  • But this information would be required to correctly convert datetime values to neutral UTC based values
  • Conclusion: Impossible!
  • Anyway, current implementation is incorrect at least: Treating a parsed provider date value as relative to the local Culture and calling .ToUniversalTime() afterwards

I submitted a fix here: https://github.com/M.../Emby/pull/1616

 

@Luke: Bottom line is, that you must travel eastwards from your timezone to reproduce this...

Edited February 4, 2017 by softworkz

[simonk83 7]

Need any more info Luke?  Happy to help where I can to get this one worked out.

[simonk83 7]

Opened an issue for this - https://github.com/MediaBrowser/Emby/issues/2486

[Luke 37086]

Thanks !

[simonk83 7]

Thanks !

 

Oops, totally missed that open issue (https://github.com/MediaBrowser/Emby/issues/2383), sorry!

[heula 189]

Ever since I use my workaround like i told here I can live with this issue.

But now there is a new issue what I have noticed for some time now. My recordings with date in the file name is not always directly auto organized.

 

Sometimes the recordings organize will take place a day later. Sometimes the recordings will be organized right away.

 

Can you take a look at this please @@Luke

 

There is this error Emby gives.

 

 

Info is available at the tvdb.

 

When I change the name from Goede Tijden, Slechte Tijden .2017.07.03 to Slechte Tijden 27x216 I get the same error.

 

 

Server log

Edited July 4, 2017 by heula

[heula 189]

The above issue still exist. Any idea what this error means and when it will be fixed?

Thanks.

[Luke 37086]

Your tvdb data for series gets updated every few days. The fact that organizing works a day later probably just means that during the initial attempt, your tvdb data did not contain information about that episode. Then it updated and the next day it worked. It's something we can look at improving for a future update, thanks.

[heula 189]

Your tvdb data for series gets updated every few days. The fact that organizing works a day later probably just means that during the initial attempt, your tvdb data did not contain information about that episode. Then it updated and the next day it worked. It's something we can look at improving for a future update, thanks.

I know that but than I usealy get a message no data is available. Those episodes given the null error are there few more than a week now and still the same error. The info at the tvdb was available long before the show was on tv. All from the same show.

Something else is wrong here in my opinion.

[heula 189]

The issue with organizing files with dates in them I mentioned here begin july still excist.

 

Today I have an issue with organizing Match of the Day 2. Again an error code null. Info is available at the tvdb.com. When I manually set it to move to Match of the day with season 2017 and episode 1 and enable that setting for future episodes it also gives the Null error. Can this please be checked out and fixed?

 

See these images.

 

 

 

Server log

 

Thanks!

Edited August 14, 2017 by heula

[heula 189]

For me this is no longer an issue because I use Sickrage now for post processing all my media. All dates and episode naming is correct now in Emby.

[schumi2004 9]

@@heula

You just found a workaround not a solution!

I'm disappointed that after such a long time this issue is still there. For me a reason not to switch back to Emby.

 

Btw, you should try Medusa instead of Sickrage

[heula 189]

I never said I found a solution. I said this is no longer an issue for me.

For me it was the reason to search for alternatives.

 

Thanks for the tip but i'll stick with Sickrage for now. 

[haggis663 0]

This is still an issue for me. Given all Emby's really good features, I am surprised that this has taken so long to fix up. 

[bgx 16]

+1 had the same problem. Hope it will be fixed.

[heula 189]

I thougt it was working now I use sickrage but the premiered date is still one day off in the nfo.

I still need the use the method I mentioned here earlier.

 

https://emby.media/community/index.php?/topic/26050-premiered-date-is-showing-up-wrong/?p=382042

Edited January 10, 2018 by heula

[heula 189]

My windows workaround is no longer an option because I have switched to the Emby server for Synology Nas.

So I will ask once more to please fix this multiple years existing issue with the Emby Server.

 

One more time in short the issue.

Media that was recorded on 2018.06.27 will be seen as 2018.06.26 premiered date in Emby and Kodi while the nfo generated by Emby has the right date (2018.06.27) in it.

 

This is in most other timelines other than the United States.

 

Thanks again.

Edited June 28, 2018 by heula

[jmos1277 9]

I thought I would chime in and note that I'm seeing similar issues with the date being 1 day off.

I'm in US/Eastern Time Zone.

I'm using Emby's Metadata Manager to edit my metadata.

If I enter a release date of: "1997-04-18" into the web interface for the metadata manager it will actually write "1997-04-17" to the .nfo file.

 

Oddly, enough, it's not ALWAYS 1 days off.  Sometime the metadata manager write the correct date.

Weird.

Edited July 10, 2018 by jmos1277

[heula 189]

@@Luke, will this issue ever be solved?

My first post was Posted 03 October 2015 - 02:37 PM

 

Almost 3 years later now.

 

Thanks again.

Edited August 16, 2018 by heula