Premiered date is showing up wrong

[heula 189]

I started this topic in Kodi forum because in Emby for Kodi the premiered date shows one day earlier than the real premiered date.

In Square for Embu for WMC it shows the date added.

 

My opinion is that the server passes through the wrong premiered date. Can this be fixed?

It goes for Dutch and US TV shows

 

 

 

 

[Angelblue05 4130]

Do you have nfos for your content? I don't have this issue. Premiere date in Emby matches the first aired date in TVDB.

 

What if you refresh the content in the metadata manager, does it get the proper premiere date?

 

Sent from my iPhone using Tapatalk

Edited October 3, 2015 by Angelblue05

[DrWatson 62]

https://forums.thetvdb.com/viewtopic.php?t=8773

May shine some light on the issue. I think Emby treats the time from tvdb as utc when it is not it is actually the tv shows network time.

[heula 189]

Metabrowser does it correctly.

 

I didn't have nfos but I enabled that now.

Refreshing did not help. When I removed the first aired date and did a refresh it came up with the same wrong dat.

 

Screenshot from metabrowser.

 

[DrWatson 62]

What I am saying is it may be a bug with Emby applying time offset to a date that should not have a time offset applied to it - no amount of refreshing will change it (unless you change your time to p.t. or a.t.). Luke would have to confirm if there is an offset applied to the tvdb date/time. I have no idea if it is true but given the dates I have had have never been right I can only say something is screwy. I am GMT +10. 

[heula 189]

Still wrong. When will this be fixed?

[heula 189]

Maybe this is not a high priority but I hope it will be fixed cause it's pretty annoying that all episodes are one day behind.

 

Thanks!

[PeteMB 12]

This is the same problem I described here. It seems emby is storing dates in the correct utc time, by doing so it reduces or adds time. So people with a UTC time that has a positive value will have this problem. You are in a time zone like me UTC+1 (during winter, UTC+2 in summer). Emby reads a date like 11-04-2015 (mm-dd-yyyy) as 11-04-2015 00:00:00 and then adds or removes some hours depending your time zone, in hour case it will remove 1 hour and stores the date as 11-03-2015 23:00:00. As you can see the date is now a day earlier.​

[heula 189]

This is the same problem I described here. It seems emby is storing dates in the correct utc time, by doing so it reduces or adds time. So people with a UTC time that has a positive value will have this problem. You are in a time zone like me UTC+1 (during winter, UTC+2 in summer). Emby reads a date like 11-04-2015 (mm-dd-yyyy) as 11-04-2015 00:00:00 and then adds or removes some hours depending your time zone, in hour case it will remove 1 hour and stores the date as 11-03-2015 23:00:00. As you can see the date is now a day earlier.​

So this issue is almost a year old nd still not fixed.

[heula 189]

Please fix. All episodes still have the first aired date from the day before here in the Netherlands. Have been waiting for this a really long time now.

 

Thanks in advance.

Edited December 2, 2015 by heula

[PeteMB 12]

Yesterday I changed the time zone on my test system running a dev release to a negative UTC time, UTC-5, and this solved the date problem. The “Date Added” field is still incorrect, but because Emby is now adding time instead of removing time, the dates do not change.
On the right side the original movie.xml file with the correct dates and time, on the left the nfo file after the movie is being imported. The dates are now correct, because Emby is storing the date as 2014-12-25 00:00:00 + 05:00:00 = 2014-12-25 05:00:00, in our time zone emby is removing 1 hour and changes the date 2014-12-24 23:00:00.

We shouldn’t need to change out time zone to solve this problem!​

[heula 189]

Yesterday this issue was fixed but now this problem what I started in this topic get's worse.

 

When Auto Organize adds files with dates it takes the wrong episode number from the TVDB when the computer is in the Netherlands or other timeline then the US.

 

As an example there is the recording for episode 5287 and that is aired today - 19-01-2016. Emby pulls the information for that episode as 5288 and that is an episode in the future - 20-01-2016.

 

This is what the server metadata manager shows.

 

 

This is the TVDB info but Emby takes the episode for the next day instead of the one it should take.

 

 

This is what Emby for MBC shows. This shows the wrong date and episode number.

 

 

This is what Emby for Kodi shows. Wrong episode number but the right date. Don't know what Emby for Kodi uses as date to show?

 

 

Now that the issue with organizing files with date has fixed I hope that this isue will be fixed as well. Is been an issue for a very long time for people in all of Europe I think.

 

I hate to say it but metabrowser 2 pulls the right info from the same TVDB.

 

Thanks.

[heula 189]

I have also changed my timezone to UTC -5 Eastern time (VS and Canada)

I hope it will be fixed soon so timezone UTC +1 Amsterdam, Berlin, Bern, Rome etc will work to.

[DrWatson 62]

Maybe this is not a high priority but I hope it will be fixed cause it's pretty annoying that all episodes are one day behind.

 

Thanks!

 

Not a high priority is a total understatement I think NO priority would be a better description. 

 

 "PremiereDate": "2016-01-25T13:00:00.0000000Z",

 

from the emby json file

 

The raw date crom tvdb is 2016-01-26 9pm

