[x] Showing 2 or 3 degrees of separation for a band

Currently as soon as a band reaches 30 bands within 2 degrees of separation, B2B stops showing the 3rd degree of separation in their family tree, regardless of how big or small their tree otherwise was. This is quite an unbalanced way of determining how many degrees to show, for example:

[www.bandtoband.com] http://www.bandtoband.com/band/adrian-utley-and-mount-vernon-arts-lab
displays 412 bands in 3 degrees, since only 16 bands within 2 degrees

[www.bandtoband.com] http://www.bandtoband.com/band/wendy-o-williams-plasmatics
displays 222 bands in 3 degrees, since only 17 bands within 2 degrees

[www.bandtoband.com] http://www.bandtoband.com/band/dead-surf-kiss
displays 197 bands in 3 degrees, since only 29 bands within 2 degrees

[www.bandtoband.com] http://www.bandtoband.com/band/ulcerate
would have about 78 bands within 3 degrees, instead displays 30 bands within 2 degrees

[www.bandtoband.com] http://www.bandtoband.com/band/head-like-a-hole
would have about 73 bands within 3 degrees, instead displays 30 bands within 2 degrees

[www.bandtoband.com] http://www.bandtoband.com/band/redsk
would have 69 bands within 3 degrees, instead displays 68 bands within 2 degrees

[www.bandtoband.com] http://www.bandtoband.com/band/mr-sterile-assembly
would have about 68 bands within 3 degrees, instead displays 32 bands within 2 degrees

[www.bandtoband.com] http://www.bandtoband.com/band/richard-ramirez
would have 43 bands within 3 degrees, instead displays 38 bands within 2 degrees

Point being that the first three examples are better candidates for being reduced to showing 2 degrees of separation than the others. It'd be much better if the reduction was determined by how many bands are within 3 degrees, eg. a limit of 200. Or perhaps have both criteria so that the first two examples aren't reduced to trees of just 16 & 17 bands.

The family tree depth does go to a 3rd degree if 2 degrees has less than 40 bands:

[bandtoband.com] https://bandtoband.com/band/american-armada

If there are any other examples where this limit isn't good enough, please let me know.


Kevin

You missed my point so I'll just take the X out of the thread title again. I put this forward as one of my "least favorite problems" about the site which I was quite passionate about, and I'm taking about fundamentally changing the algorithm, not just tweaking the number.
[bandtoband.com] https://bandtoband.com/forums/wiki-world/site-redesign-what-are-y-47056

What I'm saying is, for the edge cases to have family trees of more democratic sizes, the decision on whether to take the depth to a 3rd degree should depend on how many bands are within >three< degrees. It doesn't help that most of my examples above are way outdated. I'll try to tell it as a story:

- Suppose a typical band somewhere near a thicker part of the tree has 29 bands within 2 degrees, and 300-ish bands within 3 degrees. Tormentor for example:
[bandtoband.com] https://bandtoband.com/band/tormentor

- However, a band in the New Zealand scene I'm working on might have say 16 bands within 2 degrees and 50 bands within 3 degrees

- If I really focus on filling out that particular band's tree, what I'd find is that it soon goes over the limit, ie. now more than 30-40 bands within 2 degrees, and yet it still has only 70-90 bands within 3 degrees (either because the connections at that distance are more confined, involve the same members in different configurations, or we just haven't worked extensively everywhere). So why is Tormentor allowed a tree of 300, while my work gets 'punished' and the band's not allowed a tree of 90? Sometimes I'm in contact with a member of the band I'm focusing on so it's a shame not to be able to show them a tree with 3 degrees any more.

- In the extreme case, I've added artists with 40+ solo projects, but they only have one or two connections into the tree. These are the Redsk and Richard Ramirez examples from above. Showing the 3rd degree on these would only add around 2-5 more bands to their tree!!
[bandtoband.com] https://bandtoband.com/band/richard-ramirez
[bandtoband.com] https://bandtoband.com/band/redsk

You are correct, I didn't fully grasp what you were trying to relay although I think I understand it more now.

To try and simply things both in my thick head and for the site, do you have a lower and upper bound that you would like to see for the 3rd degree of bands to be displayed?

For example: show 3 degrees if
- 2 degrees < 40 bands cumulative
AND
- 3 degrees < 100 bands cumulative

Am I getting a better understanding of your concern? The only reason that I'd want to keep a lower bound for 2 degrees before checking on 3 degrees (ie, 2 degrees < 40) is that the database query to pull the bands for 3 degrees is *very* slow and taxing.

If we can keep a reasonable 2 degrees minimum before executing the 3rd degree database query and then evaluating the total number and display the 3rd degree only under a certain threshold (total < 100 cumulative for example) would be manageable I believe.


Kevin

Maybe there are ways to make things less taxing. How about if the 2 degrees bound wasn't a number, but rather a flag that gets put on each band at some point as their tree grows? For example:

1.) Retrieve all the bands that are 2 degrees away (if you've already reached 100 or the band is flagged in step 3. you stop here)

2.) Retrieve the 3rd degree. Would it be more efficient to loop through the 2nd degree bands 1 at a time or maybe 5-10 at a time? Meaning, retrieve the bands 1 more degree away in smaller portions so you can keep checking whether you've exceeded 100 along the way (or maybe 105 to allow for threshold mentioned below).

3.) After doing the above, you could store a flag against bands that hit 105+ bands within 3 degrees (small threshold in case bogus entries/connections get deleted via Shambles). Then you know you don't need to explore 3 degrees for them again. Only in very rare cases a correction via Shambles might remove a major connection and maybe then someone could clear the flag manually.


