Jump to content

Premiered date is showing up wrong


heula
Go to solution Solved by Angelblue05,

Recommended Posts

I have been starting simple without the use of auto-organize. not everyone uses auto-organize. the simple scenario is a new episode, changing time zone, then refreshing. once i have that nailed down i will move to more complex situations like auto-organize.

The problem only occurs when using auto-organize with Emby for me. In the webclient all data is the same as on the TVDB. Only when the episodes are organized by emby with a date in the file name it goes wrong with time zones other than US time zones. Metabrowser does all this like expected within my own time zone.

 

I just did another test with two different filenames but both are the same episode. Selected timezone is +1 Amsterdam for this test.

I hope this makes sense to you because I just don't get it.

 

It's all about the episode for Goede tijden slechte tijden for today 09-02-2016

 

Goede tijden slechte tijden 26x117.mkv = organized well

 

log for this file.

2016-02-09 11:38:03.7432 Info App: Sorting file \\HOME-SERVER\MB-Opnamen\Algemene TV-Opnamen\Season 0\Goede tijden slechte tijden 26x117.mkv
2016-02-09 11:38:03.7737 Debug App: Extracted information from \\HOME-SERVER\MB-Opnamen\Algemene TV-Opnamen\Season 0\Goede tijden slechte tijden 26x117.mkv. Series name Goede tijden slechte tijden, Season 26, Episode 117
2016-02-09 11:38:03.7857 Info HttpClient: HttpClientManager GET: http://api.themoviedb.org/3/tv/224/season/2010?api_key=f6bd687ffa63cd282b6ff2c6877f2669&append_to_response=images,keywords,external_ids,credits,videos&language=nl&include_image_language=nl,null,en
2016-02-09 11:38:03.7857 Info App: Sorting file \\HOME-SERVER\MB-Opnamen\Algemene TV-Opnamen\Season 0\Goede tijden slechte tijden 26x117.mkv into series \\HOME-SERVER\Series Astrid\Goede Tijden Slechte Tijden
2016-02-09 11:38:03.7857 Info HttpClient: HttpClientManager GET: http://www.omdbapi.com/?plot=full&r=json&i=tt0096597&Episode=117&Season=26
2016-02-09 11:38:03.8092 Info App: Sorting file \\HOME-SERVER\MB-Opnamen\Algemene TV-Opnamen\Season 0\Goede tijden slechte tijden 26x117.mkv to new path \\HOME-SERVER\Series Astrid\Goede Tijden Slechte Tijden\Season 26\Goede Tijden Slechte Tijden - 26x117 - Aflevering 5302.mkv
2016-02-09 11:38:03.8482 Info TaskManager: Organize new media files Completed after 0 minute(s) and 0 seconds

Goede tijden slechte tijden .2016.02.09.mkv = organized wrong

 

log for this file 

2016-02-09 11:43:04.0388 Info App: Sorting file \\HOME-SERVER\MB-Opnamen\Algemene TV-Opnamen\Season 0\Goede tijden slechte tijden .2016.02.09.mkv
2016-02-09 11:43:04.0388 Debug App: Extracted information from \\HOME-SERVER\MB-Opnamen\Algemene TV-Opnamen\Season 0\Goede tijden slechte tijden .2016.02.09.mkv. Series name Goede tijden slechte tijden, Date 9-2-2016 00:00:00
2016-02-09 11:43:04.0598 Info App: Sorting file \\HOME-SERVER\MB-Opnamen\Algemene TV-Opnamen\Season 0\Goede tijden slechte tijden .2016.02.09.mkv into series \\HOME-SERVER\Series Astrid\Goede Tijden Slechte Tijden
2016-02-09 11:43:04.3898 Info HttpClient: HttpClientManager GET: http://www.omdbapi.com/?plot=full&r=json&i=tt0096597
2016-02-09 11:43:04.4107 Info App: Sorting file \\HOME-SERVER\MB-Opnamen\Algemene TV-Opnamen\Season 0\Goede tijden slechte tijden .2016.02.09.mkv to new path \\HOME-SERVER\Series Astrid\Goede Tijden Slechte Tijden\Season 26\Goede Tijden Slechte Tijden - 26x118 - Aflevering 5303.mkv
2016-02-09 11:43:04.4252 Info TaskManager: Organize new media files Completed after 0 minute(s) and 0 seconds