The actual date should be 2016 - 01-27 1pm

 

My time zone is +11 gmt.

 

Is there a reason this retarded behaviour isn't fixed yet?  It also makes missing ep show up 11 hours before they even air.

 

It is the little things that make a great program attention to detail is a big part of that. It just looks like devs dont give a rats arse about fixing something that doesn't put coin in their pockets.

[speechles 1917]

builder.Append("<FirstAired>" + SecurityElement.Escape(series.PremiereDate.Value.ToLocalTime().ToString("yyyy-MM-dd")) + "</FirstAired>");

 

builder.Append("<BirthDate>" + SecurityElement.Escape(item.PremiereDate.Value.ToLocalTime().ToString("yyyy-MM-dd")) + "</BirthDate>");

Shouldnt these lines be done without the .ToLocalTime() offset applied?

 

I see where things which output the value of premiereDate apply the .ToLocalTime() before output. This would correct the output to the correct timezone. This seems normal.

 

But when saving it as a value, shouldnt this disregard the timezone? This is the part looks like the issue. It may not be this, but from a quick look at the source on github this looks suspicious.

 

Sent from my Nexus 7 using Tapatalk

Edited January 27, 2016 by speechles

[DrWatson 62]

Part of the problem is that tvdb doesn't do z time making the air time and date wrong for anyone who isn't in the viewing area of the original displaying network. So for everyone to have it right the server should convert to z time then apply local time where required.

 

Thanks for confirming @speechles 

[Luke 36997]

It would be a good data point to find out if the issue occurs with nfo as opposed to xml, and also if the issue occurs with no local metadata and just db-only saving. 

[DrWatson 62]

It would be a good data point to find out if the issue occurs with nfo as opposed to xml, and also if the issue occurs with no local metadata and just db-only saving. 

I think Heula tried that but I may be misunderstanding his post > http://emby.media/community/index.php?/topic/26050-premiered-date-is-showing-up-wrong/&do=findComment&comment=253621

[speechles 1917]

According to heula, he was using xml originally. On switching to nfo the problem eventually solved itself. He probably deleted the offending xml and let nfo replace them. The only issue he had left was matching up incorrect episodes in dutch.

 

Birthdate may be fine with tolocaltime() on it since it is derived from gmt and no further tolocaltime() are used against it. This same way dateadded is, so its just a red herring.

 

The main culprit is when using XML the tolocaltime() on premieredate which will be applied twice. Once when saved as xml, and again when calculated against missing/upcoming checks, etc. So one or the other of those has to be removed. The easier being the one pasted above.

 

Sent from my Nexus 7 using Tapatalk

Edited January 27, 2016 by speechles

[Luke 36997]

I'm pretty sure I added the ToLocalTime at the time because it would upset metabrowser and mcm. But now that xml is no longer our default format, and those savers have been moved to a plugin, we can do it whichever way you guys want. If you want to just remove the ToLocalTime then that's fine.

 

I have tested with nfo changing my time zone every which way from -12:00 to +1:00 (paris) to +12:00 and cannot reproduce the issue.

[speechles 1917]

Yeah, I think the best way is just preserve the premieredate in its raw form, and drop the local time. Then when figuring for missing/upcoming, it will be based off the time it is there (where the show was broadcast) instead of yours. This will work because most people watch shows from their own region. This will make those shows correct now, and other regions goofy (as in missing/upcoming being early/late to change for other regions) but thats a better trade off.

 

Sent from my Nexus 7 using Tapatalk

Edited January 27, 2016 by speechles

[Luke 36997]

Well for everyone saving with xml, making the change is going to cause dates to possibly be thrown off a day (or not depending on time zone), thus requiring refreshes to fix. But since xml hasn't been the default for a long time, that shouldn't be too many people.

[DrWatson 62]

I am using nfo.

 

@@Luke to repo change your timezone to +11 (Melbourne au) and add a show that shows before 10pm - eg Marvel's Agent Carter the premier date will be listed wrong by 2 days (well it is for me)

[speechles 1917]

As one of the people still using xml, it might be more than you think. To me this is an accetpable reason to switch to nfo perhaps. But yeah, it likely isnt alot of us left on legacy. Maybe fewer after they read this. Heh.

 

Sent from my Nexus 7 using Tapatalk

[heula 189]

I'm pretty sure I added the ToLocalTime at the time because it would upset metabrowser and mcm. But now that xml is no longer our default format, and those savers have been moved to a plugin, we can do it whichever way you guys want. If you want to just remove the ToLocalTime then that's fine.

 

I have tested with nfo changing my time zone every which way from -12:00 to +1:00 (paris) to +12:00 and cannot reproduce the issue.

Did you test it with only a date in the filename?

 

"Goede tijden slechte tijden 26x108.mkv" (27-01-2016) will be organized the right way.

"Goede tijden slechte tijden .2016.01.27.mkv" will be organized as "Goede tijden slechte tijden 26x109.mkv" and that is the date for tomorrow 28-01-2016.

 

I have disabled the xml files now and only nfo will be written. Issue remains for me.

Edited January 27, 2016 by heula