search

Kiina / MMM-trakt

A MagicMirror Module to show your upcoming tv shows from trakt.tv
MIT License
14 stars 2 forks source link

Showing shows only from yesterday? #14

Closed dxfan227 closed 5 years ago

dxfan227 commented 5 years ago

When I log in to trakt my upcoming calander is correct... but in the module all the shows are dated from yesterday....

Kiina commented 5 years ago

Is the time on your host set correctly? Can you quickly make a test.js file in the MMM-trakt folder with 

const moment = require("moment");

console.log(moment());

run it via node and see if the time reported there is different from the host or your time?

dxfan227 commented 5 years ago

Ok so I ran the command node test.js and it returns

moment("2019-04-20T21:06:30.420"). which is todays date( but the wrong time is now 9:07 PM vs 6:30)

dxfan227 commented 5 years ago

just thought I would bump this topic to see if you had any further ideas?

dxfan227 commented 5 years ago

something strange I noticed. If I make days "2". it shows the same shows as yesterday and then the proper day 2 shows......

so If today is Monday days set 1: shows Sunday Days Set 2: shows Sunday + Tuesday

could really use some help

Kiina commented 5 years ago

Oh sorry, didn't get a notification about the edit. Not sure if there is something broken with the trakt api. That moment returns a wrong time is weird (have you hosted it on a raspberry pi? It doesn't have a hardware clock, but I think it should get the time via ntpd), but as long as the date is correct it should fetch it correctly. Have you checked the settings in https://trakt.tv/settings#datetime? I tried different stuff, but it always mirrors the results from the trakt.tv website for me.

dxfan227 commented 5 years ago

So strange. Do you think if it was the api then it would affect all users?

My system clock is correct as well as the clock module and calander module in magic mirror. I tried reinstalling from scratch but still same issue.

Sent from my iPhone

On Apr 24, 2019, at 10:18 AM, Kiina notifications@github.com wrote:

Oh sorry, didn't get a notification about the edit. Not sure if there is something broken with the trakt api. That moment returns a wrong time is weird (have you hosted it on a raspberry pi? It doesn't have a hardware clock, but I think it should get the time via ntpd), but as long as the date is correct it should fetch it correctly. Have you checked the settings in https://trakt.tv/settings#datetime? I tried different stuff, but it always mirrors the results from the trakt.tv website for me.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

dxfan227 commented 5 years ago

So i posted over at the trakt api git and here was the response I got from them. Does this make sense to you? Is there anything in your code that accounts for the difference from UTC to the users local timezone?

So I spent a little while/a few iterations working this out, but my previous comment covers the general solution. As a broken down example to explain, check out the /calendars/all/shows endpoint.

The first result will generally have a first_aired timestamp of something like 2019-04-26T00:00:00.000Z, where the 00:00:00.000Z is 00:00 UTC because the date used for the results is in UTC (as with like 99% of the dates you send/receive using the API).

So if your local Timezone is something other than UTC (GMT+0), you need to account for that offset when converting your expected start date to UTC and using that as your start_date, and using the days parameter to make up the difference of the offset in order to pick up anything outside the offsets.

Using 26 April 2019 as an example day: If your Timezone is GMT+10, you’ll want to use pretty much the day before, as 2019-04-26 00:00 GMT+10 is 2019-04-25 14:00 GMT+0. So the start_date parameter you want is 2019-04-25. However because that will return results from 2019-04-25 00:00 to 23:59 GMT+0, you also need to add one day in total in order to receive up to 2019-04-26 14:00 GMT+0, so the days parameter you want is 2. Meaning your endpoint is /calendars/all/shows/2019-04-25/2.

Now, you’ll receive items from 2019-04-25 00:00 GMT+0 to 2019-04-26 23:59 GMT+0. This means in order to get only the items from those results that fall within your original start/end date (2019-04-26 00:00 to 23:59 GMT+10), you need to filter out all the items outside those times.

