No, now that you've corroborated this, I figure it's a bug & since this is tagged with Support we should hear something.
Playlist - Watch later. Maximum reached?
- Edited
It's funny... I just tried to reduce my 'watch later'-category today and move some off into other playlists, but for me it's only in the browser (I don't login on the DeoVR/SLR app). But can confirm, I too had the same issues.
At some point you just get a server 500 error even though there should be more pages left. For me sometimes page 47, sometimes page 48 would be the last working page. Even though when counting the total result in the json array (from the getList result, webdev will understand) I should have had 62 pages of 24 scenes per page. Deleting/moving scenes from the playlist kept filling up page 47/48 until I had reduced it enough to go under that 47/48 pages limit...
It's really weird page 47/48 is not where it breaks for everyone but it seems is different for each person...? I figured something was fucky with the pagination code as it's easy to go wrong with that but this is all very odd.
I thought it might be a thing with hidden scenes from studios that are gone (VRBangers, VRConk, etc) as those are counted and shown in the playlists, but perhaps some part of the pagination code wants to not-count them and causes a server 500 error? Then again I moved all of those into a new 'wtf-deleted' playlist with 5 pages and the pagination for that works fine so... dunno. (Plz don't hide them from playlists as well btw, that'd be worse imo
).
---Edit: Just tested adding more than 24 "hidden" scenes to watch later playlist and it didn't cause any issues with displaying another full page of that, so maybe that's not what is causing it then... I dunno, it's weird.
Seems to me some bug got introduced in the Watch Later functionality and when it got introduced is when the number of pages stopped increasing. So it is a different number for everyone.
Thanks for informing, guys!
Can other confirm this only happens in desktop browser, and not in the SLR app?
At some point you just get a server 500 error even though there should be more pages left. For me sometimes page 47, sometimes page 48 would be the last working page.
We've fixed this so many times. Keeps coming back for some reason.
Rakly3
No this is happening in the app for me & I believe @xxxscottyxxx too based on his first post.
- Edited
Rakly3 Its happening in both the SLR app and also the DEO Player for me, I havent looked on the desktop.
- Edited
Mutiny Yeah that's how it works for me, anything I add doesnt show but its obviously saved because if i delete an old one a new one appears, if I delete two then two new ones appear etc to take it back up to my maximum (106 pages) so they are obviously saving in the background.
I think @imratore hit the nail on the head when he said the bug has appeared and set everyone's current page to their maximum and thats what we all have a different number of pages we are stuck on.
It looks like it's a known bug so hopefully it can get fixed pretty quickly
I remove scenes but it doesn't add the new ones. it also removed a couple pages of scenes at the end that I used to have access to. Like it minimized the number of scenes allowed from whatever it was before.
@Rakly3 Can you let us know if this issue is currently being looking into please and if there is a fix on the way. Thanks
xxxscottyxxx It's reported, it will get looked in to. But I don't manage the dev's work schedule 
Rakly3 Thanks for reporting it, I can put up with little bugs like the JAV toggle slider keep resetting as its just a mild annoyance but not being able to see your watch later scenes is quite a big deal and really does damage the experience, really hope they fix it soon!
5 days later
xxxscottyxxx I Have exactly the same problem :-(
fokton There now seems to be another issue, it will not let me add any titles to the watch later section at all now it just says 'you've reached the maximum number of titles you can add' it wasn't doing that before it was letting me add them but they wouldn't show up until other scenes were deleted but now it doesn't let me add them at all.
Pretty disappointing from SLR really, adding titles to a watch later section is pretty basic stuff and while I appreciate bugs do happen this looks to be effecting quite a few people and still no fix has been put in place, not good really.
xxxscottyxxx what seems basic usually has a lot of technical detail that goes into it. You canāt just have an infinitely large list of items being returned to the user. At some point you will reach threshold limits either in storage, logic, or display.
Sounds to me like some threshold was reached and a dev fixed the unfriendly 500 internal server error message with what always should have been a friendly message. āYou have exceeded your limit.ā At least there is a message now. In DeoVR there is 12 videos per page so your 106 pages of watch later videos is 1272 videos long. At an average of 1 hr per video thatās 7.5 weeks of viewing.
I know as users we all want āall the thingsā but boundaries must be set so bugs can be fixed in reasonable timeframes and focus isnāt diverted from important feature work.
- Edited
Sperson xxxscottyxxx what seems basic usually has a lot of technical detail that goes into it. You canāt just have an infinitely large list of items being returned to the user. At some point you will reach threshold limits either in storage, logic, or display.
You're right in principle, but I think that's unlikely in this case. So that an infinite list is not loaded, there is a pagination. With the help of the pagination, only a certain number of data records is queried from the database. This is not a very computationally intensive process.
From the technical principle, it shouldn't behave very differently from any other filtering of the data. If we take a tag like "brunette" as an example, we have almost 6000 videos in there. Here it also works without threshold limits.
Of course, I don't mean to say that this is all easy to develop. However, it must be said that a few thousand datasets should not pose a problem unless they have not been developed particularly efficiently in one place or another.
Without knowing the structure of the system in detail, I assume a classic system, which roughly consists of the following components:
- Database
- API server
- Clients (Vue website, apps)
In my estimation, one of the two, or even both problems could apply:
- Table with the data of the playlists (e.g. watch later) does not have an optimal structure and is therefore inefficient and slow.
- A Bug in the API Server Endpoint for querying playlist data.
But since none of us knows exactly how the whole thing is technically structured, it's only a guess in the end.
@ devteam: We wish you the best of luck in solving the problem.
- Edited
I do not think it is an issue of just reaching a limit.......in that case the solution would be to delete something from the list and just ad another scene. But when I delete something from the list and I try to ad an other scene I keep getting the same message....
Sperson Its obviously not just a threshold number that has been met...if you read the thread everyone that has reported the bug has a totally different number of pages (in a lot of cases wildly different numbers) so it's not even something such as a combined amount of data, the bug also hit everyone at exactly the same time so it is a bug and not something that's purposely programmed in.
You are right, something that may seem basic may involve a lot more work than I realise but one of the mods replied to me and admitted it was a bug that had already been fixed a few times so they must already have a good understanding of what causes it and how to fix it. There has been no sort of update from anyone at SLR to even let us know they are actively working on a fix or any sort of eta for a fix, we pay a lot of money for this service, surely this is not a lot to ask for in return.
xxxscottyxxx Hey, we are actively working on it as @Rakly3 mentioned, we apologize for your troubles.
xxxscottyxxx I read the entire thread. And yes I saw that it has happened before you found a regression (term for a bug that keeps showing up.). Just because it keeps showing up doesnāt mean itās exactly the same every time.
Also just because values are different it can still be a threshold issue. Maybe itās a bitmask, maybe itās a URL length, may be itās a character limit, maybe itās a file size limit. Maybe Iām way off, but given my previously extensive history doing software QA thatās what my gut feel is.
Now as a PM, had this been my product I would have looked at the issue, saw it was a regression, thrown it in the backlog, and fixed it when we were in that code again unless there was a quick and easy fix that plugged the regressions form reoccurring which would likely be the least common denominator scenario, made sure the metrics showed that fix covered 80-90% of users, capped it at that and told the small minority to go pound sand. There are literally full categories on this site with less pages of videos of videos than your watch later list. At some point the list becomes unusable and the value is of the feature is diminished.
Be happy they are fixing it at all. Every bug fixed has an opportunity cost associated with it. And we all have to remember they donāt owe us an explanation, or timeline, or even a fix. This isnāt mission critical software.
When was the last time you reported a bug to Microsoft, or adobe, or salesforce, or Hulu or Netflix or apple or literally any other piece of software and got anything back beyond a thanks, weāre aware.
Iām just trying to provide you with a different perspective from behind the curtain of software development. My views obviously arenāt those of SLR and maybe thatās a good thing because they are really active in their forums and try to communicate the best they can and put up with a lot more than I would despite the constant barrage of toxic comments from its users.