simonk83 7 Posted February 3, 2017 Share Posted February 3, 2017 (edited) 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 Link to comment Share on other sites More sharing options...
Luke 37272 Posted February 3, 2017 Share Posted February 3, 2017 If you use the metadata editor function, what does that say? Link to comment Share on other sites More sharing options...
simonk83 7 Posted February 3, 2017 Share Posted February 3, 2017 (edited) 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 Link to comment Share on other sites More sharing options...
Luke 37272 Posted February 3, 2017 Share Posted February 3, 2017 What is your system timezone setting set to? Link to comment Share on other sites More sharing options...
simonk83 7 Posted February 3, 2017 Share Posted February 3, 2017 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 Link to comment Share on other sites More sharing options...
haggis663 0 Posted February 3, 2017 Share Posted February 3, 2017 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. Link to comment Share on other sites More sharing options...
softworkz 3350 Posted February 4, 2017 Share Posted February 4, 2017 (edited) 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 1 Link to comment Share on other sites More sharing options...
simonk83 7 Posted February 6, 2017 Share Posted February 6, 2017 Need any more info Luke? Happy to help where I can to get this one worked out. Link to comment Share on other sites More sharing options...
simonk83 7 Posted February 24, 2017 Share Posted February 24, 2017 Opened an issue for this - https://github.com/MediaBrowser/Emby/issues/2486 Link to comment Share on other sites More sharing options...
Luke 37272 Posted February 24, 2017 Share Posted February 24, 2017 Thanks ! Link to comment Share on other sites More sharing options...
simonk83 7 Posted February 24, 2017 Share Posted February 24, 2017 Thanks ! Oops, totally missed that open issue (https://github.com/MediaBrowser/Emby/issues/2383), sorry! Link to comment Share on other sites More sharing options...
heula 189 Posted July 4, 2017 Author Share Posted July 4, 2017 (edited) 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 Link to comment Share on other sites More sharing options...
heula 189 Posted July 12, 2017 Author Share Posted July 12, 2017 The above issue still exist. Any idea what this error means and when it will be fixed? Thanks. Link to comment Share on other sites More sharing options...
Luke 37272 Posted July 12, 2017 Share Posted July 12, 2017 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. Link to comment Share on other sites More sharing options...
heula 189 Posted July 12, 2017 Author Share Posted July 12, 2017 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. Link to comment Share on other sites More sharing options...
heula 189 Posted August 14, 2017 Author Share Posted August 14, 2017 (edited) 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 Link to comment Share on other sites More sharing options...
heula 189 Posted December 15, 2017 Author Share Posted December 15, 2017 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. Link to comment Share on other sites More sharing options...
schumi2004 9 Posted December 15, 2017 Share Posted December 15, 2017 @@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 Link to comment Share on other sites More sharing options...
heula 189 Posted December 15, 2017 Author Share Posted December 15, 2017 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. Link to comment Share on other sites More sharing options...
haggis663 0 Posted December 16, 2017 Share Posted December 16, 2017 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. Link to comment Share on other sites More sharing options...
bgx 16 Posted January 10, 2018 Share Posted January 10, 2018 +1 had the same problem. Hope it will be fixed. Link to comment Share on other sites More sharing options...
heula 189 Posted January 10, 2018 Author Share Posted January 10, 2018 (edited) 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 Link to comment Share on other sites More sharing options...
heula 189 Posted June 28, 2018 Author Share Posted June 28, 2018 (edited) 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 Link to comment Share on other sites More sharing options...
jmos1277 9 Posted July 10, 2018 Share Posted July 10, 2018 (edited) 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 Link to comment Share on other sites More sharing options...
heula 189 Posted August 16, 2018 Author Share Posted August 16, 2018 (edited) @@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 Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now