Bonus overthinking.) I realise using a loop in step 2.) may be taxing too, but perhaps it opens up ways to make it less taxing again. Eg. skipping one-man bands. Skipping 2nd degree bands where every member is either also in a 1st degree band or only in the one band (depends if you have the artist IDs from the 2 degrees query to play with I guess).

The B2B geek in me is still keen to see all the weirdly-shaped trees. The edge cases where an artist's bandmate has 67 solo/non-connective projects and 2-3 bands actually serving as their connection into the tree. But not if it means slowing things down with 70 queries. This bandmate of Richard Ramirez is a good example where the 3rd degree could do wonders and show where the 2-3 links actually go:
[bandtoband.com] https://bandtoband.com/band/the-rita

I tried something similar to your suggestion on the old site where I'd try and track the family tree growth, cache it at various times, etc. However this ultimately would blow up in my face. The problem lies in database calls where it will kill you with either:

1) Very complex / intensive queries
2) Way too many queries

Here, querying the DB for every band as a tree grows would blow up. Even when I recorded that data as I went, it will still blow up whenever any single tree was updated which triggers a recursive rebuild of all other bands' trees. There were times on the old site where the entire server would run slowly for 12 hours as band after band had to have their trees re-calculated.

I can't go back to that system and put the server at risk again. However as a possible stop gap, we can try this:

1) Set reasonable defaults to catch most cases:
- load 3rd degree if 2nd degree < 40(?) bands cumulative
- display 3rd degree if < 100(?) band cumulative
(since you are more in the weeds with the edge-cases, you can pick the default numbers)

2) In the case the 3rd degree doesn't display, I can add a button for logged in users to force load and display the 3rd degree on demand. That way for the edge-cases that do not load, you can still fire it up manually which won't tax the server terribly if it's only on demand as one-offs. This would even apply to all bands, even those with already big 2nd degree trees. If you wanted to be punished with the full 3rd degree display for any band, you would then always have that option.


Kevin

I don't mean ongoing tracking/caching of the trees. I just mean when a site visitor views a band's page and the 3rd degree is queried. If that query tops 100, would you then set a flag on that band so the query is never even tried again for them? Because there are plenty of cases where a 3rd degree far exceeding 100 is shown now (eg. Tormentor). There's not much point hiding those 3rd degrees if the query is still running in the background every time, haha. So my idea with the flag is to reduce all those queries going on, which could maybe allow room to increase the 40 to a larger number and have more 3rd degree queries running for bands where we would actually display the 3rd degree, due to their tree being something like this:

band -> 18 bands -> 29 bands -> 45 bands

(ie. 18 + 29 = 47 within 2 degrees but still < 100 overall)


Anyway, what you said sounds good, with 40 & 100 as a place to start. Though maybe one exception could be be if you have something like this:

band - 1 band - 5 bands - 150 bands

Because then it'd be kind of a downer to show a tree of only 6 bands to the public. Maybe always show the 3rd degree if < 8 bands within 2 degrees?

I've uploaded the range limits for family trees as discussed, including a 2 degree minimum to always load the 3rd degree as mentioned:

"band - 1 band - 5 bands - 150 bands"

I've also brought back in the old site's listing of degrees displayed as well as total number of bands (so I can double check that the numbers are correct).

I can skip the "Load 3rd Degree" button if it's not necessary. Let me know if what's up now fulfills what you were hoping to see from Family Trees.


Kevin

A 'load 3rd degree' button for logged in users would be fantastic I think.

Bands that are close to the 40 and 100 limits look good:
[bandtoband.com] https://bandtoband.com/band/the-skull-nz

The one issue I notice is the text for the bands that were showing 3 degrees and now show 2 degrees is mistakenly saying "3 degrees of separation for..."

Does that mean the 3rd degree calculation is still happening in the background as I wondered?

Do you have an example of a band showing only 2 degrees but saying "3 degrees" instead? Seeing one would help a bunch in debugging it.

I'll try and get that "Load" button going here before long.


Kevin

Yes, I mean it's all the ones that are under 40 at the 2nd degree level but would have over 100 in 3 degrees, eg.
[bandtoband.com] https://bandtoband.com/band/sommerset
[bandtoband.com] https://bandtoband.com/band/tormentor
[bandtoband.com] https://bandtoband.com/band/snakes-and-sirens
[bandtoband.com] https://bandtoband.com/band/blood-red-throne

This took way longer than I would have wanted but the option to load the 3rd degree of bands in a family tree is now up for logged in users. I had to redo (for the better) the entire rendering process of family trees behind the scenes. It takes a second or two to load, which is an eternity in the web world, so be patient as they load.

Hopefully that finishes off Family Tree requests. If I've missed anything, let me know.


Kevin

That's beautiful, nice work! In some cases it seems to load almost instantly too.

Nice feature. Probably unfair of me, but I tried to get 3 degrees for the Beatles and it timed out.

Beatles timing out here too, and the resulting timeout error screen isn't pretty.

I thought Pigface would be the one to go for, but their 3rd degree takes a bit over 20 seconds.

Ah, yep, this is what I was afraid of. The Beatles have 416 bands at 2 degrees and trying to connect all of those to the next level is simply too much for the system to take. Actually it did go through for me and resulted in:

3 degrees of separation for Beatles comprise 2974 bands

That is simply going to be too big for the system to have to handle. You could easily get into Denial Of Service attacks by having someone click on those repeatedly. I'm going to have to put upper bounds on either the number of total bands the family tree is allowed to map to (the search stopping at say, 600 bands) or not allow a 3rd degree load if a band already has 300 bands at 2 degrees (for example).

Any opinions on this one? The status quo simply cannot be allowed to be available.


Kevin