Loosing playlist items when wipeing, sorting and readding items

[ginjaninja 537]

I have a playlist with 1500 items,

I have some code which, takes all playlistitems in a  playlist, wipes the playlist and then readds items in a preferred sorted order.

 

So as to not exceed the maximum URI length when posting to /Playlists/{Id}/Items

i chunk the ids into sets of 100.

Despite all posts for all chunks returning "204", sometimes a chunk is not committed or to put it another way,

i remove 15x100 items chunks (always works)

i add 15x100 items chunks (and randomly 1 chunk will not be committed, often the 2nd or 3rd chunk) and the playlist ends up as 1400 items.

the solution is to put a 1s wait timer between each chunk post - then no problem.

 

Because it works with the wait state, my initial conclusion is that the problem is not with my code but with the api?

Are there considerations to be aware of when posting large amounts to the api and/or  adding large amounts of items to a playlist?

thanks

 

[PenkethBoy 2063]

i raised the same issue over a year ago - and its related to the api not "caching" api calls - usually not a problem but when the call takes a lot of "work" you have to put in a delay or things go missing. Dev's said this was not possible even though it is very reproducable etc etc

 

[ginjaninja 537]

17 hours ago, PenkethBoy said:

i raised the same issue over a year ago - and its related to the api not "caching" api calls - usually not a problem but when the call takes a lot of "work" you have to put in a delay or things go missing. Dev's said this was not possible even though it is very reproducable etc etc

 

thanks, good to know a delay is sometimes necessary and im probably not doing something wrong

[Luke 37093]

It's not that you need an arbitrary delay, it's that you're probably sending requests without waiting for them to complete before moving onto the next one.

[ginjaninja 537]

1 hour ago, Luke said:

It's not that you need an arbitrary delay, it's that you're probably sending requests without waiting for them to complete before moving onto the next one.

thanks. i am using powershell invoke-webrequest to post. i believe powershell is executing posts in series and getting a 204 response before the next post; im not sure what else i can do to enforce synchronous behaviour. beyond doing a 'get' after each post to confirm commitment. is thats whats necessary do you think? or am i looking for  something in the post method to force wait for conmitment.

[PenkethBoy 2063]

if you get a 204 retuned - then you should not need to wait - as the server has replied - implying i'm ready for the next request