You may say otherwise but I keep saying it is an auto-organize issue based on files with dates in the name in combination with most time zones other then US.

Edited by heula
Link to comment
Share on other sites

Only when auto-organizing a file with a date in the file name.

 

 

So you're saying in all other cases you do not see this issue?

Link to comment
Share on other sites

Great, so I guess despite the uprising this issue is fixed after all :) Auto-organization of files by date is a new thing that was only introduced recently. I will look at that separately.

  • Like 1
Link to comment
Share on other sites

Redshirt

I do use auto-organize and here's an episode that just hit my library 10 minutes ago being processed by auto-organize. The nfo and thumb image show the correct time, but the media file shows the incorrect time. My timezone is UTC -8 which means the programs air-time (6pm) is being used rather than the time the media actually hit my library.

 

56bab2e479d4a_agentcarter.png

Link to comment
Share on other sites

DrWatson

I think auto org is a red herring this was added 30 mins ago not using auto org.

 

 

 

post-1492-0-61030500-1455077153_thumb.jpg

 

EDIT:

 

It appears the touch on the file is by sonarr - am am not sure if it is relevant or not

 

so sonarr changes the file time to the original date and time that the show aired - irrelevant of local time

 

emby nfo says <dateadded>2016-02-09 20:00:00</dateadded>

 

original air date is 09-02-12 (local time where the show aired)

 

emby nfo says <aired>2016-02-08</aired>  if it was local time it should be <aired>2016-02-10</aired> if it was airtime is should be <aired>2016-02-09 </aired> if it was utc it should be <aired>2016-02-10</aired>

 

webclient says 

 

post-1492-0-73287400-1455078828_thumb.jpg

 

i have since removed the option in sonarr to change the time to orig air time but emby is still calculating the date incorrectly

Edited by DrWatson
Link to comment
Share on other sites

Redshirt

Ignore my earlier comment. I was trying to be helpful earlier but clearly I haven't a clue what's going on.

 

Even though the timestamps on the files are weird, the added dates are correct in my .nfo files. 

Link to comment
Share on other sites

I do use auto-organize and here's an episode that just hit my library 10 minutes ago being processed by auto-organize. The nfo and thumb image show the correct time, but the media file shows the incorrect time. My timezone is UTC -8 which means the programs air-time (6pm) is being used rather than the time the media actually hit my library.

 

56bab2e479d4a_agentcarter.png

 

Are you talking about media file in the file system or in the emby UI? We actually don't to anything with the timestamps on the media file. whatever timestamp it had when you originally got the file should still be there

Link to comment
Share on other sites

Redshirt

Are you talking about media file in the file system or in the emby UI? We actually don't to anything with the timestamps on the media file. whatever timestamp it had when you originally got the file should still be there

 

Yep I realized that right above your post. For me the date inside Emby generated nfo's are correct, but I do live in the timezone the shows air in. So ignore me, I'm just adding misinformation to the issue. 

Link to comment
Share on other sites

DrWatson

Tbh I couldn't care less about the prem date being wrong what I hate most is the missing ep showing as missing before they even air - and I suspect that the 2 things are related.

Link to comment
Share on other sites

kjp4756

I've been having this date problem since I started using emby last February.  All shows in upcoming show as being a day earlier.  I'm using the freebsd version of emby.  I have tried several clean installs.  I have tried using NFO files (I normally do not use them).  I have tried changing the timezone on my jail to UTC time and also to my timezone (UTC-6).  No matter what I try the date is always 1 day early.  I make sure to refresh the whole library after each thing I try.  I do not use auto-organize.

 

I can reproduce this every time by doing:

 

