starred/audiobookshelf
1
0
Fork 0
mirror of https://github.com/advplyr/audiobookshelf.git synced 2026-05-30 23:40:40 +02:00
Code Issues 1.0k Packages Projects Releases 10 Wiki Activity

[Bug]: API ignores startedAt parameter and always sets it to current time #3174

New Issue
Closed
opened 2026-04-25 00:14:04 +02:00 by adam · 8 comments
adam commented 2026-04-25 00:14:04 +02:00
Owner
Copy Link
Copy Source

Originally created by @jmswangit on GitHub (Jan 3, 2026).

What happened?

I'm trying to set historical listen dates for some books using the API, but the startedAt parameter keeps getting ignored. No matter what timestamp I send, it always gets set to the current time instead.

I've tried both the single item endpoint (PATCH /api/me/progress/{libraryItemId}) and the batch endpoint (PATCH /api/me/progress/batch/update), and both have the same issue. The finishedAt value works fine though.

What did you expect to happen?

I expected the API to use the startedAt value I'm sending in the request. The docs say that when isFinished is true, startedAt should default to finishedAt if not provided, but I'm explicitly providing it, so it should use my value.

Steps to reproduce the issue

  1. Send a PATCH request with a historical startedAt:
curl -X PATCH "https://abs.example.com/api/me/progress/li_example" \
  -H "Authorization: Bearer TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "startedAt": 1667307600000,
    "finishedAt": 1667322000000,
    "isFinished": true,
    "progress": 1
  }'
  1. Check what actually got stored - startedAt will be today's timestamp, not the one you sent.

Audiobookshelf version

v2.31.0

How are you running audiobookshelf?

Docker

What OS is your Audiobookshelf server hosted from?

Linux

If the issue is being seen in the UI, what browsers are you seeing the problem on?

None

Logs

Additional Notes

No response

Originally created by @jmswangit on GitHub (Jan 3, 2026). ### What happened? I'm trying to set historical listen dates for some books using the API, but the `startedAt` parameter keeps getting ignored. No matter what timestamp I send, it always gets set to the current time instead. I've tried both the single item endpoint (`PATCH /api/me/progress/{libraryItemId}`) and the batch endpoint (`PATCH /api/me/progress/batch/update`), and both have the same issue. The `finishedAt` value works fine though. ### What did you expect to happen? I expected the API to use the `startedAt` value I'm sending in the request. The docs say that when `isFinished` is true, `startedAt` should default to `finishedAt` if not provided, but I'm explicitly providing it, so it should use my value. ### Steps to reproduce the issue 1. Send a PATCH request with a historical `startedAt`: ```bash curl -X PATCH "https://abs.example.com/api/me/progress/li_example" \ -H "Authorization: Bearer TOKEN" \ -H "Content-Type: application/json" \ -d '{ "startedAt": 1667307600000, "finishedAt": 1667322000000, "isFinished": true, "progress": 1 }' ``` 2. Check what actually got stored - `startedAt` will be today's timestamp, not the one you sent. ### Audiobookshelf version v2.31.0 ### How are you running audiobookshelf? Docker ### What OS is your Audiobookshelf server hosted from? Linux ### If the issue is being seen in the UI, what browsers are you seeing the problem on? None ### Logs ```shell ``` ### Additional Notes _No response_
adam added the bug label 2026-04-25 00:14:04 +02:00
adam closed this issue 2026-04-25 00:14:04 +02:00
adam commented 2026-04-25 00:14:04 +02:00
Author
Owner
Copy Link
Copy Source

@Vito0912 commented on GitHub (Jan 3, 2026):

Do the books already have a progress attached ?

@Vito0912 commented on GitHub (Jan 3, 2026): Do the books already have a progress attached ?
adam commented 2026-04-25 00:14:04 +02:00
Author
Owner
Copy Link
Copy Source

@jmswangit commented on GitHub (Jan 3, 2026):

@Vito0912 I was attempting to adjust your https://github.com/Vito0912/absToolbox/blob/main/web/src/features/tools/listenDateUpdater.ts tool to allow for startedAt but, like you've mentioned before, the API doesn't respond to the startedAt parameter, but it's listed in the docs here update media progress (which I realize are outdated, but it's a feature that should exist and seemingly used to, so I wanted to report the bug.

