amitbl/blocktube

Is there a limit for blocking video ID's?

Opened this issue · 7 comments

I think I blocked more than 500 videos or more from a channel yesterday and today some of those videos reappeared again.

Good to be warned, I blocked 667 currently, and am going to block several thousands soon, will have to keep an eye. By the way, are you sure that they are exactly the same videos that have reappeared for you? For example, usually many music videos, which are the same song, are uploaded with similiar title but different URLs, hence they are different videos, despite same song.

Good to be warned, I blocked 667 currently, and am going to block several thousands soon, will have to keep an eye. By the way, are you sure that they are exactly the same videos that have reappeared for you? For example, usually many music videos, which are the same song, are uploaded with similiar title but different URLs, hence they are different videos, despite same song.

I was blocking older videos from a channel, that is when I go to a channel I select it so it can order the older videos first on the "Videos" tab, when I came back the next day I saw that some videos showed up again but not all of them. Maybe it was a bug or something because I was blocking them too fast one after another lol.

Now I just save a backup whenever I block a video or a channel ID.

Are you sure that IDs of the videos which reappeared for you, are on your blocklist?
That way we make sure whether the issue is:

  • that videos's IDs for some reason wasn't added to the blocklist
  • or that videos's IDs were on the blocklist, but the videos still reappeared

Are you sure that IDs of the videos which reappeared for you, are on your blocklist? That way we make sure whether the issue is:

  • that videos's IDs for some reason wasn't added to the blocklist
  • or that videos's IDs were on the blocklist, but the videos still reappeared

I know the video IDs were in my blocklist since I was refreshing the youtube page every 20 or so blocked videos and then I'd go and refresh the Blocktube page to see if it got updated. But it's working fine for now.

khazad11 : Is there a limit for blocking video ID's? I think I blocked more than 500 videos or more from a channel yesterday and today some of those videos reappeared again.

There doesn't seem to be any limits, at least not by design of the extension, see:

The guy 1 who blocked over 1k channels, and the answer from the creator was:
"There should be no problem having more than 1K channels.",
however there seemed to be some bug which caused overwriting old entries if there were too many entries :

The guy 2 who blocked over 1k channels, and the answer from other user was:
"No, i have way more than 1000 channels blocked already, it's not slowing down things either."

Also, there are many other issues where blocked videos or channels sometimes appear again:

After some testing on Opera (current browser version: 111.0.5168.55 - based on Chromium:125.0.6422.143), it seems that, as a design choice (?) or because of some specific browser internal behaviour/feature, when the extension reads/writes its settings, it does not interact directly with its internal settings-database but rather it works with copies of said internal-database, each one created and linked to each opened youtube-page, where all copies are distinct objects independent from each other.

Because of this (see details below) the extension seems to work correctly only having a single youtube page opened (from which elements are requested to be blocked) with the extension-settings UI closed or having the extension-settings-UI opened and no other youtube page opened.

Specifically, 2 or more youtube pages, opened at the same time (in browser-tabs or windows), seems to contain each one a distinct instance/copy of an internal extension-settings database:
--> The extension reads-from/writes-to each of those database-copies independently.
Said copy is created for a single youtube page, each time said page is opened or refreshed.

Each time a [Block-Channel]/[Block-Video] request is sent from a youtube page (which happens when the corresponding buttons are clicked in the video/comment popup-action-menù):
-- first a new blocked-element-ID is added to the extension-settings database-instance, linked only to that page;
-- then the extension-settings internal-database is overwritten with the contents of said database-copy .
All the other youtube-pages won't be able to see any of the updates, on said internal database, derived from the interaction with that particular page, until each of those other pages are refreshed.

The same does occur if a youtube-page and the extension-settings-UI are opened at the same time:
--> any manual modification of the block-lists, made via the extension UI, won't be read by any of the opened youtube pages until each of those pages are refreshed, and viceversa any modification applied when blocking elements from any of those youtube pages won't be seen in the extension-settings page until said page is reloaded;

An immediate consequence of this extension or browser behaviour is a potential data-loss in the internal settings-database, which could occur whenever multiple element-blocking actions are requested in multiple opened youtube-pages, which could give the impression of an existing internal database capacity limit.
As an example, given 2 youtube pages opened in 2 separate tabs/windows, lets say A and B:

  1. When A and B are opened for the first time, both makes a copy of the internal extension-settings database, each copy linked to A and B respectively; Lets indicate db_internal, db_A and db_B as the internal-database and the page A and B database-linked-copies respectively;
  2. If the user select an element to be blocked (video/comment) in page A, db_A is updated first, with a new blocked-element-ID, then db_internal is overwritten with the updated contents of db_A:
    --> At this point db_A and the db_internal are in sync, while db_A and db_B (and also db_internal and db_B) are not;
  3. If some other element is selected to be blocked in page B, without refreshing B first, as in step [2], first db_B is updated with the ID of the selected element in page B, and then db_internal is overwritten with all the updated contents of db_B:
    --> At this point, since, as said in step [2], db_B and db_A where not in sync (db_B does not contain any of the updates applied to db_A) db_internal has actually lost all of the updates copied from db_A in step [2] and will retain only the ones copied from db_B;
  4. To correctly update db_internal with the contents of db_B without losing the new entries copied from db_A, page B must be refreshed after blocking any element from page A and before selecting any element to block in said page B:
    --> By doing so, first db_B becomes a copy of db_internal, which in turn is a copy of the last version of db_A (that is first db_B becomes a copy of the last version of db_A), so when any new element-ID is added to db_B (after selecting elements to block in page B) and db_internal is overwritten with the contents of the updated db_B, db_internal will retain each new element-IDs added both in db_A and db_B;
  5. Finally to make page A reading the settings updated in step [4], said page must also be refreshed;

Having multiple youtube pages opened at the same time, it is also convenient to directly update all youtube pages opened, whenever one or more elements are blocked in one of those pages.

Finally, having the extension-settings UI opened along with at least one youtube-page, I've found out it's best:

  • to make sure a manually updated block-list does end with just a single new-line after the last list entry;
  • to always export the extension-settings after each manual modification before refreshing all the other youtube-pages;

Following the above mentioned criteria, after one year of continuative usage (always on Opera) I've managed to store more than 5750 channel-IDs entries with no data loss.

Good investigation, it's a nasty bug or design, which leads to user's data-loss, doing some quick tests, I can reproduce the issue in Chromium, but not in Firefox, but since I didn't do major tests yet, as for now, I can't give 100% guarantee that Firefox is not affected.