• Support

  • Playlist - Watch later. Maximum reached?

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.

    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 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.

          xxxscottyxxx one option for now, I suppose, would be to make a new playlist for the overflow. Is that still something we can do?

              petermc Yes, that's exactly the work around I've been doing the last week! Maybe I'm blind or maybe it was added recently in an update but there is an option to make a new paylist, I'm sure it wasn't there before but as I say I may have just not noticed it as I never really needed it but at least this is now giving us a way to add more titles to a watch later section.

                19 days later

                Hey, our devs are saying this is fixed, can you guys double check and maybe record a quick screengrab if it is still broken?
                Thank you!

                  Sandi_SLR No, Its still broken exactly the same as its been for a while. Ive just tried to add using the app inside the headset and it will not add any thing to 'watch later' (the app if fully up to date) and ive also just tried on my laptop through the website and still get the 'maximum number of titles reached' error even though I must have deleted about 30 - 40 scenes since I first reported the issue

                    FWIW - can also confirm this is still broken at least for me with "My Collection". I noticed this recently, ran across this thread, and after seeing the post from a day ago, just checked mine. I use it more than "Watch Later" by far.

                    I can get up to page 46 of "My Collection", but trying to go beyond that to see more, no results are returned, but the "500 Internal Application Error" appears. I am 100% certain there are many more pages that I should be seeing just knowing what I've favorited, the amount I have favorited over the past few years, and by changing the sort type between dated added (oldest) and date added (newest) and date published (oldest) and date published (newest) - reviewing those shows me that there are many more stored in the database. So there is still a bug breaking the ability to review and go through all the pagination pages of listings. Hope this helps nail down.

                      bigboppa I can get up to page 46 of "My Collection", but trying to go beyond that to see more, no results are returned, but the "500 Internal Application Error" appears.

                      Sandi_SLR Sounds like the bug that is existing for quite a long time (at least in DeoVR on Q2). In any selection of videos with a sufficiently high number of results pages, there seems to be a point from which you cannot go any further due to server error. For example, if you browse through all videos, it stops at around page 200.

                      This was reported in the forum multiple times over the last months but nothing seems to have improved.

                            SchnuppiLilac I don't think it is a maximum thing because I have deleted a lot of "watch later" videos since this all started. It still doesn't let me add back to the list in replacement of those deletions.

                                rerun119 Perhaps devs looked at the bugreport and figured "fixing the issue" meant to no longer allow us to add scenes beyond the random limit there is on everyone's playlists. 😑
                                The weirdest thing to me is still how it is limited at a different amount for everyone who's reported it. I mean pagination stuff can be annoying to code properly but that random limit is just very odd.