@jmswangit commented on GitHub (Jan 3, 2026): @Vito0912 I was attempting to adjust your https://github.com/Vito0912/absToolbox/blob/main/web/src/features/tools/listenDateUpdater.ts tool to allow for startedAt but, like you've mentioned before, the API doesn't respond to the startedAt parameter, but it's listed in the docs here [update media progress](https://api.audiobookshelf.org/#create-update-media-progress) (which I realize are outdated, but it's a feature that should exist and seemingly used to, so I wanted to report the bug.
adam commented 2026-04-25 00:14:05 +02:00
Author
Owner
Copy Link
Copy Source

@Vito0912 commented on GitHub (Jan 3, 2026):

Iirc it works if the book has no progress currently attached. Have you tried this?

@Vito0912 commented on GitHub (Jan 3, 2026): Iirc it works if the book has no progress currently attached. Have you tried this?
adam commented 2026-04-25 00:14:05 +02:00
Author
Owner
Copy Link
Copy Source

@nichwall commented on GitHub (Jan 3, 2026):

The API docs are several years out of date. Does this PR address the issue? I'd have to look at it again, but I think you want createdAt

https://github.com/advplyr/audiobookshelf/pull/3546

@nichwall commented on GitHub (Jan 3, 2026): The API docs are several years out of date. Does this PR address the issue? I'd have to look at it again, but I think you want `createdAt` https://github.com/advplyr/audiobookshelf/pull/3546
adam commented 2026-04-25 00:14:05 +02:00
Author
Owner
Copy Link
Copy Source

@Vito0912 commented on GitHub (Jan 3, 2026):

Ah yeah. Did overlook that (wrong payload).
But also as that PR states it only works with books that have no progress.
I could update my ToolBox (and I did know about this for a while), but was too lazy to add this and never actually tried it.

Imho it's also not a bug, because you cannot change the date is started after you started something. It's not convenient (which why I also stated that it did not work at all), but it makes sense from a API standpoint

@Vito0912 commented on GitHub (Jan 3, 2026): Ah yeah. Did overlook that (wrong payload). But also as that PR states it only works with books that have no progress. I could update my ToolBox (and I did know about this for a while), but was too lazy to add this and never actually tried it. Imho it's also not a bug, because you cannot change the date is started after you started something. It's not convenient (which why I also stated that it did not work at all), but it makes sense from a API standpoint
adam commented 2026-04-25 00:14:05 +02:00
Author
Owner
Copy Link
Copy Source

@jmswangit commented on GitHub (Jan 3, 2026):

@nichwall createdAt works perfectly! Wow thanks!
@Vito0912 wouldn't it be as simple as asking for both start and finish dates in your tool and deleting the existing progress then replacing it with the new values?

Gonna go ahead and close this one since createdAt works like a charm.

@jmswangit commented on GitHub (Jan 3, 2026): @nichwall createdAt works perfectly! Wow thanks! @Vito0912 wouldn't it be as simple as asking for both start and finish dates in your tool and deleting the existing progress then replacing it with the new values? Gonna go ahead and close this one since createdAt works like a charm.
adam commented 2026-04-25 00:14:05 +02:00
Author
Owner
Copy Link
Copy Source

@Vito0912 commented on GitHub (Jan 3, 2026):

Yeah exactly. It would be as simple as that. I just found out after posting my comment under that issue and had no motivation to fix it the tbh.
Most tools I use myself. This is not one of them, because it does not really change the stats.

If you want to open a PR I can ofc merge it (Toolbox)

@Vito0912 commented on GitHub (Jan 3, 2026): Yeah exactly. It would be as simple as that. I just found out after posting my comment under that issue and had no motivation to fix it the tbh. Most tools I use myself. This is not one of them, because it does not really change the stats. If you want to open a PR I can ofc merge it (Toolbox)
adam commented 2026-04-25 00:14:06 +02:00
Author
Owner
Copy Link
Copy Source

@jmswangit commented on GitHub (Jan 3, 2026):

@Vito0912 Just submitted a PR. Tested it on my end. Added the UTC date parsing because it was setting the date to a day behind each time. There might be a better way to handle that, but that's entirely up to you. Other than that, it's pretty much exactly what we spoke about.

@jmswangit commented on GitHub (Jan 3, 2026): @Vito0912 Just submitted a PR. Tested it on my end. Added the UTC date parsing because it was setting the date to a day behind each time. There might be a better way to handle that, but that's entirely up to you. Other than that, it's pretty much exactly what we spoke about.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
authentication
backlog
bug
chapter editor
config-issue
ebooks
encoding/embedding
enhancement
help wanted
listening sessions & progress
planned
possible plugin
progress sync
pull-request
Mirrored from GitHub Pull Request
 sorting/filtering/searching
unable to reproduce
upload
users & permissions
waiting
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam (Adam Melkus)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/audiobookshelf#3174
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?