For a negative GMT (eg. GMT-8), you do the same, pretty much (logic is exactly the same), but for the sake of the example, you’re going the other way (basically, start_date is 2019-04-26 and still using days parameter of 2 to make up the difference, seeing as 2019-04-26 00:00 GMT-8 is 2019-04-26 08:00 GMT+0 meaning you need to get up to 2019-04-27 08:00 GMT+0. You should end up with items between 2019-04-26 00:00 GMT+0 and 2019-04-27 23:59 GMT+0. Once again you’re going to need to filter out anything outside 2019-04-26 00:00 to 23:59 GMT-8.

I’m unsure if I can explain it any better than that heh. The important thing is that the dates you use for the endpoint are in UTC, hence why for GMT+10 you’re technically using the day before through to the day you’re in, and for GMT-8 you’re using the day you’re in through to the next day. This would be why you’re seeing somewhat “correct” results when using tomorrow’s date and seeing some of tomorrow’s results, but you’ll find it’s also including some of the day before/after as well due to the UTC logic. Using the all endpoint is likely the best way to test as it should have items ranging from 00:00 to 23:59 in any time zone (although also has a lot of items for each request lol).

Kiina commented 5 years ago

Oh, yeah, I think i've found my thinking error. Will push an update in the next few days

dxfan227 commented 5 years ago

THANK YOU. I hope it will solve my issues. I love your module ( it my fav one on my mirror) I just want it to work lol.

Sent from my iPhone

On Apr 26, 2019, at 1:42 PM, Kiina notifications@github.com wrote:

Oh, yeah, I think i've found my thinking error. Will push an update in the next few days

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

Kiina commented 5 years ago

Can you try the latest commit and see if it works? It's kinda hard to test different time zones for such a module.

dxfan227 commented 5 years ago

Sure I will. Do I just navigate to my modules folder and type “git pull”

Sent from my iPhone

On Apr 28, 2019, at 6:49 AM, Kiina notifications@github.com wrote:

Can you try the latest commit and see if it works? It's kinda hard to test different time zones for such a module.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

Kiina commented 5 years ago

Yes

2019년 4월 28일 (일) 21:12, dxfan227 notifications@github.com님이 작성:

Sure I will. Do I just navigate to my modules folder and type “git pull”

Sent from my iPhone

On Apr 28, 2019, at 6:49 AM, Kiina notifications@github.com wrote:

Can you try the latest commit and see if it works? It's kinda hard to test different time zones for such a module.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Kiina/MMM-trakt/issues/14#issuecomment-487407248, or mute the thread https://github.com/notifications/unsubscribe-auth/AASOXB2CDOV2DSPS2Q74Z4DPSXZIRANCNFSM4HHBXGVA .

dxfan227 commented 5 years ago

I updated via git pull. Unfortunately I still have the same issue, it's showing yesterdays shows.

I also tried to create a new applications with new keys, and deleted the token file....still pulling yesterdays shows. sigh

Kiina commented 5 years ago

Yeah, nvm I broke it. I need to implement some deeper logic to account for the timezone

Kiina commented 5 years ago

Can you try the commit on the devel branch? It broke the days variable for now, but it should display the correct data for today if I'm not crazy.

dxfan227 commented 5 years ago

Sure, what’s the command to pull that branch instead of master ?

Sent from my iPhone

On Apr 28, 2019, at 5:17 PM, Kiina notifications@github.com wrote:

Can you try the commit on the devel branch? It broke the days variable for now, but it should display the correct data for today if I'm not crazy.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

Kiina commented 5 years ago

git pull origin devel should work

dxfan227 commented 5 years ago

Ok give me about 1 hour to get back home.

Sent from my iPhone

On Apr 28, 2019, at 5:17 PM, Kiina notifications@github.com wrote:

Can you try the commit on the devel branch? It broke the days variable for now, but it should display the correct data for today if I'm not crazy.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

dxfan227 commented 5 years ago

@Kiina

things seem to be in working order. I'll keep an eye on it for the next few days and let you know how it performs.

Is there anything else I need to do on my end, is it ok to just stay on the devel branch?

Thank you so much for your help with this, it was the final touch to my mirror and honestly the most important one! so I appreciate it.

Kiina commented 5 years ago

I will clean up the code a bit so the days variable works again and everything looks a bit better and then push that to master. You can probably stay on devel if you want, but further big updates and fixes will go on the master branch. In case there are any other problems feel free to comment.