1. Install a new instance of the FreeNAS emby plugin

2. Map media dataset to newly created jail for emby plugin at /media

3. In emby setup wizard add a TV series library pointing to /media/TV

4. Finish the wizard

5. Refresh newly created library

6. Check out upcoming tab and see how all shows are a day off

 

I also run sonarr in a separate jail which has a similar upcoming function as emby and it works correctly using data from thetvdb.  Sonarr is also mono based.

 

I have done lots of testing on this issue over the last few months.  I get the same behavior using emby server for windows.  

Link to comment
Share on other sites

kjp4756

Will do.  I was a little confused on how that should be because the init script for the freebsd port forces emby to UTC time rather than local time. 

 

UPDATE: Removed the TZ variable from the emby init script and refreshed my TV series.  Date is correct now.  

Edited by kjp4756
Link to comment
Share on other sites

  • 2 weeks later...

Any update on the auto-organization of files by date issue?

Tested today but still need to set my timeline to -5 Eastern Time VS and Canada tot get the job done well.

Link to comment
Share on other sites

  • 1 month later...
heula

haven't gotten to it yet. a good way to help get auto-organize more attention would be to participate with this

 

http://emby.media/community/index.php?/topic/31502-305891-auto-organize-smart-matching/

This smart macthing does not help with this issue. I still need to set my time-line to -5 to get it working properly. Please take a look into this and fix it. We have been waiting long enough now.

Thanks.

Link to comment
Share on other sites

I investigated this issue today and was able to reproduce.

 

The problem is also related to this issue: http://emby.media/community/index.php?/topic/33295-auto-organizedaily-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/MediaBrowser/Emby/pull/1616

  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...
paulsalter

Is there anyway to set the timezone for Emby separately to my PC time, not sure if there is something in a config file i can change, but would like to get Emby to think I am on GMT again instead of BST (Only 1 hour difference so i can live with that)

 

This issue is also affecting weekly UK shows I record which never seem to have a Season/Episode and just go by date, so a show last night had a date of 11th April, but the matching tried to match it as 12th which the show didn't air on so it failed to do anything with it 

 

Thanks

Link to comment
Share on other sites

Is there anyway to set the timezone for Emby separately to my PC time, not sure if there is something in a config file i can change, but would like to get Emby to think I am on GMT again instead of BST (Only 1 hour difference so i can live with that)

 

This issue is also affecting weekly UK shows I record which never seem to have a Season/Episode and just go by date, so a show last night had a date of 11th April, but the matching tried to match it as 12th which the show didn't air on so it failed to do anything with it 

 

Thanks

 

This is not a good solution as it would probably cause lots of other problems.

 

It needs to be fixed in the server. Hope @@Luke will do it soon...

Link to comment
Share on other sites

paulsalter

Thanks for the info

 

Just trying to think of a workaround until this gets resolved

 

As I am on GMT+1 now, i could live with all times being GMT, if it fixed the auto organise for daily shows issue

 

Manually have to go in and rename files daily is getting a bit of a pain

 

Thanks again for info

Link to comment
Share on other sites

Thanks for the info

 

Just trying to think of a workaround until this gets resolved

 

As I am on GMT+1 now, i could live with all times being GMT, if it fixed the auto organise for daily shows issue

 

Manually have to go in and rename files daily is getting a bit of a pain

 

Thanks again for info

 

Another instant solution - if you're not afraid of building from source code:

 

https://github.com/softworkz/Emby/tree/AutoOrganizeLiveUpdate

 

This forked branch aready contains the fix..

Link to comment
Share on other sites

  • 1 month later...

i have an idea of what i want to do, i just haven't gotten to it yet.

  • Like 1
Link to comment
Share on other sites

  • 2 months later...
heula

i have an idea of what i want to do, i just haven't gotten to it yet.

Tried once more after 2,5 months and still the issue is there and not fixed. I hope you find the time to do your idea soon.

 

Thanks again.

Link to comment
Share on other sites

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...