Please provide a few examples so I can take a look. We get air dates from TVDB, so my guess is either the date is incorrect over there, or the episode aired earlier on its original network.
You're on windows I assume? These rules are intended to target tablets and other devices that don't render scrollbars. I'll have to see how to hide them on windows somehow.
What is the exact resolution? I'm not able to reproduce the issue so far.
Both exist on TVDB. One will need to be removed there first before I can remove it from Trakt.
FYI, I pushed an update so we can manually set per season Networks. For example, Black Mirror and Supergirl have this data now.
I looked into this a bit more and I think for step 1 we can start saving a per season Network. As I mentioned, this will require manual data entry on our side, but we can update it for the more popular shows or by new support tickets pretty easily. This will at least make the season and episode pages more accurately reflect the original network the show aired on.
The next step would be looking into the episode air dates themselves and see if there is an automated solution we can reliably implement.
I agree it is a good suggestion to use the first time it airs, even if it is across networks.
Currently, we don't store a network per season and TMDB/TVDB don't include that info either. Maybe we can start doing this, but have it would manual data entry.
As for the episode dates, I wonder if its reliable enough to use the earliest date between TVDB and TMDB. That might cause unforeseen issues if we just start doing that, but I'm not certain.
All good ideas. We need to re-architect some things behind the scenes in order to boost performance to do things related to your network activity.
Currently, only plays are shown in this area. It doesn't include collected items or anything else currently, which is part of the performance issues. In v1, there were way fewer users so all these actions could be queried direct against the database. We now have so many users that is needs to be cached in other ways as to avoid direct data access.
I really like the idea of user independent data, which could aggregate and give you very useful stuff. Things like over the past week, the most watched show and movie from your friends was X and Y. That would actually be very cool along with other stats too.
Before any of this though, we need to do some behind the scenes updates so the recent activity can be accessed quickly. It has been on my task list, so hopefully some time can open up in the near future to start planning those backend updates.
I found a bug with the initial image importing, so I'll have a fix out for that later this week. I'm not sure why "Chinese Midnight Express II" didn't import correctly. I tried it manually and it was ok in my testing environment. I wonder if it failed to grab the movie info from TMDB for some reason. After it grabs the "changes" it then would get specific info for each movie.
We run the update at 08:30 UTC each day, but have it go back to the previous day for the start date to get updates from. So that exceeds the 8 hours and should include any new items as well. I'm not sure why they wouldn't be picked up correctly.
Not currently planned, but will add to researching.
This is similar to some other suggestions in the past about not requiring a date when entering your watched data. It's not something we currently have planned since the entire site is largely based around dates. Without dates, it would change or make a lot of the stats not function with how they are setup.
I agree using "release date" is not a perfect option, but attaching no date would require an overhaul of how stats are presented throughout the entire website. We'd also need to figure out how to handle this via the Trakt API and the many apps that use that data. Long story short, we still would need a date attached at some level for the API to function correctly as well.
I know if doesn't fully solve your issue, but we currently have these features to help:
- choose a default watched action (new signups default to today's date)
- release date can help approximate when you watched older items
- hide the date breaks when viewing your watched history and other sections
- sort your watched history by other non date related options
Will need to look into this more and see if its possible with the way we currently have these sections setup.
How would this be different than the "recently aired" option? The progress page will sort using the next episode you need to watch and not the next episode to air in general for the show. Does that make sense?
I'm still thinking about this and what the best approach is. I do like handling planned/rumored movies differently somehow, possible just ignore any release dates for movies in that status?
I guess one concern is if a valid and released movie might still have one of those statuses on TMDB. Looking in Trakt's database, I see quite a few movies in that state. They are clearly released, but have a status of rumored or planned still. Some might be stale data on Trakt, but others I'm sure are in this incorrect state still.
The reason it is currently one page is all the filters and sorting are applied client side in the browser. Pagination would break that. I'll have to think about this more and see if there is another alternative.
Not sure this helps, but there are direct links to "pre filter" your watchlist for a specific type of content.
Here's an article that explains all about social sharing: https://blog.trakt.tv/share-on-your-social-networks-3a5cd188772
In regards to the check in text, we unfortunately don't store that. It is only used when sharing with your connected networks. The main problem is in order to save that text, it requires a major backend update, due to how plays are stored. I like the idea, but it unfortunately is not a top priority because of this infrastructure change. When I last commented on this issue, we had plans to change how plays are stored on the backend, but we didn't proceed with that system and thus don't have the flexibility to store additional fields, such as the check in text. I can't say we'll never do it, but its not really possible right now.
As for sharing, we only share scrobbles and checkins and not previous watches. The reason being that previous watches are typically added in bulk and we don't want to spam your social networks if you add a whole bunch of content in a short amount of time. Since checkins and scrobbles are real time, they generate a lot less volume and don't spam your networks nearly as much.
This will actually be a new feature, we don't currently save the text for checkins. (we didn't in v1 either actually). That text is used when sharing to your social networks. We're currently in the process of optimizing the history activities, so once we're done with that I'll be able to better look into the original idea of saving the check in text for display on the website. For the location part, I plan to save that as separate from any note that is entered.
As for the task list, this uservoice board is what we have that is public facing. The different statues like "planned", "started", etc are how we keep track of that. If we have a more exact time frame, we try to indicate that. For the most part, things in "started" are tasks that are being worked on or will be once a some other tasks fall into place.
Thanks for the suggestion! I think some of it makes sense and some of it would break conventions a bit too much. The hover icons + dimmed screenshots might be a little confusing since that is different from all the other views. I'll plan to look into this more for a future update though and see if there is an opportunity for a new view.
Those errors seem related to the ad loading, so it shouldn't affect the image loading that I know of. I still haven't been able to reproduce or find a fix for this issue yet.
Weird error. I'm not able to reproduce it so far, using Chrome as my primary test case. Do you have any browser plugins installed? I'm wondering if there is a conflict that is affecting the image loading plugin. Basically, images should fade in when scrolled into view, but initially it should of course load the visible ones.
Need to figure out how to do this while also retaining the client side sorting and filtering if possible.
Agreed, this is an issue with large lists. The problem is the sorting and filtering is handled client side, so pagination will lose that functionality. It is all done client side for performance reasons currently.
I think this is somehow related to the ads on the page, it seems like that is introducing a bug with the search bar. Not sure of a fix yet.
I'm not able to reproduce the issue on Firefox 53.0 on MacOS. This was tested with a non VIP account just to see if it was an issue with any advertising, but that doesn't seem to be the case. I'm not sure what is different with your Firefox.
Have you tried disabling any Firefox extensions to make sure one isn't breaking the long press? Are there are errors in the browser console?
Please provide some examples for reference.
You are referring to the global sections like trakt.tv/movies/popular? Do you have any design inspiration for ideas on what they could look like?
Currently, you can hide a show from you calendar or progress page. Hiding from watched progress also hides it from your dashboard on deck. Hiding in those 2 places should work for most users.
This topic proposes a “dropped” status for a show. This would hide from the 3 sections mentioned above + add a “dropped” indicator in places such as the show summary page.
To recap my previous replies, you can hide shows by clicking the Ø icon when viewing your dashboard up next, progress page, or calendar. There is no need to unwatch the items. You can unhide from trakt.tv/settings/hidden if needed too.
@Vicky we expose the hidden items for apps and plugins to use, but it sounds like whichever you are using might not use that data to hide within their app. I would recommend sending a feature request to the app developer.
Please provide your username so I can check if the items are correctly hidden. And also please send screenshots of the dashboard on deck and the collection progress so I can see if they line up correctly.
Do you see all the hidden shows listed at trakt.tv/settings/hidden? As I see it, the issue seems to be with the hiding either not working properly or not saving when you click the Ø icon to hide.
@Anonymous did you hide the show from your progress page? That removes it from your on deck as well. The watchlist is a special list for what you want to watch, so adding/removing to that shouldn't affect the progress or calendar.
@Anonymous you can hide the show from your progress page which will also hide it from your dashboard on deck. No need to mark it as 100% watched.
Liam, you can ignore seasons from the progress page as well. Just expand the percentage view, and there will be Ø icons next to each season as well.
Alan & Roxie, I'm not able to reproduce the issue. I just tested and was able to hide a show from my watched progress and it correctly hid from my on deck as well. If you have more info (i.e. browser errors, etc) please let me know. Can you confirm the show is actually hidden from the progress page too?
For the more recent comments, please be aware you can hide show from your calendar and progress pages directly to hide them from showing up. When hiding from your watched progress, this will also hide them from your on deck section.
I agree adult movies should be hidden, but I'd like to always hide them and not have an option since we prefer not to have that content at all. I'll need to look into this more and see if the TMDB tags are reliable enough to do something automated or not.
Trakt itself does refresh very quickly. The 8 hours can come in to play from the data we receive from TMDB or TVDB if it was updated right before trying to refresh on Trakt.
The main thing is changes on TMDB and TVDB aren't instant. It usually takes up to 8 hours for the data to be updated so an immediate refresh on Trakt won't necessarily grab the updated info. That's part of the reason its not a general feature since it could be confusing as to why the data didn't immediately update.