get_history api - started timestamp wrong when playing completed #112
Comments
I am trying to replicate. Does it have to be a new item? Edit: Meaning does it have to be media that has never been played in the past? |
I actually reproduced it with a non-new item, but seems that this happens randomly, for a lot of items I get correct timestamps (testing with tracks). |
Interesting... that is why the few times I tried it seemed to work just fine. |
This is what I get for example:
I'll have an eye on that to find out how to reproduce it. |
I was able to reproduce. I think it maybe specific to Music.
|
@tfonfara If you turn off "Group Play History" in Settings --> General. Do you still see the issue? |
@samwiseg00 nope, when turned off the timestamp is correct (even for previously wrong timestamps) |
After looking into it. It's not a bug but by design. What you are seeing is the start time of the first grouped item. With grouping enabled it will display the start item of the first history item. You can disable grouping by adding https://github.com/Tautulli/Tautulli/blob/master/API.md#get_history |
Got it, thanks! |
Version: v2.1.18-beta
Branch: beta
Commit hash: a8a676b79496b4dc3dea9596dfd09a4eeeae60e0
Operating system: Linux 4.15.0-24-generic
Python version: 2.7.14 (default, Dec 14 2017, 15:51:29) [GCC 6.4.0]
What you did? Called
get_history
api as shown in the api docs while item is playing, wait until playing completes (or next entry in list starts) and call api againWhat happened?
started
timstamp is correct while playing, but jumps ~1 month into past after playing completedWhat you expected? Started timestamp shouldn't change
How can we reproduce your issue? See above.
The text was updated successfully, but these errors were encountered: